Re: [opensuse-contrib] Policy for broken packages - draft
Peter, Listmates, On Thu, 2009-08-20 at 18:14 +0200, Petr Uzel wrote:
the number of broken packages (those that do not build for whatever reason) in Contrib is quite high now, so I'm thinking about a policy for these packages.
Shame.
According to [1], whoever submits a package to Contrib agrees that she/he will take care of the package, which of course means also ensuring that package can be built fine most of the time. If this is not possible for some reason, we should have some mechanism to collect garbage and thus keep Contrib in a good shape.
So I'm proposing the following garbage-collection algorithm for openSUSE:Factory:Contrib repository:
1) Build of package FOO fails
2) After 14 days, send and email directly to the maintainer of FOO that FOO needs his attention
3) Wait another 14 days
4) If FOO was not fixed and nothing in Contrib depends on FOO, GOTO 7)
5) If FOO was not fixed and packages BAR and BAZ (in Contrib) depend on FOO, then send an email to maintainers of BAR and BAZ that if FOO is not fixed, then all FOO, BAR and BAZ will be dropped
6) Wait 14 days
7) Post an announcement to opensuse-contrib@opensuse.org that if nobody fixes FOO, FOO and all packages depending on FOO will be dropped in 14 days
8) Wait 14 days
9) If FOO is still not fixed, move it to openSUSE:Factory:Contrib:Deleted
so we're looking at an about 2 month schedule from breakage until removal?I don't think it's to long or to short. The amount sounds good. I'm not certain though that the 'process' of just mail is sufficient enough. It leaves 'too few tracking' in my opinion. honestly, in this respect I think launchpad is a great tool, as 'bugs' are associated straight to a package (something our bugzilla / obs integration is missing). Maybe integrating the process into Bugzilla (by some automatic means.. scripting is possible after all) would be. Product: openSUSE Component: Contrib Package: <foo> <Assignee>: <maintainer> <CC>: contrib-ML (or a more specific monitoring list). Maybe using some flags (ContribFail1, ContribFail2) we could have the level of how far it is in the process? (Also for scripts, to verify when the assignee or CC list needs to be changed/extended, after the 14 day periods). After step 9, the bnc entry could just be RESOLVED / WONTFIX and the package be moved out of the way. This all sounds like some cron magic should be able to do the trick :) Dominique -- To unsubscribe, e-mail: opensuse-contrib+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-contrib+help@opensuse.org
On Thu, Aug 20, 2009 at 06:29:53PM +0200, Dominique Leuenberger wrote:
Peter, Listmates,
So I'm proposing the following garbage-collection algorithm for openSUSE:Factory:Contrib repository:
1) Build of package FOO fails
2) After 14 days, send and email directly to the maintainer of FOO that FOO needs his attention
3) Wait another 14 days
4) If FOO was not fixed and nothing in Contrib depends on FOO, GOTO 7)
5) If FOO was not fixed and packages BAR and BAZ (in Contrib) depend on FOO, then send an email to maintainers of BAR and BAZ that if FOO is not fixed, then all FOO, BAR and BAZ will be dropped
6) Wait 14 days
7) Post an announcement to opensuse-contrib@opensuse.org that if nobody fixes FOO, FOO and all packages depending on FOO will be dropped in 14 days
8) Wait 14 days
9) If FOO is still not fixed, move it to openSUSE:Factory:Contrib:Deleted
so we're looking at an about 2 month schedule from breakage until removal?I don't think it's to long or to short. The amount sounds good.
I'm not certain though that the 'process' of just mail is sufficient enough. It leaves 'too few tracking' in my opinion. honestly, in this respect I think launchpad is a great tool, as 'bugs' are associated straight to a package (something our bugzilla / obs integration is missing).
Maybe integrating the process into Bugzilla (by some automatic means.. scripting is possible after all) would be.
Product: openSUSE Component: Contrib Package: <foo> <Assignee>: <maintainer> <CC>: contrib-ML (or a more specific monitoring list).
OK, some more tracking than just sending emails would be fine. Scripting bugzilla (as you propose) should be also possible - I think mvyskocil's tool [1] could help here.
Maybe using some flags (ContribFail1, ContribFail2) we could have the level of how far it is in the process? (Also for scripts, to verify when the assignee or CC list needs to be changed/extended, after the 14 day periods).
Hmm, does Novell bugzilla support user defined flags?
After step 9, the bnc entry could just be RESOLVED / WONTFIX and the package be moved out of the way.
Another way how to add more tracking to the process without scripting bugzilla could be something similar to coolo's 'Factory status' page [2] - along with sending emails to maintainers the page would be updated so that for every failing package one could find when it will be dropped, the buildlog, dependent packages etc. It should be easier to implement than bugzilla integration, but it would be just-another tool.
This all sounds like some cron magic should be able to do the trick :)
Dominique
[1] http://lizards.opensuse.org/2009/07/29/hackweek-iv-novell-bugzilla-access-fr... [2] http://www.suse.de/~coolo/factory-status.html -- Best regards / s pozdravem Petr Uzel, openSUSE Community Multiplier Team ----------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel@suse.cz Lihovarská 1060/12 http://www.suse.cz 190 00 Prague 9, CR
participants (2)
-
Dominique Leuenberger -
Petr Uzel