In my last post I mentioned that users of packages lacking a maintainer in portage should submit patches for the open bugs; while this is all good and fine, it is true that often there are bugs with patches that stays there to rot as well. I wish to point out here some things that might not be obvious to users as well as developers.
The first point I want to make is that it’s not like the problem is limited to user-submitted bugs and patches; bugs and patches submitted by developers can follow the same road too, waiting for months, if not years, before they are accepted and merged in. The problems here are many, some technical some social, some difficult to fit into a single category.
The biggest technical problem I can find is that there is no easy way to identify bugs which have patches waiting for review from a simple search. Modifying the Bugzilla workflow is probably a matter too complex to be worth it, but there is an easy way to avoid this, although it requires more coordination between reporters and assignees: using the “Status whiteboard” field to write “Patch waiting review” or something like that; the status whiteboard appears in searches by default, and would be useful to signal stuff like that (I used that to ask developers to signal me particular cases where gnuconfig_update couldn’t be removed).
Another technical problem is that maybe some developer is interested in fixing eventual bugs with patches for a particular package that lacks a maintainer, without becoming maintainers themselves; or an users would like to submit patches for the new bugs about a particular package. Adding themselves to maintainer-needed alias, or watching it, is most likely going to throw at them a huge amount of bug mail they are absolutely not interested in; I’m sure I sent some hundreds of bugs the m-n way in the last month (I’ll have fun watching the bug statistics on the next GMN), and I’m sure most people wouldn’t care of all those bugs.
The feasible way to handle this in the current infrastructure would be to set up bug whining filtering by package name in subject, but that’s not the nicest option I guess, although it is doable without changing anything. Another idea I got would require a huge effort from our infrastructure team and might not really e that feasible: creating multiple package name aliases; basically creating an packages.g.o domain, and then creating dynamic aliasing for addresses like app-arch+libarchivep.g.o so that it would then redirect the mail to the maintainer (developer or team) looking at metadata. This is of course a very complex solution, requires technical changes, and might as well be quite worse on other things, like for instance it would be a huge mess to search for all the bugs for a given herd, and would increase the amount of spam that each alias receive in a HUGE manner. On the other hand, the domain could be ste to only receive mail through bugzilla, and the addresses being otherwise invalid.
There are then some social problems, for instance there is the fact that Gentoo developers are volunteer, so you can’t force them to accept patches, or to improve submitted patches if they are not seen fit for merge in the tree. This means that if you want your patch to be merged in the tree you need to make sure you have a good case for it, and that you improve it as much as it’s needed for it to be merged, which might take an incremental amount of time. Of course not all users are programmers, but you cannot expect all developers to take charge of improving patches indeterminately until they can be merged, if they have no need for such patches. You can always try to find some person interested in helping out who can help you improve the patch; in the worst case you can resolve to pay someone to fix your patch up.
Also, most of the developers are likely swamped and might require some prodding to remember to take care of patches, and this is probably the heaviest showstopper; the only way to fix that is to join Gentoo and start improving the situation; of course it requires training, it’s not like we can accept every user as a developer, there are standards that one has to consider. Yes, I know there are some developers who not always live up to those standards, but that’s also a problem. I’m not saying that new developers should be perfect before joining, but they have to be open to critics and ready to learn; “works for me, it’s your problem” is not a good answer.
Does anybody have better ideas on how to fix these problems?
When I first started being a dev, I squashed about 60 m-n bugs in a month, I eventually got the queue down to less than 250 open bugs. That was quite good. Now it is back to 432 open bugs. Maybe one solution would be to drop maintainer-ship on everything other than the toolchain and/or “big” projects. meh.
Overlays can be a solution. Overlays like sunrise that accept user contributions can allow people to get their patches into a publicly available forum — even if it’s not the tree. Eventually, those patches will (hopefully) trickle down into the portage tree.Maybe creating a new development team to specifically monitor overlays and integrate important patches from them into the tree is a way to go.
As for identifying bugs that have patches waiting for a review wouldn’t it be sufficient to apply some keyword to them?
Unfortunately only the reporter can set the Status Whiteboard…
The point is that “Status whiteboard” appears by default on searches, while keywords don’.And I don’t like the idea of overlays _at all_, and I think with due reasons (I have written about them quite a bit in the past, I might write more in the future maybe).And Jeremy, I also closed huge amount of bugs in my first year as a developer, but after a while you have to choose whether to do one thing very good or trying to do many on average; I choose the former, like I think most our colleagues did. I don’t think there’s a right or wrong choice there, but it is a choice.
I fully agree that overlays is not the solution, although for a different reason. A user running gentoo doesn’t want to spent ages finding the correct overlay to run up-to-date software (and then end up in the situation that dependicies are not compatible with multiple overlays). To me overlays as a source where the user is expected to find software counter-acts the whole concept of gentoo that attracted me to it a long time ago.Regarding to your blog-post. I do think you need to think about the underlying problem instead of (only?) looking at symptoms. To me it appears that the amount of bugs and packages makes working with Bugzilla a nightmare due to the scale and complexity of Gentoo. As a result it is very difficult for users to step in and help with basic stuff, so that devs can focus on the more interesting and novel stuff (which they will do by definition leaving the boring stuff for bit-rot).Finding a solution for that is difficult….it might be that the git-approach of Daniel works and it at least appears a natural thing to try as it works well for kernel-development. On the other side the model of Arch linux with different community managed repositories also has it charms. Problem for the latter is that in Gentoo so much of the complexity is hidden in the eclasses that (to me!!) don’t appear to have a clear “upgrade-path” in contrast to ebuilds. In the arch-model I don’t really see how users can work on improving e-classes in an easy way in contrast to the GIT-model.
Yea, wrt to overlays. I’m not impressed with them to be honest. Some uses but definately not to house lack of maintainer ebuilds.I’m intrigued as you your opinion of the underlying problem, Moesasji.
About user contributions, there is a thread on forums.gentoo.org We are trying to summarize our suggestions : http://forums.gentoo.org/vi…