Countries I've been to

Page executed in 0.9643 seconds.

Review of comments

February 4th, 2008

Figured since I actually got some interesting replies as of late that I’d highlight some of them and add some more thoughts about them.

I think one thing that would help the bugwranglers in this case would be a Frequently Submitted Bugs.

This is an example of an idea that I’m looking for. Something that I most certainly would not of thought of but has a very valid way to help out. One little minor issue is that we don’t have enough bug wranglers. The one person who actively does it, doesn’t really have the time to actually write up such a document. An area that we could use help obviously so this kind of documentation can actually be updated or simply created.

Do I always need the latest and greatest, well no. Except may be for a few select apps for which I will go as far as having my own personal overlay. Really I experiment with stuff.

This is a perfect example of a person who has the perfect way to help out. They have only a few packages that they run unstable and as they actively use them…know if they work with the rest of their stable tree setup. With a minimal of effort they can do a search for open bugs with a simple ALL package name. If there’s nothing critical for their version they can then go and file a bug for marking it stable. Currently the maintainer needs to push that to the arch teams to mark stable but it will mean that other people will get a new stable version. That’s always useful.

Some of the Portage documentation gives a bit of a mixed message about this. ( http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3 : “If you want to use more recent software, you can consider using the testing branch instead.” ). It says “we recommend you only use the stable branch” but maybe not strongly enough?

Something that we can look into changing as it does say that either work, and they certainly do. I’d like to see more stable users personally but that’s my goal and not the projects as a whole.

I tend to run ~x86 versions of desktop apps which I know are updated regularly with new features (Pidgin, Amarok, Firefox, many others), even if I can’t name all of those features off the top of my head; but I use the stable versions of mostly everything else. Does this seem like a sane policy?

This is the kind of thing I actually sort of expect to see happen with Gentoo. These are also applications that really should be stable far sooner then others as they are so commonly used in arch and ~arch mixed environments. I consider this a very sane policy and in a lot of ways its also the way I do my own system.

I’d submit bugs to mark new versions of some of those packages stable, but I don’t really know what the process is.

This is something that once I’m able to sit down and work on it…that I’ll hopefully put out a document that will be somehow associated with our bugzilla system so that its prominent there. I’m sure others would like it mentioned on the front page as a prominent link but there has to be some motivation to want to help out.

I’ve always been running ~ arches, both because I like bleeding edge stuff and because I don’t mind investigating broken builds and post bugs about it. Even unstable has been very “stable” to me, so keep up the good work!

This is great and shows another side of our community. A person who helps out in his own way. More power to you and those like you.

The second big reason (after I hit the problem first, so I can help, I have less problems then they have), I am a version junkie. I like to have the latest KDE, xine, glibc, kernel, gcc as soon as it is unmasked. Even more true for games, where the difference between two releases can be huge.

I think quite a few of our users would fall into this category. This is of course is diametrically opposed to those who run stable.

Also, when I’m trying a new unstable package, I’m never quite sure what version to unmask. I don’t *really* want to run unstable - it’s just that there’s no stable version.

This is another perfect example of what we could use help with. Honestly, I don’t know what packages you run. I doubt you know what I run. So if its entirely unstable…lets work on getting at least one version stable if it can go without some major blockers. It could be that the maintainer just never thought about it for stable. A lot of maintainers do actually maintain 20+ packages so some do get forgotten when you have that many.

I generally try to keep my system as close to arch as possible (i use x86, amd64 and ppc(64) ).
But some of the packages I depend on are hopelessy outdated.. dev-db/postgresql .. the stable release is 8.0, 8.3 is in release candidate state… there is usually around 15-25% more performance for each major release (8.1 -> 8.2 -> 8.3) and lots of major features (new features for 8.3 is for example full text search, which is vital for my kind of work) …

Postgresql is a fairly important package, one that I’d vote for lots of testing before going stable. Still requires someone filing a bug to go stable as well. If the maintainer doesn’t do it. Recommend it. If the maintainer says it shouldn’t then there should be a good number of reasons but I’d like to see a 40+% increase in performance in my stable machine, I’m not sure of a user who would not.

That’s just a few of the comments that I found interesting lately and wanted to highlight the ways that these users can help out a lot as you can see is by simply working with the ticketing/bug system we have and helping us with the testing you are already doing….

3 Responses to “Review of comments”

  1. Francois Says:

    I just remembered an episode that was a bit painful with bug #86047.
    A long time ago now I was toying with rosegarden and suddenly the ebuild
    in stable stopped working (or the version left in stable didn’t work
    I don’t remember). I searched on bugzilla for _open_ bugs on rosegarden
    (also at the time searching for “all” was quite slow and often resulted in
    time out at the times I was actively searching).
    My bug got closed as a duplicate of bug #86047 it did upset me on two counts:
    1) we are told to give “good descriptive summary” for our bugs,
    “rosegarden ebuilds are bull…. :)” is certainly descriptive but it doesn’t
    really tell me what’s wrong - and that was filled by someone who apparently
    should have known better or so it looked to me at the time. I am not sure I
    would have related my problem to this title.
    2) and now that’s the main rub: the bug was marked closed fixed while the stable
    version in the tree was broken. While I can understand that the bug was
    resolved I am not sure it should be marked fixed when the only stable version
    is broken. If you know it’s broken it should at least be removed or something.
    It stayed that way for quite a while until someone cleaned up.

  2. moesasji Says:

    Just some random thoughts after seeing those comments.

    1) Bugzilla is one of the things that immediately comes to my mind when thinking about what annoys me. It is so extremely difficult to retrieve any useful information from it that I really don’t understand how developers can work with it or even keep track of things.

    Something as trivial as finding the bugs you’ve submitted or commented on actually requires thinking…probably one of the reasons why so many bugs remain unresolved as the submitter looses sight/interest.

    2) At the same time it is my feeling that bugzilla doesn’t really stimulate users enough to help resolving bugreports. As an example I wouldn’t mark a bug as non-valid or attach a comment along those lines, something that I would do in the forums. I don’t know if this feeling is universal, but if so it could be good to get this threshold lower somehow so that simple users can easier do small tasks.

    3) Overall there seems to be quite a large number of knowledgeable people in the forum, but the threshold to do something is too big at the moment. It’s my impression that FreeBSD hits this balance better. Somehow the distinction between system and world, where users take a greater responsibility for the world part seems to be more inviting to contribute.

    To some extend I think that Gentoo’s system is too advanced as a result of the magic that happens in the eclasses. I found that getting something to compile on FreeBSD is easier. An example that I actually tried is the SVN version of code::blocks. Easy on FreeBSD, a nightmare on gentoo if you don’t have the ebuild that is maintained by somebody in the forums.

    Last part brings me back to the threshold in contributing…in the forums a person is actively maintaining an SVN ebuild for code::blocks. It would be beneficial if such a person would actually do that within the tree as wxGTK seems understaffed seeing how long it took to get wxGTK2.8 into the tree, which again points to the high threshold for participation.

    4) I do run most of my system as stable and quite often submit stable-requests. However the amount of those requests that go without much response for a very long time makes that quite quickly you feel that this is not a useful thing to do. The latest stable-request that annoys me is clamav for example. In particular as logwatch flags this up day in day out.

  3. Xake Says:

    About the “Frequently Submitted Bugs” I did not think directly that the bugwranglers would make that as much as the bug-fixers could start working on it. They could make their own entries and if someone finds something that is a similar problem for two bugs it could always get merged after that. But the mainpoint is to have a database with facts and possible solutions and/or links to possible solutions, not having a lot of spam/noise as some longstanding and common bugs get as the users think they finds their own solutions/workaround.

Leave a Reply