Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Thu, 2010-01-28 at 11:14 +0100, Till Maas wrote: Nevertheless, what is the recommended procedure to claim the other branches? Is it a ticket to FESCo trac or a CVS Admin procedure request? Honestly that's a good question. I'd start with a FESCo ticket and see what happens? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote: On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensou...@till.name wrote: The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package. Odd. Not sure why it wasn't there. I mailed the maintainer and can orphan it. It is still not orphaned afaics. Regards Till pgpqaQa70AEbW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, Jan 19, 2010 at 02:42:17PM -0700, Kevin Fenzi wrote: On Sun, 17 Jan 2010 20:48:25 +0100 Till Maas opensou...@till.name wrote: On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote: On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensou...@till.name wrote: Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can. No, please go ahead. I took the liberty right after I posted. Did also contact the recordmydesktop maintainer? I didn't then, but I did just now. (Of course that meant I had to send two emails... perhaps next time you could just mail them directly? :) You offered to write both of them and I agreed afaics. Nevertheless I did not mail them directly, because I hoped the full situation could be resolved in some clean way, e.g. just perform a non responsive maintainer procedure on all affected maintainers at once instead of all these quick actions that leave a lot of confusion. Nevertheless, it is too late now, anyhow. Regards Till pgpQgwcFnJvVr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Wed, Jan 27, 2010 at 10:39:38AM -0700, Kevin Fenzi wrote: On Wed, 27 Jan 2010 15:43:40 +0100 Till Maas opensou...@till.name wrote: On Tue, Jan 19, 2010 at 02:42:58PM -0700, Kevin Fenzi wrote: On Sun, 17 Jan 2010 20:52:12 +0100 Till Maas opensou...@till.name wrote: The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package. Odd. Not sure why it wasn't there. I mailed the maintainer and can orphan it. It is still not orphaned afaics. Sorry about that, was hoping I would get a reply. Oh, then I misunderstood, I thought you got a reply saying that you can orphan it. I will then go on with a non responsive maintainer procedure. Regards Till pgprlTQjbM6Ur.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, 19 Jan 2010, Toshio Kuratomi wrote: After some talk on IRC yesterday, skvidal is the person doing work on this at them moment. His plan is to implement tests that try to tell if individual packages are maintained and get people to orphan those that are not. Here's his general plan for what to test: 1. all the pkgs which have no devel checkins in 365 days 1a, if the only checkins they have correspond to a massrebuild date - then they still get counted as potentially abandoned 2. all the pkgs which have no builds, other than mass rebuilds in 365 days then take that set of pkgs and if it is a LARGE number of pkgs - then intersect that with pkgs which have bugs open to reduce the set a bit b/c open bugs AND not looked at == problems for fedora We discussed whether to do reporting from this via bugzilla or another tool and I'm leaning towards another tool so it's easy for a maintainer to look through and a list of packages and check which ones they still care about. skvidal would like to get the tests working first to see if we're talking about a huge number of packages or only a few. I'm going to try and generate a couple of lists today if I can get all my koji-foo working properly. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
2010/1/18 Seth Vidal skvi...@fedoraproject.org: 1. extraordinarily stable [...] in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. Are you serious? - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Tue, 19 Jan 2010, Thomas Moschny wrote: 2010/1/18 Seth Vidal skvi...@fedoraproject.org: 1. extraordinarily stable [...] in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. Are you serious? As a heart attack. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sun, 17 Jan 2010 20:48:25 +0100 Till Maas opensou...@till.name wrote: On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote: On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensou...@till.name wrote: Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can. No, please go ahead. I took the liberty right after I posted. Did also contact the recordmydesktop maintainer? I didn't then, but I did just now. (Of course that meant I had to send two emails... perhaps next time you could just mail them directly? :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
Matt Domsch (matt_dom...@dell.com) said: With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm. We could easily create a new class of bugzilla ticket, say MAINTAINED. An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think). Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Bill Nottingham wrote: Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill. Right - so maybe last check into devel branch since the last release of the distro. If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think. thoughts? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote: On Mon, 18 Jan 2010, Bill Nottingham wrote: Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill. Right - so maybe last check into devel branch since the last release of the distro. If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think. The majority of my packages does not get updated that often (15 from 21) and there are also no bug reports unhandled for them. I am not sure how the ratio is for others, but it does not seem to be such a got criterion. Regards Till pgpJ3zn66b6aD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Till Maas wrote: On Mon, Jan 18, 2010 at 12:25:44PM -0500, Seth Vidal wrote: On Mon, 18 Jan 2010, Bill Nottingham wrote: Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill. Right - so maybe last check into devel branch since the last release of the distro. If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think. The majority of my packages does not get updated that often (15 from 21) and there are also no bug reports unhandled for them. I am not sure how the ratio is for others, but it does not seem to be such a got criterion. so 15/21 your packages don't get rebuilt, atall, from release to release? Really? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 12:25 -0500, Seth Vidal wrote: On Mon, 18 Jan 2010, Bill Nottingham wrote: Ugh, this seems like it would just create a lot of make-work for the common case where packages *are* maintained. Perhaps only do this for packages that appear via some criteria (have not been built, have not been committed to, have lots of bugs with no response, etc.), but doing it for *every* package seems like overkill. Right - so maybe last check into devel branch since the last release of the distro. If we do that check before the alpha release that should let us track down awol maintainers and unmaintained pkgs pretty easily, I think. thoughts? I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Tomas Mraz wrote: I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package. I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are: 1. extraordinarily stable 2. dead upstreams 3. unmaintained 4. unusued in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote: On Mon, 18 Jan 2010, Tomas Mraz wrote: I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package. I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are: 1. extraordinarily stable 2. dead upstreams 3. unmaintained 4. unusued in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. So that means that for example for the openoffice.org-dict-cs_CZ package I'll get the nag bug report before each and every Fedora release? It is definitely not 4. however 1. and 2. apply to it. As this is just a czech spelling and hyphenation dictionary which is pretty good one and we do not have any alternative anyway I do not think that 2. matters much. OK, I think my next changelog entry in the .spec will be something like: - rebuilding just for the sake of not getting a nonsense bug report opened against the package -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Tomas Mraz wrote: On Mon, 2010-01-18 at 14:04 -0500, Seth Vidal wrote: On Mon, 18 Jan 2010, Tomas Mraz wrote: I think there should be at least two conditions which would have to be fulfilled for the nagging bug to be created - the package was not touched by the maintainer during recent x months and at least one bug is opened not closed in the bugzilla on the package. I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are: 1. extraordinarily stable 2. dead upstreams 3. unmaintained 4. unusued in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. So that means that for example for the openoffice.org-dict-cs_CZ package I'll get the nag bug report before each and every Fedora release? It is definitely not 4. however 1. and 2. apply to it. As this is just a czech spelling and hyphenation dictionary which is pretty good one and we do not have any alternative anyway I do not think that 2. matters much. OK, I think my next changelog entry in the .spec will be something like: - rebuilding just for the sake of not getting a nonsense bug report opened against the package Really? We need all this drama? I have another radical idea - we could whitelist all sorts of things which are unchanging and yet used. We could act like reasonable folks and realize that one extra bug report A YEAR that you have to close as 'fixed' is really not that big of a deal. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, Jan 18, 2010 at 02:04:14PM -0500, Seth Vidal wrote: I disagree about the bug being open. A lack of filed bugs could mean that no one CARES about the pkg at all. And if we have pkgs which are not being maintained AND no one cares enough to file a bug about then either they are: 1. extraordinarily stable 2. dead upstreams 3. unmaintained 4. unusued in ANY of those cases I'd want to start thinking about nuking the pkg from fedora. I would like to have more packages matching case 1 in Fedora! ;-) But I guess as soon as you look at non GUI packages that have a specialized use case, you will find a lot packages that do not need to be updated that often once they are old enough. I use most of my packages, that are extraordinarily stable regularly. Upstream might be dead (or is in at least one case), but as far as they work for me without any problems, I do not see any problem there. If there is no change, there is also a less higher change that something is breaking. Examples of my packages: latex-mk, last change by me was 2007-07-28 and I know people who are using it daily with me being the first contact in case of problems. But there are none. Then next example, fcgi. One change since 2007-08-23 by me (and two by Chris Weyl because of perl changes). Works fine for me every day for at least one service using fastcgi. Maybe there are more, I do not remember which do depend on it, but I know one that definitly does. Then there is unclutter, the tarball is from 1994 and it still does it's job without any problems: hiding the mouse cursor when it's idle. Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either. Regards Till pgprqFWzcPR35.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, Jan 18, 2010 at 02:32:10PM -0500, Seth Vidal wrote: I have another radical idea - we could whitelist all sorts of things which are unchanging and yet used. We could act like reasonable folks and realize that one extra bug report A YEAR that you have to close as 'fixed' is really not that big of a deal. First of all, that would be two bug reports per year, as we have a 6 month development cycle. But it also will not be that useful, as we already have three things that have to be done by every maintainer once or twice a year, so they can be easily used to track, whether or not a maintainer is still around at all: FAS password, Koji certificate Bugzilla password. Then if you intend to catch unused packages, this will also fail unless you also plan to implement some captcha for this for every package, because there will be a script that a maintainer can run to close all bugs for all of his packages at once, even for the packages he does not maintain properly. So you will still only track down, whether or not a packager is still around and not whether he cares about a certain package. Regards Till pgpUQ1OGz3liF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote: On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote: Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either. Often maintainers don't realize they have some of these packages, or the maintainers have left the project. Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year. In fact, if we were only checking once a year, I bet many of these packages are going to get hidden behind the mass rebuilder. But these rebuilds are mostly automated ones by Fedora releng and as such not countable against the nag bug report. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote: On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote: Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either. Often maintainers don't realize they have some of these packages, or the maintainers have left the project. Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year. The problem with this is that we mass rebuild for it. In the early days we had one or two massrebuilds that weren't automated in order to catch packages that were no longer maintained. We could go back to that model but is it desirable? -Toshio pgpd21j4dC1js.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, Jan 18, 2010 at 02:55:36PM -0500, Seth Vidal wrote: Yes, I believe the expression you're looking for is: Perfect is the enemy of the good What is being suggested is not perfect. It is, however, good. Here we disagree. As I explained I see little use in it, since there are other methods that work at least as good as this on, but are less annoying. And they might even perform better, wrt to the challenge to find unmaintained packages. Or in other words, I do not trust in the mass bugfiling method, so the other methods still need to be implemented to get the information I am interested in. Also I cannot remember any argument from you that explains why your solution is superior to the other solutions. Regards Till pgpHW48v52mha.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 18 Jan 2010, Till Maas wrote: Often maintainers don't realize they have some of these packages, or the maintainers have left the project. Do maintainer really often forget, that they own a certain package? Ok, maybe if they are forced to do this from Red Hat, I do not know. But I am happy for every package that I do not have to maintain. But I think packages with no bug reports because they are not used are also not that big of a problem if they exist, unless they are really big or take very long to be rebuilt. It's imho at least not a problem that needs to be checked for every year. Or can you point to any known issues because of such packages since Fedora started? Sure - we're expanding with no end in sight. Every pkg increases the load of metadata and crap that EVERYONE has to download and has to deal with. If we have pkgs which are NOT being used then we can save everyone the bandwidth. Let's call it a cleanliness thing. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 16:22 -0500, Seth Vidal wrote: I've not heard any other solutions which aren't oh just let it be. It might have been missed in the passing but: We have to reset our bugzilla password frequently We have to renew our Koji cert once a year We should be able to detect when either of those goes wrong, probably easiest to do the koji cert one. If there was some way to take the list of accounts in pkgdb, and compare them to the active valid certs, and any discrepancies where the account owns packages, we can tag those for needing attention. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 15:08 -0500, Toshio Kuratomi wrote: On Mon, Jan 18, 2010 at 11:55:13AM -0800, Jesse Keating wrote: On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote: Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either. Often maintainers don't realize they have some of these packages, or the maintainers have left the project. Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year. The problem with this is that we mass rebuild for it. In the early days we had one or two massrebuilds that weren't automated in order to catch packages that were no longer maintained. We could go back to that model but is it desirable? Not in the least. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 13:39 -0800, Jesse Keating wrote: It might have been missed in the passing but: We have to reset our bugzilla password frequently We have to renew our Koji cert once a year We should be able to detect when either of those goes wrong, probably easiest to do the koji cert one. If there was some way to take the list of accounts in pkgdb, and compare them to the active valid certs, and any discrepancies where the account owns packages, we can tag those for needing attention. To be fair, this is a Maintainer down approach, as opposed to a package up approach. Seth is looking at this from the package point of view, where as the above looks at it from a maintainer point of view. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Mon, 2010-01-18 at 11:55 -0800, Jesse Keating wrote: On Mon, 2010-01-18 at 20:44 +0100, Till Maas wrote: Imho the only real problem from your list is, if a package is unmaintained, because if it is maintained, the maintainer usually uses it, otherwise he would just drop it. If upstream is dead but the maintainer fixes bugs, when they are found, I do not see a problem, either. Often maintainers don't realize they have some of these packages, or the maintainers have left the project. Even your most stable packages get touched nearly once a year due to distribution changes. With a more active rpm upstream I suspect we'll be seeing even more need to rebuild everything, at least once a year. In fact, if we were only checking once a year, I bet many of these packages are going to get hidden behind the mass rebuilder. So...the argument is we should worry about packages that don't get touched every six months, but no-one should be bothered about this, because everything gets touched at least every six months, even if it's not by the maintainer so the touch doesn't prove anything one way or another about the activeness or otherwise of the maintainer? I'm a bit lost. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote: On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensou...@till.name wrote: Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can. No, please go ahead. I took the liberty right after I posted. Did also contact the recordmydesktop maintainer? Regards Till pgpuaFlExPW4I.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, Jan 15, 2010 at 02:06:09PM -0600, Matt Domsch wrote: On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote: On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote: On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote: The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already. At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so. I made sure that no one who fixed a package was actually the package owner. Pre-orphaning: [...] The list of packages you announced that are going to be orphaned and the list of packages that were orphaned are not the same. recordmydesktop was on the to-be-orphaned list but afaics was not orphaned and also was not mentioned in your list about which provenpackager fixed which package. Regards Till pgpUbWl855vFU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, Jan 15, 2010 at 1:58 PM, Till Maas opensou...@till.name wrote: perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell There is a minor error: I fixed the -Simple package with a patch submitted in the upstream bugtracker iirc 7 days ago. But I also noticed that the -Mirror package was removed from debian. The SVN::Mirror module seems to have problems with subversion 1.6. The author doesn't seem to have done anything with the module since 2008 including responding to the upstream bug. It will probably need to be removed since I don't have the knowledge to fix it. The perl-SVK package requires perl-SVN-Mirror but it is for an optional feature. I could make a new package that removes the dependency. But what about the other packages from this maintainer? He maintains around 36 other packages: https://admin.fedoraproject.org/pkgdb/users/packages/iburrell E.g. the jigdo packages also has 4 bug. I looked at two an both did not receive any comments from the maintainer: https://bugzilla.redhat.com/show_bug.cgi?id=426847 https://bugzilla.redhat.com/show_bug.cgi?id=503833 Therefore the non responsive maintainer procedure, i.e. orphaning all packages from the affected maintainers, seems to me to be more appropriate. Sorry, I have been neglecting my packages for all the usual reasons. I'll give them the attention they need. - Ian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010, Matt Domsch wrote: We could easily create a new class of bugzilla ticket, say MAINTAINED. An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think). With a slight modification, my ftbfs bugzilla script could generate the tickets. Thoughts? I like the idea. I like it even more if we could make a make-target for saying I'm here, shut the hell up so it can be done easily. So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug on any of the pkgs which has not had any change in a full release. that should narrow the number of bugs he has to deal with, I'd think. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On 01/16/2010 03:50 PM, Matt Domsch wrote: On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote: With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm. We could easily create a new class of bugzilla ticket, say MAINTAINED. An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think). With a slight modification, my ftbfs bugzilla script could generate the tickets. Thoughts? I don't like this idea, because I don't see how this is would be essentially different from the AWOL process. The only difference would be, with proposal non-reponsive maintainer would be urged to take action on one package otherwise you'll loose ownership on this package vs. take action on one or package, otherwise you'll loose ownershp on all packages as with the AWOL process. That said, I seriously think, * non-responsive maintainers should be confronted with an AWOL-process in all cases of non-responsiveness. They always have the opportunity to take action. * we might need a better, formalized AWOL process. Also consider that FTBS breakdowns only are one situation amongst many similar situations of non-responsive maintainers - I don't see any need to special case FTBS. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sun, Jan 17, 2010 at 10:46:18PM -0500, Seth Vidal wrote: On Sat, 16 Jan 2010, Matt Domsch wrote: We could easily create a new class of bugzilla ticket, say MAINTAINED. An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think). With a slight modification, my ftbfs bugzilla script could generate the tickets. Thoughts? I like the idea. I like it even more if we could make a make-target for saying I'm here, shut the hell up so it can be done easily. So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug on any of the pkgs which has not had any change in a full release. that should narrow the number of bugs he has to deal with, I'd think. yes, it would. Help generating the list of (packages which have not been rebuilt since X except by the rel-eng rebuild script) would be welcome. I do have a concern with how bugzilla will handle mass filing 9000 bugs in one fell swoop. Perhaps pkgdb would be a more appropriate tool to do this in? Just a thought. I agree FTBFS isn't really special-case. It only highlighted the 30 or so packages which were truly unloved for a long time (no rebuild to f12 or f13). My goal with FTBFS is to ensure the whole distro is self-hosting; it has the side effect of noticing packages that prevent this. FESCo wasn't ready to declare the owners thereof non-responsive, they just wanted to prepare the distro for the possibility of the packages being removed, which orphan status on the specific package does do. But note: there are 2 cases we're dealing with: 1) the owner has updated some of their packages (so, responsive to some), but unresponsive to others (FTBFS, other longstanding unresolved bugs) 2) the owner hasn't updated _any_ of their packages in some time, even in presence of filed bugs (non-responsive maintainer). It's worth distinguishing, as case 1) calls for selective orphaning of packages (just the ones not getting the attention necessary), whereas case 2) calls for orphaning all the owner's packages. Ideally in case 1) the owner, being still somewhat responsive, would choose to orphan their unloved packages themselves. The other thing to remember is that it doesn't have to be a badge of shame to have your packages orphaned, or for you to orphan a package yourself. Individual's priorities and capabilities do change over time; we need a healthy way to gracefully let people bow out of maintaining some or all of their packages. And we do, I see orphan notices with others picking them up quite often on de...@. That's a sign of a healthy community. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 05:13:29 +0100, Ralf wrote: On 01/15/2010 08:17 PM, Matt Domsch wrote: At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. Well, if FESCO thinks this was a good idea ... I think you guys stopped half-ways: You better should have launched AWOL-processes against these maintainers. It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already. With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm. Makes me wonder what bugzilla status report scripts we have? To create a list of potentially unmaintained packages earlier and to detect packages with non-responsive owners. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
Hi, On 01/16/2010 12:14 AM, Jesse Keating wrote: On Fri, 2010-01-15 at 22:58 +0100, Till Maas wrote: But what about the other packages by these maintainers that do not fail to build but are probably as unmaintained as the packages that fail to build? Because this isn't a fully proper non-responsive maintainer approach, we felt it was only necessary to orphan the particular packages in question. These maintainers may have been active elsewhere, and wholesale orphaning with very little notice does not seem appropriate. I don't see who the orphaning without following proper procedure is appropriate at all. Simply blocking the ones which FTBFS bugs were not fixed from F-13 inclusion would have been the appropriate response (as documented in our procedures), not some adhoc almost random response. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
Hi, On 01/15/2010 08:17 PM, Matt Domsch wrote: On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote: The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already. At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so. awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628 evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451 geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494 gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780 gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591 Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617 knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487 libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470 ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200 perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749 perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984 perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570 perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964 perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770 perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729 prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64) python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675 qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688 recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931 skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202 smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362 synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195 unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553 widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717 Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great! Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ? Thanks, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 10:59:56 +0100, Hans wrote: On 01/15/2010 09:01 PM, Till Maas wrote: What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked. You know we have a procedure for this it is called the awol maintainer procedure and it would be nice if FESco would follow its on procedures here. Ah well I guess the rules don't apply to those who make them :( That view is overly pessimistic. We are in need of more automated procedures and more automated triggers. And we need to find ways how to detect non-responsive, inactive or overwhelmed contributors sooner. Fedora has grown out of proportions. It's good to see the community of contributors grow further, but in some areas it doesn't scale nevertheless. There is only a single package owner in pkgdb. A single person who is the default assignee of tickets in bugzilla. We should aim at making every assignee in bz a person who is responsive OR have enough co-maintainers on the watchbugzilla list to be responsive instead. It doesn't work well if arbitrary packagers keep alive a package without being the package's official maintainers -- and if the assignee is like /dev/null for problem reports or perhaps has left the project already. We can't wait for the one in a thousand bug reporters who will escalate a problem instead of resigning in disappointment. Two months without a reply, three months without a reply ... what to expect? FESCo ought to give the FTBFS tickets a special status. Unhandled FTBFS tickets will trigger the AWOL procedure for the assignee in bugzilla. The assignee will have to respond to the various pings and fix the package ownership in pkgdb if appropriate. A single reply in multiple weeks or an extended period of time. No harm is done if others need to take care of the package temporarily anyway. If somebody else has fixed the FTBFS meanwhile, consider yourself lucky. Then you've avoided the FTBFS-AWOL trigger, and some other monitoring software will need to detect non-responsiveness, inactivity, orphans. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote: It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already. In general I've been running the FTBFS scripts about monthly; maybe less so as we approach a release (nearly all packages get rebuilt, especially if there's a mass rebuild that happens). I think that's frequent enough to detect FTBFS; also we're not yet proposing dropping packages that don't rebuild in F13 yet; only those that never got rebuilt for F12. So the FTBFS now-orphaned packages are at 1 year old with no real progress to speak of. With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm. We could easily create a new class of bugzilla ticket, say MAINTAINED. An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think). With a slight modification, my ftbfs bugzilla script could generate the tickets. Thoughts? Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote: unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553 i fixed this, but i think we should still remove it because it has been superceded by the superior sunifdef. regards, kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 08:50:14AM -0600, Matt Domsch wrote: On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote: With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm. We could easily create a new class of bugzilla ticket, say MAINTAINED. An automated process would generate such tickets, blocking F13MAINTAINED. The ticket would ask the maintainer to close the ticket to remain the owner of the package. Tickets still open after $SOMEDELAY would be candidates for orphan or non-responsive maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release cycle (more would be too onerous I think). I do not like such artificial conditions that should show that a package is still maintained. It will bother all maitainers that already maintain their packages correctly. But this could be a techninal implementation but with other conditions when such tickets are created, e.g. these tickets could have been created for all maintainers still having FTBFS packages without commenting on their bug reports recently. But there could also be other conditions that trigger this, which still need to be implemented. Regards Till pgp8fjBzhp4NE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 11:12:03AM +0100, Hans de Goede wrote: widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717 Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great! Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ? My apologies. Issue fixed in the database, have assigned the two packages to you, and backporting the fixfor this that went into pkgdb trunk but hasn't gone to the production instance yet. -Toshio pgpvVby0KfSmQ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 10:39:54 +0100 Till Maas opensou...@till.name wrote: Indeed. I don't see much activity from them. Have you tried sending them an email? If not, I can. No, please go ahead. I took the liberty right after I posted. (Hopefully Ian doesn't mind me passing this along:) Ian Burrell wrote: I am still around but haven't been busy recently and haven't done anything with my packages. I'll take a look at this weekend. - Ian signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 11:08:30 +0100 Hans de Goede hdego...@redhat.com wrote: I don't see who the orphaning without following proper procedure is appropriate at all. Simply blocking the ones which FTBFS bugs were not fixed from F-13 inclusion would have been the appropriate response (as documented in our procedures), not some adhoc almost random response. These packages have failed to build for over a year. Sure, we could allow them to continue if someone steps in to build them, but then who is answering bugzilla tickets on them? Who is following upstream and updating them, in short: who is maintaining them? Not the maintainer of record it seems. if you want them to go on, take ownership. Sorry for the bug that prevented people from doing this, it's been fixed. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 16 Jan 2010 10:13:32 +0100 Michael Schwendt mschwe...@gmail.com wrote: It's a more fundamental problem, though. The AWOL-process is for people, not for packages. The people may still be active (and even known to be active somewhere) and not AWOL, but the packages which are assigned to them would still look orphaned. FTBFS is just one way to find packages that don't even build. However, if that happens, it may be much too late. Such a package may have been in an unmaintained desolate state for a long time already. With nobody handling the incoming bugzilla tickets. With some bug reports having been killed in an automated way at dist EOL. And worse if it turns out that packages which do build are unmaintained nevertheless, with the same symptoms in bugzilla and in package scm. Makes me wonder what bugzilla status report scripts we have? To create a list of potentially unmaintained packages earlier and to detect packages with non-responsive owners. Yeah, there was talk a while back about setting something up to try and detect poorly maintained/unmaintained packages, but I fear nothing ever came of it. I think it would be great to have some automated script that used a variety of input info to try and come up with a list of packages and/or maintainers who are not responsive. Unfortunately, this will be tricky to get right as there are a lot of corner cases: This could include: - Process bugzilla. Maintainers: How many bugs are assigned to each maintainer. How many of those have never had a comment by that maintainer. How many of those are over a month old How many of those are over a year old How many of those are over 5 years old. Packages: Packages with the most bugs (would need to weight somehow things like the kernel or X, and/or abrt bugs). Perhaps divide by co-maintainers? Packages that have upstream updates that haven't been acted on. -SCM Commits / Bodhi / Koji Packages: Packages that have had no SCM commits in a cycle. Packages that have had no updates in a cycle. Maintainers: Maintainers who have not commited to anything in a cycle Maintainers who have never submitted an update. Maintainers who have never built anything in koji. Maintainers who haven't built anything in a cycle. Maintainers who haven't built anything in a year. - Mail / FAS: Maintainers who have never posted to fedora* Maintainers who's fedora account system email bounces Maintainers who's fedora account system email is never responded to. Sponsors who have never sponsored anyone. Sponsors who have not sponsored anyone in a year. Sponsors who have not sponsored anyone in 5 years. - Planet: Maintainers who have a feed, but no posts. etc. You can see there is a lot of info out there, but much of it may not apply in reality. Ie, there is a package that doesn't update because it's quite stable. It has no bugs against it and the maintainer isn't doing anything else in Fedora. :) So, it might be nice to have such a tool and have it generate a list of possible maintainers/packages that need help. Then a human should look over the list and try and contact maintainers/gather info on packages and/or start unresponsive maintainer, etc. Any takers for writing such a script? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, 2010-01-16 at 10:59 +0100, Hans de Goede wrote: You know we have a procedure for this it is called the awol maintainer procedure and it would be nice if FESco would follow its on procedures here. Ah well I guess the rules don't apply to those who make them :( The non-responsive maintainer process is a rather lengthy and involved process, one which wouldn't lead to these packages being blocked in time. Due to that we decided it would be best to special case these and orphan them right away, so that this current set of packages can be dealt with appropriately. If a volunteer wishes to instigate a non-responsive process on all the maintainers, that is a separate matter which can happen concurrently to the current actions. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 12:47:35AM +0100, Hans de Goede wrote: Bad idea (says someone who owns 150 packages). I don't feel like getting 150 bugzilla mails and having to (mass) close them each release. OK; add a fedora-packager script that mass-closes bugs; or use the bugzilla web interface to select all bugs owned by you also blocking the blocker bug, and apply the same change to them all; again in one fell swoop. This is solvable. This may still not be the best approach, but it is possible and doesn't have to be onerous. -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 05:10:17PM -0600, Matt Domsch wrote: On Sat, Jan 16, 2010 at 12:47:35AM +0100, Hans de Goede wrote: Bad idea (says someone who owns 150 packages). I don't feel like getting 150 bugzilla mails and having to (mass) close them each release. OK; add a fedora-packager script that mass-closes bugs; or use the bugzilla web interface to select all bugs owned by you also blocking the blocker bug, and apply the same change to them all; again in one fell swoop. This is solvable. This may still not be the best approach, but it is possible and doesn't have to be onerous. We could also include a cron script, that does it all twice a year. ;-) There are already afaik three such timeouts that hit maintainers, can't we use this data? One is asked to change the password in FAS and bugzilla regularly and the client certificate to create builds and upload to the lookaside cache expire every 6 months iirc. Imho the solution to detect whether a package is still maintained should support maintainers as much as much is possible and not just be created in a way that's easy to implement, but highly annoying to maintainers. Regards Till pgpo2kApePfDB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, 2010-01-15 at 13:17 -0600, Matt Domsch wrote: Any package still orphaned as of the Feb 16 F13 Alpha freeze will be dropped per standard operating procedure. I might attempt to drop them a bit earlier than alpha freeze, so that if there is unexpected fallout we have time to fix it prior to the freeze. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote: On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote: The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already. At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so. What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked. Regards Till pgp50CIpi30sI.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote: On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote: On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote: The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already. At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so. What about the other packages of these maintainers? E.g. in the recordmydesktop case, there were four bugs open with working patches attached for that package. I did not yet check the other packages, but in case a packager does not have the time anymore to maintain one package from this list, why do we assume that he has the time to maintain the others? So before the mass orphaning is done, it would be nice to do it in a way that allows to at least easily spot which maintainers owned the packages before the orphage, so non responsive maintainers can be found easier. Or tell all maintainers in question and orphan all their packages. But the current solution seems to be only half-baked. I made sure that no one who fixed a package was actually the package owner. Pre-orphaning: evolution-brutus bpepple geronimo-specs fnasser gmfsk bjensen (fixed by caolanm) gnome-scan deji Io-languageorphan (fixed by caolanm) knm_new-fonts orphan libFoundation athimm ohmcjb (should be dead) perl-AnyEvent-XMPP allisson (WIP by spot) perl-Class-InsideOut cweyl (fixed by Ralf) perl-Jemplatecweyl (fixed by Spot) perl-MooseX-Traits-Attribute-CascadeClear cweyl (spot says kill it) perl-RRD-Simple cweyl (spot says kill it) perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it) perl-SVN-Simple iburrell prctl karsten qtiplot frankb skychart lkundrak smarteiffel orphan synce-kde awjb unifdef dwmw2 widelands karlik (WIP by hdegoede) xpilot-ng wart (fixed by hdegoede) xqilla10 orphan xqilla orphan -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
On Sat, Jan 16, 2010 at 05:13:29AM +0100, Ralf Corsepius wrote: On 01/15/2010 08:17 PM, Matt Domsch wrote: Unfortunately, this has proven to be hard/impossible so far. perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 I intended to take this one, but the packagedb doesn't offer me an option to take it: C.f.: https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut This package appears to be owned by owner orphan and doesn't offer the Take Ownership button, I see on packages listed on https://admin.fedoraproject.org/pkgdb/packages/orphans otherwise. Indeed, I see the same thing when logged in - no Take Ownership button. Toshio? -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
