Re: [ACTION REQUIRED] Retiring packages for F-17
On 19 January 2012 23:23, David Tardon dtar...@redhat.com wrote: On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote: On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. Yes, I agree with this completely. If something is not being maintained in Fedora, it's better to retire it. Then a user who wants that piece of software will have two options: 1) They can build it and maintain it themselves on their own system(s) 2) They can choose to build and maintain it for Fedora by unretiring it. 3) They can choose another distro that contains the package(s). That is not a bad thing though. A) The user will be happier because they have support B) Our developers will be happier because they can focus on what they want to work on C) That distros developers will be happier because they have enough users that want what they are producing. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Tue, 17 Jan 2012 02:20:15 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: We talked about, but never finished implementing a timeout on acl requests. The way this would work is that maintainer would have some time.. 3 weeks or something to reject a acl request. If they did not do so, pkgdb would automatically approve it at the end of the time. This would help in cases where the maintainer is overloaded or not paying attention. The question is of course why we need to allow the maintainer to reject comaintainership in the first place. Sure. In an ideal world we never would. In the real world it might be that someone is a new maintainer and wanting to work on a package that is very complex or sensitive without much background, or someone who the current maintainers know they differ on philosophy or something that would make working together difficult, or a maintainer who doesn't get along with upstream and would cause undue friction, or a maintainer who doesn't communicate with existing maintainers well, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Thu, 19 Jan 2012 18:50:50 -0500 Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: ...snip... (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) This is an important point: I think it would be much less of a problem to retire packages if the process for unretiring them were not so painful. I _do_ think the unretiring process is an excellent example of unnecessary bureaucracy (as is the renaming process, good lord, what a PITA). Those two things could stand to be trimmed down. At least to 'if you're a provenpackager (or even just a sponsored packager) you can unretire a package without any obstacles'. If you file a FESCo ticket to change this policy, this approach would have my support. There's no reason that a package rename or unretirement should need to go through a full review (although as I said in an earlier email, the side-effect here is that such things can help curb specrot). There are two cases here: a) rename The changes involved in a rename are pretty minor. Just usually adding Obsoletes and Provides and changing the name in the spec file. That said, it's amazing how easy it is to get this wrong. It happens ALL THE TIME. ;) having a review to get another pair of eyes was decided to be the best way to avoid that. I tried (and failed) to get a lower bar for this. Perhaps current fesco would be interested. b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Once upon a time, Kevin Fenzi ke...@scrye.com said: b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Fri, 20 Jan 2012 17:15:57 -0600 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Kevin Fenzi ke...@scrye.com said: b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). Possibly, but that info isn't super easy to find. You would need to look at the scm-commits list to see when it was retired. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Once upon a time, Kevin Fenzi ke...@scrye.com said: On Fri, 20 Jan 2012 17:15:57 -0600 Chris Adams cmad...@hiwaay.net wrote: I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). Possibly, but that info isn't super easy to find. You would need to look at the scm-commits list to see when it was retired. If it was release-1 or release-2, those are both current and still getting updates; checking the current trees on a mirror would show if the package was in either release. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/17/2012 09:54 AM, Stephen Gallagher wrote: On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote: While that makes some sense, it was not my point. My point was that even if the package has NO maintainer, as long as it works, it's still better than no package at all! Not true. A package that appears to work, has people using it, but has no one maintaining it is likely to become a package that has exploitable security issues. I'm in favor of retiring unmaintained packages. At worst, it will encourage someone to step up to re-add it if it is actually important. I am more with Kevin on this one---absence of evidence of security is not evidence of absence of security. We should require actual manifestations of bit rot (bug reports, vulnerability records) before we consider abandoning packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) This is an important point: I think it would be much less of a problem to retire packages if the process for unretiring them were not so painful. I _do_ think the unretiring process is an excellent example of unnecessary bureaucracy (as is the renaming process, good lord, what a PITA). Those two things could stand to be trimmed down. At least to 'if you're a provenpackager (or even just a sponsored packager) you can unretire a package without any obstacles'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/19/2012 04:30 PM, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. I can see both points here. Is it worth it to create a repo / koji tag for 'unmaintained' packages? They automatically get put there and someone enabling it would hopefully know what that means. That way everyone is happy, someone who wants it around gets it, and can take ownership if they so choose, but the base set of packages is 'maintained'...? -- Nathanael d. Noblet t 403.875.4613 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. Yes, I agree with this completely. If something is not being maintained in Fedora, it's better to retire it. Then a user who wants that piece of software will have two options: 1) They can build it and maintain it themselves on their own system(s) 2) They can choose to build and maintain it for Fedora by unretiring it. Either way, they will not be given a false sense that the package is being maintained. (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) This is an important point: I think it would be much less of a problem to retire packages if the process for unretiring them were not so painful. I _do_ think the unretiring process is an excellent example of unnecessary bureaucracy (as is the renaming process, good lord, what a PITA). Those two things could stand to be trimmed down. At least to 'if you're a provenpackager (or even just a sponsored packager) you can unretire a package without any obstacles'. If you file a FESCo ticket to change this policy, this approach would have my support. There's no reason that a package rename or unretirement should need to go through a full review (although as I said in an earlier email, the side-effect here is that such things can help curb specrot). 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: [ACTION REQUIRED] Retiring packages for F-17
On 01/19/2012 11:30 PM, Adam Williamson wrote: This is an important point: I think it would be much less of a problem to retire packages if the process for unretiring them were not so painful. I_do_ think the unretiring process is an excellent example of unnecessary bureaucracy (as is the renaming process, good lord, what a PITA). Those two things could stand to be trimmed down. At least to 'if you're a provenpackager (or even just a sponsored packager) you can unretire a package without any obstacles'. I'm not so sure that the process is entirely to blame but probably to some extent and as with everything could be improved but these comments fell out of Dan's PrivateTmpfeature proposal which is just couple of days old. rgmanager is going away in 2/3 weeks from Fedora rawhide/F17. ricci is going away from Fedora rawhide/F17 in 2/3 weeks time. Now why if you know that you are going to orphan/remove components why do you have to do so late in the development cycle why cant this stuff be done immediately at branch time? The first thing to do is to remove what's not going to be in $next-release then proceed working on the stuff that actually will so those of us that are actually working on features and other stuff ain't wasting our time with something that will be removed *sometime* in the midst of the development cycle... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/19/2012 11:50 PM, Stephen Gallagher wrote: Yes, I agree with this completely. If something is not being maintained in Fedora, it's better to retire it. Then a user who wants that piece of software will have two options: 1) They can build it and maintain it themselves on their own system(s) 2) They can choose to build and maintain it for Fedora by unretiring it. Either way, they will not be given a false sense that the package is being maintained. Agreed and one thing that seems to be left out of this discussion is that we are spending resource on those unmaintained packages ( hw+releng/proven packagers for example ). Just to keep them rolling in and between releases which arguable could be better spent elsewhere like on package that actually are being maintained or to assist maintainers that are overloaded etc... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote: On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. Yes, I agree with this completely. If something is not being maintained in Fedora, it's better to retire it. Then a user who wants that piece of software will have two options: 1) They can build it and maintain it themselves on their own system(s) 2) They can choose to build and maintain it for Fedora by unretiring it. 3) They can choose another distro that contains the package(s). D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Thu, Jan 19, 2012 at 03:30:50PM -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. Do you have the numbers to prove that? Also note that not all packages contain code. (I just found leonidas-backgrounds-lion-dual-11.0.0-2.fc12.noarch on my machine. This package is most certainly unmaintained. Oh my god, my machine is insecure!) D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/17/2012 01:21 AM, Kevin Kofler wrote: While that makes some sense, it was not my point. My point was that even if the package has NO maintainer, as long as it works, it's still better than no package at all! I disagree packages without maintainers should not be shipped in the distribution and only waste the projects resources and can hinder feature process completion and of course can lead to users of those unmaintained components to leave the distribution because of bugs they experience aren't getting fixed... Better an small good distribution than bigger crappy one filled with unmaintained packages. ( quality vs quantity ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote: While that makes some sense, it was not my point. My point was that even if the package has NO maintainer, as long as it works, it's still better than no package at all! Not true. A package that appears to work, has people using it, but has no one maintaining it is likely to become a package that has exploitable security issues. I'm in favor of retiring unmaintained packages. At worst, it will encourage someone to step up to re-add it if it is actually important. This means a new package review, which is a good thing for dealing with specrot. 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: [ACTION REQUIRED] Retiring packages for F-17
On Tue, 17 Jan 2012 09:54:39 -0500, SG (Stephen) wrote: On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote: While that makes some sense, it was not my point. My point was that even if the package has NO maintainer, as long as it works, it's still better than no package at all! Not true. A package that appears to work, has people using it, but has no one maintaining it is likely to become a package that has exploitable security issues. Kind of a poor example, albeit a valid one, too. Any bug might have an impact. The general question of Who handles bug reports (including security related ones)? is still unanswered. It doesn't even need to be a real security vulnerability. Any bug report that isn't handled can lead to shipping software that doesn't work or doesn't work well enough. Worse if bug reports pile up with nobody responding to them. Fedora users are annoyed, if bugzilla appears to be no better than /dev/null. Perhaps there would not be just a team that rebuilds hundreds to thousands of unmaintained and possibly unused packages as needed, in Kevin's scenario there might be a Security SIG that would handle [properly tracked] security issues. That doesn't answer above question, however. I'm in favor of retiring unmaintained packages. At worst, it will encourage someone to step up to re-add it if it is actually important. This means a new package review, which is a good thing for dealing with specrot. So far so good, but disagreeing with the latter, because: Every approved Fedora Packager should be capable of discovering and getting rid of specrot. Just because we make mistakes occasionally (and because some packagers have messed up important Obsoletes/Provides before), doesn't mean we should punish all packagers with an extra review request. Releng could have the final say after reviewing the old dead.package file that must mention why a package had been retired previously. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/17/2012 05:26 PM, Michael Schwendt wrote: On Tue, 17 Jan 2012 09:54:39 -0500, SG (Stephen) wrote: On Tue, 2012-01-17 at 02:21 +0100, Kevin Kofler wrote: While that makes some sense, it was not my point. My point was that even if the package has NO maintainer, as long as it works, it's still better than no package at all! Not true. A package that appears to work, has people using it, but has no one maintaining it is likely to become a package that has exploitable security issues. Kind of a poor example, albeit a valid one, too. Any bug might have an impact. The general question of Who handles bug reports (including security related ones)? is still unanswered. It doesn't even need to be a real security vulnerability. Any bug report that isn't handled can lead to shipping software that doesn't work or doesn't work well enough. Worse if bug reports pile up with nobody responding to them. Fedora users are annoyed, if bugzilla appears to be no better than /dev/null. Well, you leave me no other choice but to pronounce something you probably don't want to hear: It's not uncommon to Fedora users to confronted with /dev/null style answers. It's just that they are called FIXED RAWHIDE, FIXED UPSTREAM or no reply and not explicitly labeled /dev/null ;) Perhaps there would not be just a team that rebuilds hundreds to thousands of unmaintained and possibly unused packages as needed, in Kevin's scenario there might be a Security SIG that would handle [properly tracked] security issues. I don't question such security issues/risks exist, but would question these are for real. IMO, the risks of being affected by security issues in new packages which had not seen wider use (or even security audits) is much larger than those in packages, which often had been in the wild for many years. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/17/2012 06:31 PM, Ralf Corsepius wrote: Well, you leave me no other choice but to pronounce something you probably don't want to hear: It's not uncommon to Fedora users to confronted with /dev/null style answers. It's just that they are called FIXED RAWHIDE, FIXED UPSTREAM or no reply and not explicitly labeled /dev/null ;) And is this generally considered to be acceptable and respectful behaviour to others in the community and Fedora's end user base? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
* Ralf Corsepius [17/01/2012 20:34] : It's not uncommon to Fedora users to confronted with /dev/null style answers. It's just that they are called FIXED RAWHIDE, FIXED UPSTREAM or no reply and not explicitly labeled /dev/null ;) Nitpick: There is no status FIXED in Fedora's bugzilla instance. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
Yes, with skychart I made some confusion: after a discussion on a forum I thought I can use a request for updating a package as a review ticket, but I soon realize that this wasn't possible. So I became a maintainer in the correct way and after that I asked privileges in pkgdb to become a co-maintainer... long story short: I admit I made confusion and I know I must contact directly the maintainer to discuss about packaging the new version and eventually to grant me such privileges. For the second point, I don't know if a new review should be really necessary only to verify the presence of obsoletes and provides: in my opinion if someone is a package maintainer he/she MUST already know how to rename a package and that this requires obsoletes and provides directives; just like he/she can modify an existing package without ask every time a review. Il 15/01/2012 21:57, Michael Schwendt ha scritto: On Sun, 15 Jan 2012 20:37:16 +0100, MV (Mattia) wrote: I'm just entered the world of Fedora packagers and I see a few points that can be optimized in my opinion. 1. I saw a package that need to be upgraded. I opened a bug in bugzilla, after some time whit no response from the maintainer I asked in pkgdb permissions for that package: I'm still waiting, after two weeks, that the maintainer gives me such permissions. That package is skychart according to the bugzilla searching I've done. The bugzilla ticket ( http://bugzilla.redhat.com/769454 ) raises a couple of questions. It could be that the assignee is confused so far (and the ticket has been opened on Dec 20th, btw). You wrote: | I'm not a packager, but I would like to became a co-maintainer. This could be confusing enough for the assignee to wait with approving your commit access request in pkgdb. Have you talked to him privately before, also about your pkgdb requests? Sometimes, pkgdb mails get filtered into special folders by users. An upgrade request in bugzilla with an immediate request to become a co-maintainer could be understood as some form of assault. I mean, not only would you (and the current co-maintainer) need to agree on the packaging anyway, you would also need to agree on how to team up in general (e.g. with regard to monitoring upstream commits and evaluating a new release). You've not commented on any changes in the new release. | I need a review of this package and a sponsorship, if possible. This is another confusing point. At least, I don't understand it yet either. The skychart packager cannot sponsor you if he's not a sponsor. He could apply forwarded spec changes, however. Submitting them as a unified diff (against current git, for example) could save some time. On the other hand, pkgdb lists two packages for your account, ... but as I said, this is confusing. So why I can take an orphaned package with automatic procedure and I cannot apply as co-maintainer in the same manner? An orphaned package would be unmaintained, that is first come first served for whoever is fastest to take it again. For packages with existing maintainers, you are supposed to talk to them about becoming a co-maintainer. Sometimes it just needs a private mail (and for others, IRC is even faster) to point them at pkgdb requests. 2. In review requests I see some of them are requests for existent packages that should be renamed. Why bothering reviewers (that are not so much, I think, looking at the long list of reviews pending) with this extra-work only to rename an existing package? Well, this is some form of unneeded bureaucracy. The http://fedoraproject.org/wiki/Package_Renaming_Process page is brief. It mentions proper Obsoletes and Provides, however, which might be a primary reason for expecting packagers to follow this process. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Mon, 16 Jan 2012 05:01:29 +0100 Ralf Corsepius rc040...@freenet.de wrote: On 01/16/2012 03:20 AM, Kevin Fenzi wrote: On Sat, 14 Jan 2012 18:28:15 +0100 Kevin Koflerkevin.kof...@chello.at wrote: Michael Schwendt wrote: However, with the current features of pkgdb, each member of such a group would need to subscribe to the package in pkgdb. Not just for commit access, but also for someone to monitor bugzilla and the package-owner mail alias, which is convenient for team-work, too. That's exactly why we need proper support for group ownership in pkgdb. In particular, a new developer joining a SIG should AUTOMATICALLY get write access to all the packages (co)maintained by that SIG. Exactly. How does one determine what SIGS exist? How does one determine who is a member of a SIG? How does one determine what packages a SIG controls? All these are the known deficiencies/missing features of Fedora's infrastructure (esp. the packagedb) - there simply is no concept of group ownership. My question is: what should the answers to these questions be? If you could make it work however you thought it would best work how would you answer them? I fear there's not any good answers to them without adding more layers to things and increasing red tape. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
Mattia Verga wrote: For the second point, I don't know if a new review should be really necessary only to verify the presence of obsoletes and provides: in my opinion if someone is a package maintainer he/she MUST already know how to rename a package and that this requires obsoletes and provides directives; just like he/she can modify an existing package without ask every time a review. +1 Those rename reviews are really just pointless bureaucracy, but I have been unsuccessful at fighting that nonsense. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Brendan Jones wrote: I agree! If a package is orphaned, can't we automatically escalate ownership to the next co-maintainer (when there is one - perhaps the one with the most commits for example). If a package is being orphaned for legitimate reasons, the owner should announce the intention to their co-maintainers first and they can opt to remove their ACLs before the package is orphaned. Its hard enough getting packages reviewed as is, let alone throwing a myriad of perfectly functioning packages back on the pile. While that makes some sense, it was not my point. My point was that even if the package has NO maintainer, as long as it works, it's still better than no package at all! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
Kevin Fenzi wrote: We talked about, but never finished implementing a timeout on acl requests. The way this would work is that maintainer would have some time.. 3 weeks or something to reject a acl request. If they did not do so, pkgdb would automatically approve it at the end of the time. This would help in cases where the maintainer is overloaded or not paying attention. The question is of course why we need to allow the maintainer to reject comaintainership in the first place. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/14/2012 07:12 PM, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) Kevin Kofler I agree! If a package is orphaned, can't we automatically escalate ownership to the next co-maintainer (when there is one - perhaps the one with the most commits for example). If a package is being orphaned for legitimate reasons, the owner should announce the intention to their co-maintainers first and they can opt to remove their ACLs before the package is orphaned. Its hard enough getting packages reviewed as is, let alone throwing a myriad of perfectly functioning packages back on the pile. Brendan (bsjones) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sun, Jan 15, 2012 at 11:48:35 +0100, Brendan Jones brendan.jones...@gmail.com wrote: On 01/14/2012 07:12 PM, Kevin Kofler wrote: I agree! If a package is orphaned, can't we automatically escalate ownership to the next co-maintainer (when there is one - perhaps the one with the most commits for example). If a package is being orphaned for legitimate reasons, the owner should announce the intention to their co-maintainers first and they can opt to remove their ACLs before the package is orphaned. Currently to change ownership you need to orphan the package first so that the co-maintainer can take ownership. There isn't a one step way to give away a package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sun, Jan 15, 2012 at 2:46 PM, Bruno Wolff III br...@wolff.to wrote: On Sun, Jan 15, 2012 at 11:48:35 +0100, Brendan Jones brendan.jones...@gmail.com wrote: On 01/14/2012 07:12 PM, Kevin Kofler wrote: I agree! If a package is orphaned, can't we automatically escalate ownership to the next co-maintainer (when there is one - perhaps the one with the most commits for example). If a package is being orphaned for legitimate reasons, the owner should announce the intention to their co-maintainers first and they can opt to remove their ACLs before the package is orphaned. Currently to change ownership you need to orphan the package first so that the co-maintainer can take ownership. There isn't a one step way to give away a package. He was talking about how the process should be improved not about the current state ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Bill Nottingham venit, vidit, dixit 13.01.2012 17:11: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. Orphan GREYCstoration Orphan adaptx Orphan ario Orphan armadillo Orphan asa comaintained by: pertusus Orphan autodafe Orphan avalon-framework Orphan avalon-logkit Orphan avl Orphan axis Orphan bcel Orphan bibexport comaintained by: pertusus Orphan bit Orphan blackbox Orphan blt Orphan bmake Orphan bsf Orphan bsh Orphan bwidget Orphan byaccj comaintained by: dbhole Orphan camstream Orphan castor Orphan ccsm Orphan compiz Orphan compiz-bcop Orphan compiz-fusion-extras Orphan compiz-fusion-unsupported Orphan compiz-manager Orphan compizconfig-backend-gconf Orphan compizconfig-backend-kconfig4 Orphan compizconfig-python Orphan concurrent Orphan conexus Orphan crcimg Orphan dbus-cxx Orphan dotconf Orphan eazykeyboard Orphan eclipse-setools Orphan eclipse-slide Orphan eclipse-systemtapgui Orphan eg Orphan eiciel Orphan erlang-erlzmq2 Orphan expatmm Orphan fortune-firefly Orphan freehdl comaintained by: chitlesh Orphan ganglia Orphan gestikk Orphan gget Orphan gimpfx-foundry Orphan gkrellm-volume Orphan gmime22 Orphan gnome-paint Orphan gnubversion Orphan gpx-viewer Orphan higlayout Orphan intellij-idea Orphan intuitively comaintained by: pertusus Orphan invulgotracker Orphan itaka Orphan itcl Orphan itk Orphan itools Orphan iwak Orphan iwidgets Orphan jakarta-commons-httpclient Orphan jps Orphan kcirbshooter Orphan kurdit-unikurd-web-fonts Orphan libcompizconfig Orphan libgnomeprint22 Orphan libgnomeprintui22 Orphan libmetalink Orphan libmodelfile Orphan libnoise Orphan libspe2 Orphan libsx comaintained by: pertusus Orphan libxdg-basedir Orphan libyahoo2 comaintained by: siddhesh Orphan lifeograph comaintained by: sundaram Orphan log4c Orphan lush Orphan maradns Orphan mathmap Orphan maxr comaintained by: cassmodiah Orphan mediawiki-rss comaintained by: ianweller Orphan medusa Orphan memchan Orphan metalink Orphan mingw32-OpenSceneGraph Orphan mingw32-SDL_image Orphan mingw32-SDL_mixer Orphan mingw32-plib Orphan mod_perlite Orphan monsoon Orphan mtkbabel Orphan mulk Orphan mysqlreport comaintained by: wolfy Orphan nanoxml Orphan netbeans Orphan nethack-vultures Orphan netstiff Orphan nsca comaintained by: xavierb Orphan olpc-netutils Orphan openbios Orphan papyrus Orphan perl-Acme-Damn comaintained by: ppisar psabata mmaslano Orphan perl-AppConfig-Std comaintained by: ppisar psabata mmaslano Orphan perl-Archive-RPM comaintained by: ppisar psabata mmaslano Orphan perl-Array-RefElem comaintained by: ppisar psabata mmaslano Orphan perl-B-Hooks-OP-Check-StashChange comaintained by: ppisar psabata mmaslano Orphan perl-Best comaintained by: ppisar psabata mmaslano Orphan perl-CPAN-Mini comaintained by: ppisar psabata mmaslano Orphan perl-CPANPLUS-Shell-Default-Plugins-Changes comaintained by: ppisar psabata mmaslano Orphan perl-CPANPLUS-Shell-Default-Plugins-Diff comaintained by: ppisar psabata mmaslano Orphan perl-CPANPLUS-Shell-Default-Plugins-RT comaintained by: ppisar psabata mmaslano Orphan perl-Cache comaintained by: ppisar psabata mmaslano Orphan perl-Chatbot-Eliza comaintained by: ppisar psabata mmaslano Orphan perl-Check-ISA comaintained by: ppisar psabata mmaslano Orphan perl-Class-Can Orphan perl-Class-DBI-Plugin-DeepAbstractSearch comaintained by: ppisar psabata mmaslano Orphan perl-Class-Data-Accessor comaintained by: ppisar psabata mmaslano Orphan perl-Class-Exporter Orphan perl-Class-Factory comaintained by: ppisar psabata mmaslano Orphan perl-Class-Prototyped comaintained by: ppisar psabata mmaslano Orphan perl-Config-IniHash comaintained by: ppisar psabata mmaslano Orphan perl-Context-Preserve comaintained by: ppisar psabata mmaslano Orphan perl-Contextual-Return comaintained by: ppisar psabata mmaslano Orphan perl-Convert-NLS_DATE_FORMAT comaintained by: ppisar psabata mmaslano Orphan perl-DBD-Mock comaintained by: ppisar psabata mmaslano Orphan perl-DBD-Multi comaintained by: ppisar psabata mmaslano Orphan perl-DBI-Dumper comaintained by: ppisar psabata mmaslano Orphan perl-DBIx-POS comaintained by: ppisar psabata mmaslano Orphan perl-Data-Denter comaintained by: ppisar psabata mmaslano Orphan
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
I'm just entered the world of Fedora packagers and I see a few points that can be optimized in my opinion. 1. I saw a package that need to be upgraded. I opened a bug in bugzilla, after some time whit no response from the maintainer I asked in pkgdb permissions for that package: I'm still waiting, after two weeks, that the maintainer gives me such permissions. So why I can take an orphaned package with automatic procedure and I cannot apply as co-maintainer in the same manner? 2. In review requests I see some of them are requests for existent packages that should be renamed. Why bothering reviewers (that are not so much, I think, looking at the long list of reviews pending) with this extra-work only to rename an existing package? In my opinion these two points can be modified to have less bureaucracy and to make things working a bit faster. Il 14/01/2012 13:03, Michael Schwendt ha scritto: On Sat, 14 Jan 2012 09:12:06 +0100, KK (Kevin) wrote: Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. Not if we make it a project-wide policy to upgrade whenever there isn't a strong reason not to (as I've been proposing all this time) and encourage provenpackagers (or even any packagers) to just upgrade the packages (unless the maintainer explicitly left a note in the specfile why it shouldn't be upgraded and the reason given actually makes sense), instead of discouraging it as we do now. Wow, that's a bit much for wrapping it into one sentence only! There is _a package_ with _a maintainer_. Is it an arbitrary maintainer or one assigned to the package's team of maintainers, who also handle incoming bug reports? Anyway, that maintainer has looked into performing an upgrade, but has found a reason not to upgrade and leaves a note in the specfile or a separate README in git. So far, so good. That reminds me of what I've been doing for Audacious during its troublesome v2 series. That is a basic idea, not a tested bullet-proof process, however. For example, what happens if an upgrade-mad maintainer thinks the notes in the spec file no longer apply? What happens if this is not (or cannot be) discussed for various reasons with the person that added the note? A single pet-peeve bug fixed in the latest upstream release could lead to a maintainer pushing forward an upgrade without taking care of the package normally. Conflict resolvement would be necessary. I'm not convinced that would be easy. Else there would not be regular threads-of-doom on the mailing-lists either. The system would lead quickly to some people accusing others of abusing their package write-access. What happens if there is no note and someone does an upgrade, which turns out to be broken in several ways? Who decides whether to downgrade (Epoch-fun!) or whether to try to fix the problems? And if the problems affect external packages and require porting to a new API (or require heavier development even), are there volunteer maintainers to do that for packages that are not being assigned to? Why is it so difficult to say I'm interested in many more packages, I want to contribute to those packages, and I do that either upstream or only in the Fedora packages, and in order to do so, I request pkgdb access to the packages in Fedora properly? Then you could find out whether team-work is possible with the existing maintainers. Why must it be the opposite? Arbitrary access to packages, possibly sporadic or random upgrades (as time permits), with no one taking care of the packages normally. With that, the policy would be: You think the software is old? You upgrade it. Problem solved. =:-o That's all? Software is old, replace it? You must be kidding. Especially Fedora's users expect the distribution makers to offer the full show: Everything from choosing a working combination/collection of software to testing/QA, integration-work, and maintaining all this during the life-time of the distribution. If software is new but broken, users turn that against you. Even if this is Fedora and not RHEL. real PITA to resurrect them. (If I want to pick up a package I missed in one of the previous retiring announcements, I have to get it through all the review process again just as if it had never been in Fedora!) This is almost ridiculous. The reason you've missed it could very well be that the package doesn't interest you at all and that you've not had a look at it (or its http://bugz.fedoraproject.org/NAME page) before. You haven't taken care of it in the package collection either. And if you've discovered the software just recently, would you be its only user in Fedora? Nobody else? Perhaps just a few users who run with a personal repo or a 3rd party repo on the web? Impressive. And finally, I'm almost certain FESCo could be approached with a proposal to have provenpackagers not require a re-review of previously retired packages. The reason they have been retired is
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sun, 15 Jan 2012 20:37:16 +0100, MV (Mattia) wrote: I'm just entered the world of Fedora packagers and I see a few points that can be optimized in my opinion. 1. I saw a package that need to be upgraded. I opened a bug in bugzilla, after some time whit no response from the maintainer I asked in pkgdb permissions for that package: I'm still waiting, after two weeks, that the maintainer gives me such permissions. That package is skychart according to the bugzilla searching I've done. The bugzilla ticket ( http://bugzilla.redhat.com/769454 ) raises a couple of questions. It could be that the assignee is confused so far (and the ticket has been opened on Dec 20th, btw). You wrote: | I'm not a packager, but I would like to became a co-maintainer. This could be confusing enough for the assignee to wait with approving your commit access request in pkgdb. Have you talked to him privately before, also about your pkgdb requests? Sometimes, pkgdb mails get filtered into special folders by users. An upgrade request in bugzilla with an immediate request to become a co-maintainer could be understood as some form of assault. I mean, not only would you (and the current co-maintainer) need to agree on the packaging anyway, you would also need to agree on how to team up in general (e.g. with regard to monitoring upstream commits and evaluating a new release). You've not commented on any changes in the new release. | I need a review of this package and a sponsorship, if possible. This is another confusing point. At least, I don't understand it yet either. The skychart packager cannot sponsor you if he's not a sponsor. He could apply forwarded spec changes, however. Submitting them as a unified diff (against current git, for example) could save some time. On the other hand, pkgdb lists two packages for your account, ... but as I said, this is confusing. So why I can take an orphaned package with automatic procedure and I cannot apply as co-maintainer in the same manner? An orphaned package would be unmaintained, that is first come first served for whoever is fastest to take it again. For packages with existing maintainers, you are supposed to talk to them about becoming a co-maintainer. Sometimes it just needs a private mail (and for others, IRC is even faster) to point them at pkgdb requests. 2. In review requests I see some of them are requests for existent packages that should be renamed. Why bothering reviewers (that are not so much, I think, looking at the long list of reviews pending) with this extra-work only to rename an existing package? Well, this is some form of unneeded bureaucracy. The http://fedoraproject.org/wiki/Package_Renaming_Process page is brief. It mentions proper Obsoletes and Provides, however, which might be a primary reason for expecting packagers to follow this process. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sun, 15 Jan 2012 18:39:48 +0100 Michael J Gruber michaeljgruber+gm...@fastmail.fm wrote: ...snip... (Please trim you emails...) Took bibexport. mathmap seems to be dead upstream as a Gimp plugin, unfortunately. (It's supposed to be turned into a web service...) While it's a pitty to see it go away, pampering the final version in Fedora appears to be futile. And yes, I feel quite uneasy about this mass removal, too. I mean, it affects even packages with comaintainers when the owner disappeared for whatever reasons. In this case the co-maintainers should have been seeing bounce emails for any commit against the package from the missing maintainer. They also should see that it's orphaned in the above list and should consider one of them taking over ownership. Unless I'm using a package already, I'd have to check what it does, what state it is in etc. before taking ownership - but it's gone by that time already, requiring much more paperwork to take over. well, we still have a good deal of time before any of the packages on this list are retired. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sun, 15 Jan 2012 20:37:16 +0100 Mattia Verga mattia.ve...@tiscali.it wrote: I'm just entered the world of Fedora packagers and I see a few points that can be optimized in my opinion. Welcome by the way. ;) 1. I saw a package that need to be upgraded. I opened a bug in bugzilla, after some time whit no response from the maintainer I asked in pkgdb permissions for that package: I'm still waiting, after two weeks, that the maintainer gives me such permissions. So why I can take an orphaned package with automatic procedure and I cannot apply as co-maintainer in the same manner? We talked about, but never finished implementing a timeout on acl requests. The way this would work is that maintainer would have some time.. 3 weeks or something to reject a acl request. If they did not do so, pkgdb would automatically approve it at the end of the time. This would help in cases where the maintainer is overloaded or not paying attention. 2. In review requests I see some of them are requests for existent packages that should be renamed. Why bothering reviewers (that are not so much, I think, looking at the long list of reviews pending) with this extra-work only to rename an existing package? It's very easy to mess up however, so we determined that a review was needed. Many times people don't do the obsoletes and provides correctly for the old name. In my opinion these two points can be modified to have less bureaucracy and to make things working a bit faster. Thanks for the ideas! kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
On 01/16/2012 03:20 AM, Kevin Fenzi wrote: On Sat, 14 Jan 2012 18:28:15 +0100 Kevin Koflerkevin.kof...@chello.at wrote: Michael Schwendt wrote: However, with the current features of pkgdb, each member of such a group would need to subscribe to the package in pkgdb. Not just for commit access, but also for someone to monitor bugzilla and the package-owner mail alias, which is convenient for team-work, too. That's exactly why we need proper support for group ownership in pkgdb. In particular, a new developer joining a SIG should AUTOMATICALLY get write access to all the packages (co)maintained by that SIG. Exactly. How does one determine what SIGS exist? How does one determine who is a member of a SIG? How does one determine what packages a SIG controls? All these are the known deficiencies/missing features of Fedora's infrastructure (esp. the packagedb) - there simply is no concept of group ownership. Likely, the simpliest apprach to implement group ownership would be handle this similar to provenpackager, but with limited/restricted privileges. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Michael Schwendt wrote: Are you trying to say the Fedora Project has made it much too easy for them to leave and have their account disabled, too? I'm saying that it's the ever-increasing bureaucracy which causes us to lose maintainers, that's all. No, it isn't. Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. Not if we make it a project-wide policy to upgrade whenever there isn't a strong reason not to (as I've been proposing all this time) and encourage provenpackagers (or even any packagers) to just upgrade the packages (unless the maintainer explicitly left a note in the specfile why it shouldn't be upgraded and the reason given actually makes sense), instead of discouraging it as we do now. With that, the policy would be: You think the software is old? You upgrade it. Problem solved. and I don't have the time to do it all alone anymore.) Which is proof that your entire proposal won't work either. No, it's not. If we all made it a habit to (and I believe that would be WITHIN our CURRENT policies, though a policy change actively encouraging this would be helpful) just rebuild packages with broken dependencies as we see them, there wouldn't ever be so many that a single person can't handle it (and even if there would, it wouldn't be a problem because it would NOT be a single person to do it). The problem only starts when it's only me! No. We need _more_ packagers, even if that means, many more _newbie packagers_. If there is at least one user for package, at least one of these users ought to contribute to the packaging. Easier said than done. Getting people to contribute that way has had very limited success, many users are just not interested in packaging (they come up with all sorts of excuses when I ask them the usual You want this software in Fedora? Why don't YOU package and maintain it? question), plus we're actually not making it easy at all to start packaging. Not only is there the endless bureaucracy which also annoys existing maintainers, but the sponsorship (and package review) process can also be a big hurdle. In the meantime, we're removing packages people actually need, and making it a real PITA to resurrect them. (If I want to pick up a package I missed in one of the previous retiring announcements, I have to get it through all the review process again just as if it had never been in Fedora!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Ralf Corsepius wrote: Do you realize that such demands for more people often are symptoms of a failing system? The common alternatives are to improve efficency and to improve productivity using those resources you have available. Approaches into this direction would be teaming up, less burecracy and a less volatile basis to work with. +1! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
- Original Message - From: Kevin Kofler kevin.kof...@chello.at To: devel@lists.fedoraproject.org Sent: Saturday, January 14, 2012 10:12:06 AM Subject: Re: [ACTION REQUIRED] Retiring packages for F-17 Michael Schwendt wrote: Are you trying to say the Fedora Project has made it much too easy for them to leave and have their account disabled, too? I'm saying that it's the ever-increasing bureaucracy which causes us to lose maintainers, that's all. No, it isn't. Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. Not if we make it a project-wide policy to upgrade whenever there isn't a strong reason not to (as I've been proposing all this time) and encourage provenpackagers (or even any packagers) to just upgrade the packages (unless the maintainer explicitly left a note in the specfile why it shouldn't be upgraded and the reason given actually makes sense), instead of discouraging it as we do now. With that, the policy would be: You think the software is old? You upgrade it. Problem solved. and I don't have the time to do it all alone anymore.) Which is proof that your entire proposal won't work either. No, it's not. If we all made it a habit to (and I believe that would be WITHIN our CURRENT policies, though a policy change actively encouraging this would be helpful) just rebuild packages with broken dependencies as we see them, there wouldn't ever be so many that a single person can't handle it (and even if there would, it wouldn't be a problem because it would NOT be a single person to do it). The problem only starts when it's only me! It's not only you. There are a bunch of guys doing all kind of distro-wide work in different areas - most of the time invisible to each other. And most of the broken packages for long time are packages that really don't have anyone interested with some people trying to rescue them (though I'm not sure that even if built they would work). To give an example in Java SIG we take care of packages that are generally useful and not some obsolete junk. So despite the fact that you see frysk, glib-java, cairo-java, gtk-java and etc. as packages with broken dependencies the truth is that these have been obsoleted by java-gnome for years but java-gnome is not a dropin replacement for glib-java, cairo-java... and people still try to keep them because of frysk instead of porting frysk to the new lib. That's fine by me everyone is free to do whatever he/she wants but in this example it's 3rd fedora release where these packages are on the list for removal and everytime someone takes them and doesn't maintain them after that ending with being orphaned for the next release and not building for most of the dev cycle. If it's only because of such examples - we need this procedure I would even love an automated removing of packages that are orphaned for more than 3 months. Note that this doesn't conflict with your idea of people doing upgrades everytime they see them. I actually love it and practice it on packages in my area of work. And I strongly encourage people to do so with my package but old junk should die it's just taking our precious time for no benefit. And yes I'm not ready to take packages just to deprecate them whenever I see them. Noone interested - it should die !!! Alex No. We need _more_ packagers, even if that means, many more _newbie packagers_. If there is at least one user for package, at least one of these users ought to contribute to the packaging. Easier said than done. Getting people to contribute that way has had very limited success, many users are just not interested in packaging (they come up with all sorts of excuses when I ask them the usual You want this software in Fedora? Why don't YOU package and maintain it? question), plus we're actually not making it easy at all to start packaging. Not only is there the endless bureaucracy which also annoys existing maintainers, but the sponsorship (and package review) process can also be a big hurdle. In the meantime, we're removing packages people actually need, and making it a real PITA to resurrect them. (If I want to pick up a package I missed in one of the previous retiring announcements, I have to get it through all the review process again just as if it had never been in Fedora!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: [ACTION REQUIRED] Retiring packages for F-17
Bruno Wolff III wrote on 2012-01-14: On Sat, Jan 14, 2012 at 03:54:08 +, Wei, Gang gang@intel.com wrote: If I pick up tboot package successfully asap, will it still be possible to be kept in F-17? Another message had the date the packages needed to be picked up by. I think it was February 7th. Thanks a lot, both messages you gave were quite informative. After change from IE to Chrome to make javascript work, I picked it up successfully. Jimmy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/13/2012 09:51 PM, Michael Schwendt wrote: On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote: When we're in danger of losing so many packages, it's a sign that our processes are broken: That's a dubious conclusion. Agreed the current process only highlights the underlying cause. There is no point in shipping packages in the distribution if there is nobody there to maintain it. * The forced password and SSH key change caused us to lose many maintainers, not all of whom would have become inactive if it hadn't been for such stupid asinine and totally useless (since the keys were NOT compromised) security bureaucracy being forced on them, wasting their time. Are you trying to say the Fedora Project has made it much too easy for them to leave and have their account disabled, too? Agreed here as well and I have to say that I also agree with how infrastructure team is handling. Their process both identifies who are no longer with the project and keeps it secure at the same time. What doesn't work is that we're supposed to sponsor people, who dump packages into the collection without really trying to take care of them afterwards. With no other users of those packages joining the team that tries to maintain the packages. With bug reports being ignored. With the initial packagers abandoning the Fedora Project without prior warning. Agreed. * The whole concept of packages being owned, and by one person at that, is broken. No, it isn't. Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. And someone dedicated, who would be reachable via bugzilla tickets. [Unfortunately, the latter doesn't work well anymore.] And someone to monitor upstream, or contribute upstream, and collaborate with upstream. [here insert stuff that has been discussed before] Agreed. Fedora as a whole should feel responsible for those packages, commit access should be open to ALL packagers (not just provenpackagers) as in the good old Extras, and there should be experienced packagers actually stepping in to rebuild packages with broken dependencies, fix FTBFS issues etc. (I used to do that, but I had to mostly give up because nobody else would help (Alex Lancaster used to help fixing broken dependencies, but mostly doesn't anymore) Well, that's not entirely true, because there are still provenpackagers, who rebuild broken deps _if_ they are affected by them. I see no reason why I should spend time on packages nobody else takes care of. The packages need more treatment than rebuilds. There are open bug reports, too. Agreed. and I don't have the time to do it all alone anymore.) Which is proof that your entire proposal won't work either. Agreed. Any package which is removed from Fedora is a package our users will no longer be able to use. Removing a package should only be a last resort if it cannot be made to work at all. No. We need _more_ packagers, even if that means, many more _newbie packagers_. If there is at least one user for package, at least one of these users ought to contribute to the packaging. Agreed with the added point that we also need to put limits on how many packages an single individual can own/maintain/co-maintain regardless of the nature of the package ( high maintenance/low maintenance). Finding that magic number should not prove too difficult something along the lines of 8 hour sleep + 8 hours work + 2 hours in meals + 2 hours recreation/family leaving 4 hours of the whole day to do various voluntary community stuff. Let's say on average it takes 30 minutes to deal with a single bug report against a component and let's say on average that each component in the project gets one report per day which gives us a maximum of 8 packages which an single individual can maintain or co maintain within the project so 8 would be that magic number. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sat, Jan 14, 2012 at 6:14 AM, Ralf Corsepius rc040...@freenet.de wrote: On 01/13/2012 10:10 PM, Bill Nottingham wrote: Sérgio Basto (ser...@serjux.com) said: The script that generated this page can be found at https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py This script is supposed to run on my laptop , if I have a fas account and keys to login on koji ? You can do that, yes. If someone take a package when the list will be modified ? I'll send out a few more reminders (about one per week) with updated lists, and will do a final check before packages are blocked. Could you please do this more often? Yes, please send updated lists more frequently. I've just taken a bunch of the perl packages, so things should already look a lot better. It would be nice for everyone to have a clear picture of what's left, though. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
2012/1/14 Jóhann B. Guðmundsson johan...@gmail.com: [snip] Agreed with the added point that we also need to put limits on how many packages an single individual can own/maintain/co-maintain regardless of the nature of the package ( high maintenance/low maintenance). Finding that magic number should not prove too difficult something along the lines of 8 hour sleep + 8 hours work + 2 hours in meals + 2 hours recreation/family leaving 4 hours of the whole day to do various voluntary community stuff. Let's say on average it takes 30 minutes to deal with a single bug report against a component and let's say on average that each component in the project gets one report per day which gives us a maximum of 8 packages which an single individual can maintain or co maintain within the project so 8 would be that magic number. You've got to be kidding. In a little over three years, I've picked up more than 300 packages and only 81 bugs - most of which are from upstream release monitoring. I've got no problem at all keeping up with the work. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sat, 14 Jan 2012 06:10:48 +0100, RC (Ralf) wrote: Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. ... but this someone doesn't have to be an individual nor does it have to be the package maintainer. It can be a group, it can be an expert or a group of experts etc. True. However, with the current features of pkgdb, each member of such a group would need to subscribe to the package in pkgdb. Not just for commit access, but also for someone to monitor bugzilla *and* the package-owner mail alias, which is convenient for team-work, too. The 1 package:1 owner model works in commercial environments, where supposed to be skilled professionals are supposed to be in _charge_ of customer care. It doesn't work well in an environment run by volunteers, who often are laymen, work in their spare time and can not be forced to anything. We are not being forced to apply this model. However: 1) Whenever a current owner (in terms of pkgdb) is lost for various reasons, often the co-maintainers in pkgdb don't want to continue with the packaging. Similarly, many current owners would rather like to get rid of a few package ownerships and welcome a first co-maintainer as an opportunity to transfer ownership. 2) More often than not, when I try to encourage a person (sometimes complainers, sometimes self-proclaimed heavy-users) to consider becoming a co-maintainer (who would be able to influence to package more than a passive user), I meet refusal or silence. I regularly try to recruit alleged Fedora users, talking to them and offering help. Typically, they are not (!) concerned about too much bureaucracy, but about lack of skills. It's way too easy to stay independent and retain the freedom to turn in a hardcore-Fedora-critic who threatens with distro-hopping. Some do that in private mail immediately after a reply to their bugzilla ticket, and suddenly you're the primary target of a user's accumulated grief with regard to various aspects of Fedora (not limited to MP3, Pulse Audio or GNOME Shell). No. We need _more_ packagers, even if that means, many more _newbie packagers_. Do you realize that such demands for more people often are symptoms of a failing system? Not immediately. If the only alternative is to open the flood-gates for the infamous dumping-ground of unmaintained packages - No, thanks. The common alternatives are to improve efficency and to improve productivity using those resources you have available. Approaches into this direction would be teaming up, less burecracy and a less volatile basis to work with. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/14/2012 10:44 AM, Iain Arnell wrote: You've got to be kidding. In a little over three years, I've picked up more than 300 packages and only 81 bugs - most of which are from upstream release monitoring. I've got no problem at all keeping up with the work. Nope no kidding with my example above and to point you out others are having difficulty's maintaining a single component with 300+ bugs on them ( like the kernel ). Expecting a maximum of 4 hours of volunteering per day from an individual on average in the project is not that far off ( and by some that number might be considered to high ) but ofcourse you can twist that math as much as you like to suit the outcome you would like to see. For example you can say I dont have a work and I dont have kids thus I should be allowed to maintain more packages but then you suddenly knock up a broad and land a job and the scenario becomes very much different... I personally fail to see this I maintain gazillion packages and I'm the best mentality that some seem to carry which more often than not they poorly maintain those gazillion packages and it would not take more then a bus accident to leave the project in limbo... I would think the projects goal here is to have more individuals maintaining the same package not one maintainer maintaining all the packages How many co-maintainers do you have on those 300 packages you maintain and how much time on average did you spend on fixing one of those 81 bugs ( from report to build with fix ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sat, 14 Jan 2012 09:12:06 +0100, KK (Kevin) wrote: Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. Not if we make it a project-wide policy to upgrade whenever there isn't a strong reason not to (as I've been proposing all this time) and encourage provenpackagers (or even any packagers) to just upgrade the packages (unless the maintainer explicitly left a note in the specfile why it shouldn't be upgraded and the reason given actually makes sense), instead of discouraging it as we do now. Wow, that's a bit much for wrapping it into one sentence only! There is _a package_ with _a maintainer_. Is it an arbitrary maintainer or one assigned to the package's team of maintainers, who also handle incoming bug reports? Anyway, that maintainer has looked into performing an upgrade, but has found a reason not to upgrade and leaves a note in the specfile or a separate README in git. So far, so good. That reminds me of what I've been doing for Audacious during its troublesome v2 series. That is a basic idea, not a tested bullet-proof process, however. For example, what happens if an upgrade-mad maintainer thinks the notes in the spec file no longer apply? What happens if this is not (or cannot be) discussed for various reasons with the person that added the note? A single pet-peeve bug fixed in the latest upstream release could lead to a maintainer pushing forward an upgrade without taking care of the package normally. Conflict resolvement would be necessary. I'm not convinced that would be easy. Else there would not be regular threads-of-doom on the mailing-lists either. The system would lead quickly to some people accusing others of abusing their package write-access. What happens if there is no note and someone does an upgrade, which turns out to be broken in several ways? Who decides whether to downgrade (Epoch-fun!) or whether to try to fix the problems? And if the problems affect external packages and require porting to a new API (or require heavier development even), are there volunteer maintainers to do that for packages that are not being assigned to? Why is it so difficult to say I'm interested in many more packages, I want to contribute to those packages, and I do that either upstream or only in the Fedora packages, and in order to do so, I request pkgdb access to the packages in Fedora properly? Then you could find out whether team-work is possible with the existing maintainers. Why must it be the opposite? Arbitrary access to packages, possibly sporadic or random upgrades (as time permits), with no one taking care of the packages normally. With that, the policy would be: You think the software is old? You upgrade it. Problem solved. =:-o That's all? Software is old, replace it? You must be kidding. Especially Fedora's users expect the distribution makers to offer the full show: Everything from choosing a working combination/collection of software to testing/QA, integration-work, and maintaining all this during the life-time of the distribution. If software is new but broken, users turn that against you. Even if this is Fedora and not RHEL. real PITA to resurrect them. (If I want to pick up a package I missed in one of the previous retiring announcements, I have to get it through all the review process again just as if it had never been in Fedora!) This is almost ridiculous. The reason you've missed it could very well be that the package doesn't interest you at all and that you've not had a look at it (or its http://bugz.fedoraproject.org/NAME page) before. You haven't taken care of it in the package collection either. And if you've discovered the software just recently, would you be its only user in Fedora? Nobody else? Perhaps just a few users who run with a personal repo or a 3rd party repo on the web? Impressive. And finally, I'm almost certain FESCo could be approached with a proposal to have provenpackagers not require a re-review of previously retired packages. The reason they have been retired is very important, however. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
2012/1/14 Jóhann B. Guðmundsson johan...@gmail.com: On 01/14/2012 10:44 AM, Iain Arnell wrote: You've got to be kidding. In a little over three years, I've picked up more than 300 packages and only 81 bugs - most of which are from upstream release monitoring. I've got no problem at all keeping up with the work. Nope no kidding with my example above and to point you out others are having difficulty's maintaining a single component with 300+ bugs on them ( like the kernel ). Then you can't blindly work the averages and apply hard limits. Just because some packages are high maintenance, doesn't mean that can't cope with dozens of low maintenance packages. Expecting a maximum of 4 hours of volunteering per day from an individual on average in the project is not that far off ( and by some that number might be considered to high ) but ofcourse you can twist that math as much as you like to suit the outcome you would like to see. For example you can say I dont have a work and I dont have kids thus I should be allowed to maintain more packages but then you suddenly knock up a broad and land a job and the scenario becomes very much different... I personally fail to see this I maintain gazillion packages and I'm the best mentality that some seem to carry which more often than not they poorly maintain those gazillion packages and it would not take more then a bus accident to leave the project in limbo... We just had this situation - cweyl left the project and his 300 or so packages were orphaned. Most are implicitly co-maintained by other members of perl-sig. The only difficulty is that pkgdb doesn't make it easy for other members of the sig to claim the particular packages they're most interested in - but we're coping and mostly have the situation under control. I would think the projects goal here is to have more individuals maintaining the same package not one maintainer maintaining all the packages How many co-maintainers do you have on those 300 packages you maintain and how much time on average did you spend on fixing one of those 81 bugs ( from report to build with fix ) I think every single package has perl-sig as co-maintainer. It's a shame there's no proper infrastructure to support group maintainership of packages, but we seem to get by with enough provenpackagers in the sig. And the time to fix bugs is generally quite short - probably no longer than the 30 minutes you guestimated earlier. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/14/2012 12:10 PM, Iain Arnell wrote: Then you can't blindly work the averages and apply hard limits. Just because some packages are high maintenance, doesn't mean that can't cope with dozens of low maintenance packages. That hard limit is based on an guestimated time it takes to fix a single bug from a guestimated free time an individual has to do so. As you mentioned that it took you around 30 minutes to fix one bug on average and I know for a fact that it takes me on average around 30 minutes to migrate legacy sysv init which is where that number initially comes from since the steps are similar in that regard as in. 1 .I first have to look at the component in question in koji to see if it is already shipping a unit file due to package maintainers not always dropping the legacy sysv init script or package it in a separate sub package as is stated by the guidelines. 2. I then have to look at all the bug reports filed against a component to see if someone else has already migrated the legacy sysv init script and submitted that. 3. if none of the above are true migrate the legacy sys init script and perform minimal testing. 4. submit that to bugzillla and flag the component inprogress in documentation So 30 minutes is not that far off as an guestimated average. Now 60(minutes)×4(guestimated available free hours)÷30( guestimated time it takes to fix) = 8 which means you as an individual can cover fixing bugs for 8 components per day which is the *worst case* scenario as in each day all of the 8 components receive one bug report but in more general terms I think it's safe to assume you can afford spending half an hour on average per day per individual component if you maintain 8 components in general maintenance tasks for those components. Soon as that number increases as in the time you have to spend in maintaining 8 components you slowly start painting yourself into a corner since you have to start taking the time from other activity's in your daily route and of course as reality has it also works the other way around your daily routine demands more of you thus you need start cutting down you package maintainership. People have tendency fooling themselves into they can handle it in the long run until things have escalated way out of their control which results from a package maintainership point of view things becomes more sloppy and the user base is screaming at them ( they essentially are working out issue because they have to not because they want to ) or from the individual perspective people become more isolated, cut down on general social activities, are at risk loosing their job and have their wife and kids screaming at them since they aren't paying any attention to them and we as a project loose them as a result of that. What I'm trying to say here is that there is a magic number ( it might be 8 it might be more but most likely it's less ) to how many packages single individual can properly and reliably maintain in the distribution. The rules become somewhat different with regards to the number of components with co-maintainership but you still have only those gestimated 4 hours to spend ( in reality this probably is a lower number ). And ofcourse none of those things applies if you are unemployed, have no social life, no girlfriend are living in your parents basement so in theory you can maintain as many packages as you like without it affecting you in anyway since you got all the time in the world... Arguable for everyone's benefits, the projects and the projects users and the maintainers and maintainers loved ones we should have a cab on how many components maintainers are allowed to maintain from my pov. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sat, 14 Jan 2012 14:03:32 + Jóhann B. Guðmundsson johan...@gmail.com wrote: On 01/14/2012 12:10 PM, Iain Arnell wrote: Then you can't blindly work the averages and apply hard limits. Just because some packages are high maintenance, doesn't mean that can't cope with dozens of low maintenance packages. That hard limit is based on an guestimated time it takes to fix a single bug from a guestimated free time an individual has to do so. ...snip... I think the time it takes to fix a bug varies so widely that there is no way to guestimate any 'average'. Some variables: * How good/stable the package is. * How active/good upstream is. * How complex the package is/what it does. * How many other packages it depends on where bugs may appear in interactions. I wouldn't personally even try and guess how long an 'average' bug take me to fix. There's really no average. What I'm trying to say here is that there is a magic number ( it might be 8 it might be more but most likely it's less ) to how many packages single individual can properly and reliably maintain in the distribution. I disagree there is any magic number here. I think people who feel overloaded or unable to process the bugs they are responsable for should look for interested co-maintainers to help them. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
...snip.. FWIW, I largely agree with Michael Schwendt here. Keeping packages around with no maintainers or people handling their bugs is poor for everyone. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
2012/1/14 Jóhann B. Guðmundsson johan...@gmail.com: On 01/14/2012 12:10 PM, Iain Arnell wrote: Then you can't blindly work the averages and apply hard limits. Just because some packages are high maintenance, doesn't mean that can't cope with dozens of low maintenance packages. That hard limit is based on an guestimated time it takes to fix a single bug from a guestimated free time an individual has to do so. As you mentioned that it took you around 30 minutes to fix one bug on average and I know for a fact that it takes me on average around 30 minutes to migrate legacy sysv init which is where that number initially comes from since the steps are similar in that regard as in. [snip] Now 60(minutes)×4(guestimated available free hours)÷30( guestimated time it takes to fix) = 8 which means you as an individual can cover fixing bugs for 8 components per day which is the *worst case* scenario as in each day all of the 8 components receive one bug report but in more general terms I think it's safe to assume you can afford spending half an hour on average per day per individual component if you maintain 8 components in general maintenance tasks for those components. I'm not disagreeing with 30 minutes per bug - just your guesstimate of one bug per package per day. Low maintenance packages are more like one bug per package per year. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
Michael Schwendt wrote: However, with the current features of pkgdb, each member of such a group would need to subscribe to the package in pkgdb. Not just for commit access, but also for someone to monitor bugzilla and the package-owner mail alias, which is convenient for team-work, too. That's exactly why we need proper support for group ownership in pkgdb. In particular, a new developer joining a SIG should AUTOMATICALLY get write access to all the packages (co)maintained by that SIG. We also need a policy that SIGs AUTOMATICALLY, and WITHOUT an option for the primary maintainer to opt out, get comaintainership of the class of packages they're experts for, e.g. the Perl SIG for perl-*, the KDE SIG for anything based on the KDE Platform (or even just on Qt as long as there's no separate Qt SIG) etc. A situation as we had recently where FESCo overturned a mass change to give a new Perl developer at Red Hat commit access to all Perl packages just makes no sense whatsoever. A new Perl SIG developer MUST get write access to all Perl packages; if that's against policy, it just means the policy is broken and needs to be fixed. And if there's no primary owner anymore, the ownership should just go to the SIG by default. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
Michael Schwendt wrote: Why must it be the opposite? Arbitrary access to packages, possibly sporadic or random upgrades (as time permits), with no one taking care of the packages normally. Because it's a much more effective use of our limited manpower. Everyone does what they currently have time for, without requiring a long-term commitment, the overhead of having to ask for commit access, discuss things with some assigned maintainer who thinks (because that's what he/she's told by the project) that he/she owns the package (all of which requires you to wait for the maintainer's answer, which wastes time and means you might no longer have free time when the answer finally arrives, plus, sometimes, you have to nag the maintainer several times to even get an answer at all) etc. I strongly believe that in the end, that would lead to MORE problems getting fixed, not fewer. This is almost ridiculous. The reason you've missed it could very well be that the package doesn't interest you at all and that you've not had a look at it (or its http://bugz.fedoraproject.org/NAME page) before. You haven't taken care of it in the package collection either. And if you've discovered the software just recently, would you be its only user in Fedora? Nobody else? Perhaps just a few users who run with a personal repo or a 3rd party repo on the web? Impressive. One example is smb4k. I hadn't noticed that because I don't use it myself, but more than one user has asked for it, and if it just required me to hit a button and then fix the occasional FTBFS issues every few months, I'd probably sign up for it. Going through the rereview process (plus the SCM admin request to unretire the package, plus the rel-eng request to unblock it) just exceeded my threshold of what I'm willing to do for a package I don't use, at least up to now (and it might also be hard to get somebody to actually do the rereview). Reportedly, the package was building and working just fine, so there was no practical reason for it to get retired in the first place, even though it had no assigned primary maintainer. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Jóhann B. Guðmundsson wrote: What I'm trying to say here is that there is a magic number ( it might be 8 it might be more but most likely it's less ) to how many packages single individual can properly and reliably maintain in the distribution. The rules become somewhat different with regards to the number of components with co-maintainership but you still have only those gestimated 4 hours to spend ( in reality this probably is a lower number ). First of all, if a package is maintained by 10 people, that divides the work by 10. If you don't take that into account, your proposal will actually discourage comaintainership instead of encouraging it, which is really the exact opposite of what you are trying to accomplish! Secondly, only 8 packages is a joke, we don't have remotely enough maintainers to be able to sustain such a low ratio of packages per maintainer. And finally, I don't agree with the idea of a hard limit, because different people have different amounts of free time and work at different speeds, and because different packages require different amounts of care. As an example, look at z88dk: http://pkgs.fedoraproject.org/gitweb/?p=z88dk.git You'll see that I haven't touched this package since 2009. And that was NOT because of laziness, but because there was literally nothing to change! There hasn't been a single bug filed, nor has there been a new upstream release (which would have led to a bug being filed thanks to Upstream Release Monitoring, but I just double-checked), since 2009. (In fact, the only 3 bugs ever filed against z88dk were an ExcludeArch tracking bug because the code was not 64-bit safe, which I fixed in 2007, and Upstream Release Monitoring bugs for 1.8 in 2008 and 1.9 in 2009.) Effort to maintain this package: basically zero. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sat, 14 Jan 2012 19:12:58 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Thats your preference. Some people would be better off with another supported package that does something similar, or even a package from an upstream thats more up to date or functional. Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) This doesn't apply to the vast majority of our users. Many would be upset when something doesn't work, and then even more upset when they learn no one is maintaining the package. kevin PS: I'll likely not continue to reply to this thread today. It's fudcon and I find argument by repetition a very poor rhetorical device. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Sat, 14 Jan 2012 18:45:28 +0100, KK (Kevin) wrote: Michael Schwendt wrote: Why must it be the opposite? Arbitrary access to packages, possibly sporadic or random upgrades (as time permits), with no one taking care of the packages normally. Because it's a much more effective use of our limited manpower. Everyone does what they currently have time for, without requiring a long-term commitment, the overhead of having to ask for commit access, discuss things with some assigned maintainer who thinks (because that's what he/she's told by the project) that he/she owns the package (all of which requires you to wait for the maintainer's answer, which wastes time and means you might no longer have free time when the answer finally arrives, plus, sometimes, you have to nag the maintainer several times to even get an answer at all) etc. I strongly believe that in the end, that would lead to MORE problems getting fixed, not fewer. Unconvincing. It could be that - nobody finds the time to take care of a specific package, - nobody has enough interest to monitor upstream development for the package, - nobody handles incoming bug reports for the package, - nobody really uses the package, some users give it a try, but perhaps it doesn't work well, - nobody can guarantee that the package (or a set of related packages) will still be _low maintenance_ type of packages next year (that could be due to upstream development or stuff getting ancient, and suddenly you're supposed to deal with old APIs and broken/unmaintained software), - everyone, who has touched the package over the past years, suddenly does not do that anymore -- you refer to no long-term commitment, but actually long-term commitment is needed, even if it means that a new maintainer supersedes the previous maintainer from time to time, and for a different package, - somebody apparently takes care of it, but somebody else all of a sudden applies an upgrade for no particular reason and then hides again. [package retirement process to cumbersome] One example is smb4k. I hadn't noticed that because I don't use it myself, Case closed I could throw in here then. ;) but more than one user has asked for it, And here, too. [that deserves a :-( smiley actually] and if it just required me to hit a button and then fix the occasional FTBFS issues every few months, I'd probably sign up for it. Going through the rereview process (plus the SCM admin request to unretire the package, plus the rel-eng request to unblock it) just exceeded my threshold of what I'm willing to do for a package I don't use, at least up to now (and it might also be hard to get somebody to actually do the rereview). Reportedly, the package was building and working just fine, so there was no practical reason for it to get retired in the first place, even though it had no assigned primary maintainer. It's somewhat tragic there's an endless loop already. If the package requires no to low maintenance, it is low-hanging fruit for newbies, too. And if nobody volunteers to take it, the loop restarts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Am 14.01.2012 19:12, schrieb Kevin Kofler: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! be careful with such assumptions without mind what this means for the integrity of your setup most time you will not know that it is unmaintained if yum install does the job, you expect it will get security fixes which will not happen in this case so if it is NOT maintained and has security bugs you will be the first start whining why it was not from the moment machine is compromised signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Kevin Fenzi wrote: Thats your preference. Some people would be better off with another supported package that does something similar, or even a package from an upstream thats more up to date or functional. That assumes such a package exists. I have no problems with packages getting retired when there's really a better replacement which covers the use cases of the original package (and ideally is officially designated as a successor), in which case there should also be Obsoletes in place. But in many cases, there is just no alternative at all to the dropped package, or at least none that's actually packaged in Fedora. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Losing package maintainers (Re: [ACTION REQUIRED] Retiring packages for F-17)
* Kevin Kofler [14/01/2012 22:06] : That's exactly why we need proper support for group ownership in pkgdb. I believe that this isn't going to happen unless the people who want it actually submit patches for pkgdb to implement it. Should it be none the less implemented by other people, there's a fair chance it will probably not work the way the way these people want it to work. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
eiciel, xmms-pulse (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Fri, 13 Jan 2012 11:11:13 -0500, BN (Bill) wrote: Orphan eiciel Taken since I've kept it alive last year, too. Orphan xmms-pulse This will need active development rather than just packaging, because it is still old code that causes problems meanwhile. Inspiration for changes that will be necessary could be derived from (or copied from) Audacious' Pulse Audio output plugin (which had started as a fork of xmms-pulse some years ago). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
I took libxdg-basedir for xmoto. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/13/2012 05:11 PM, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. I took the following packages, I already was co-maintainer for: - perl-Devel-StackTrace-AsHTML - perl-Test-TCP - perl-Test-SharedFork Additionally, I took these: - perl-Module-Versions-Report - perl-Test-WWW-Mechanize - perl-Time-Duration-Parse More are likely to follow. Note1: I took these for Fedora, only. Note2: How to remove oneself as co-maintainer in the packagedb? For those packages, I already was co-maintainer, I am now enrolled as both maintainer and co-maintainer. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Fri, Jan 13, 2012 at 11:23 AM, Ralf Corsepius rc040...@freenet.de wrote: On 01/13/2012 05:11 PM, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. I took the following packages, I already was co-maintainer for: - perl-Devel-StackTrace-AsHTML - perl-Test-TCP - perl-Test-SharedFork Additionally, I took these: - perl-Module-Versions-Report - perl-Test-WWW-Mechanize - perl-Time-Duration-Parse More are likely to follow. Note1: I took these for Fedora, only. Note2: How to remove oneself as co-maintainer in the packagedb? For those packages, I already was co-maintainer, I am now enrolled as both maintainer and co-maintainer. I think you just change the dropdown to the blank option. Not sure. -J Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
I took qbrew. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Fri, 13 Jan 2012 11:11:13 -0500 Bill Nottingham nott...@redhat.com wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. I took perl-Test-Simple, which will reduce the list of dependent packages substantially. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Fri, Jan 13, 2012 at 11:11:13 -0500, Bill Nottingham nott...@redhat.com wrote: The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. I have taken ownership of the following packages: fortune-firefly nethack-vultures sear sear-media skstream -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Bill Nottingham (nott...@redhat.com) said: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. If these packages are not claimed, they will be retired before we branch off of rawhide on February 7. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
I have taken these packages: avalon-framework avalon-logkit bcel bsf jakarta-commons-httpclient On Fri, Jan 13, 2012 at 2:37 PM, Bill Nottingham nott...@redhat.com wrote: Bill Nottingham (nott...@redhat.com) said: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. If these packages are not claimed, they will be retired before we branch off of rawhide on February 7. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
I took GREYCstoration. On Fri, Jan 13, 2012 at 3:03 PM, Kevin Kofler kevin.kof...@chello.at wrote: Bill Nottingham wrote: Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. When we're in danger of losing so many packages, it's a sign that our processes are broken: * The forced password and SSH key change caused us to lose many maintainers, not all of whom would have become inactive if it hadn't been for such stupid asinine and totally useless (since the keys were NOT compromised) security bureaucracy being forced on them, wasting their time. * The whole concept of packages being owned, and by one person at that, is broken. Fedora as a whole should feel responsible for those packages, commit access should be open to ALL packagers (not just provenpackagers) as in the good old Extras, and there should be experienced packagers actually stepping in to rebuild packages with broken dependencies, fix FTBFS issues etc. (I used to do that, but I had to mostly give up because nobody else would help (Alex Lancaster used to help fixing broken dependencies, but mostly doesn't anymore) and I don't have the time to do it all alone anymore.) And packages such as perl-* should just be owned (automatically) by the relevant SIG. * Depending on timing, some packages can end up retired with little to no time to pick them up first, e.g. in one case (avl), your mail threatens to retire a package less than 97 minutes (!) after it got orphaned. The time between the mass orphaning due to the security farce and the mass retiring (now) is also deeply insufficient, and there wasn't even one updated list of not yet picked up packages from the security fiasco (the original one contained way too many packages for packagers to notice the ones of interest) before this one which already threatens their removal. Any package which is removed from Fedora is a package our users will no longer be able to use. Removing a package should only be a last resort if it cannot be made to work at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Fri, 2012-01-13 at 11:11 -0500, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. But I think that many of then will be taken , like perl. A few thoughts: No maintainer doesn't mean, for me, no package maintained. So if history packages still working, I looked for some tcl(s) packages like itcl , if no good motive to orphaning , I can rebuild it :) But my the point is many people volunteer to maintain many package in above list. The script that generated this page can be found at https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py This script is supposed to run on my laptop , if I have a fas account and keys to login on koji ? If someone take a package when the list will be modified ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Sérgio Basto (ser...@serjux.com) said: The script that generated this page can be found at https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py This script is supposed to run on my laptop , if I have a fas account and keys to login on koji ? You can do that, yes. If someone take a package when the list will be modified ? I'll send out a few more reminders (about one per week) with updated lists, and will do a final check before packages are blocked. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/13/2012 11:11 AM, Bill Nottingham wrote: Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. Please add 'blktool' to this list. I just retired it in Fedora-devel today. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Dne 13.1.2012 21:03, Kevin Kofler napsal(a): time to pick them up first, e.g. in one case (avl), your mail threatens to retire a package less than 97 minutes (!) after it got orphaned. The time This is purely my fault ... nobody uses avl to the best of my knowledge, and I have just forgot to orphan it earlier. I don't think this is not your cause célèbre. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Michael Schwendt writes: What doesn't work is that we're supposed to sponsor people, who dump packages into the collection without really trying to take care of them afterwards. With no other users of those packages joining the team that tries to maintain the packages. With bug reports being ignored. With the initial packagers abandoning the Fedora Project without prior warning. I wonder how many of them abandoned ship because they suddenly found themselves dealing with – in their view – an unproductive, and hard-to-use desktop, in F-16. Or the fact that upgrading from one Fedora to release is no longer as smooth as it used to be, given – more or less – the de-emphasis of the upgrade path, with new installs being the preferred way. But, in any case, Fedora's gotten too big, in my view. Going on a weight- loss diet may not be such a bad thing. pgpoyARin5K8g.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: [ACTION REQUIRED] Retiring packages for F-17
If I pick up tboot package successfully asap, will it still be possible to be kept in F-17? Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. Orphan tboot comaintained by: gwei3 I have to pick up tboot package, but I failed to do it for several times. Any hints for how can I do it? I am the co-maintainer of tboot, below is my steps(failed) trying to take ownership of it: Login as gwei3, and enter tboot package url(https://admin.fedoraproject.org/pkgdb/acls/name/tboot), press take ownership buttons for Fedora devel/15/16, wait for a while then the buttons keeps as grayed, refresh the page, the package status is still orphaned. Jimmy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sat, Jan 14, 2012 at 03:47:47 +, Wei, Gang gang@intel.com wrote: Login as gwei3, and enter tboot package url(https://admin.fedoraproject.org/pkgdb/acls/name/tboot), press take ownership buttons for Fedora devel/15/16, wait for a while then the buttons keeps as grayed, refresh the page, the package status is still orphaned. The package database page for changing access requires javascript to work. It would be nice if it didn't, but I don't use it enough to feel like asking someone else to do a lot of work to save me from turning javascript on and back off again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Sat, Jan 14, 2012 at 03:54:08 +, Wei, Gang gang@intel.com wrote: If I pick up tboot package successfully asap, will it still be possible to be kept in F-17? Another message had the date the packages needed to be picked up by. I think it was February 7th. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/13/2012 06:49 PM, Jon Ciesla wrote: On Fri, Jan 13, 2012 at 11:23 AM, Ralf Corsepiusrc040...@freenet.de wrote: Note2: How to remove oneself as co-maintainer in the packagedb? For those packages, I already was co-maintainer, I am now enrolled as both maintainer and co-maintainer. I think you just change the dropdown to the blank option. Not sure. Thanks, this worked. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/13/2012 10:51 PM, Michael Schwendt wrote: On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote: When we're in danger of losing so many packages, it's a sign that our processes are broken: That's a dubious conclusion. I concur with Kevin. * The whole concept of packages being owned, and by one person at that, is broken. No, it isn't. To me, it's obvious, this concept doesn't work well anymore. Even in the scenario of project-wide write-access to packages, there must be someone to decide when to perform an upgrade. ... but this someone doesn't have to be an individual nor does it have to be the package maintainer. It can be a group, it can be an expert or a group of experts etc. The 1 package:1 owner model works in commercial environments, where supposed to be skilled professionals are supposed to be in _charge_ of customer care. It doesn't work well in an environment run by volunteers, who often are laymen, work in their spare time and can not be forced to anything. Fedora as a whole should feel responsible for those packages, commit access should be open to ALL packagers (not just provenpackagers) as in the good old Extras, and there should be experienced packagers actually stepping in to rebuild packages with broken dependencies, fix FTBFS issues etc. (I used to do that, but I had to mostly give up because nobody else would help (Alex Lancaster used to help fixing broken dependencies, but mostly doesn't anymore) Well, I also did several times, but often found me stuck in bureaucracy and often got stuck in a web of bugs elsewhere - in short, not a pretty tedious experience. Any package which is removed from Fedora is a package our users will no longer be able to use. Removing a package should only be a last resort if it cannot be made to work at all. No. We need _more_ packagers, even if that means, many more _newbie packagers_. Do you realize that such demands for more people often are symptoms of a failing system? The common alternatives are to improve efficency and to improve productivity using those resources you have available. Approaches into this direction would be teaming up, less burecracy and a less volatile basis to work with. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 01/13/2012 10:10 PM, Bill Nottingham wrote: Sérgio Basto (ser...@serjux.com) said: The script that generated this page can be found at https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py This script is supposed to run on my laptop , if I have a fas account and keys to login on koji ? You can do that, yes. If someone take a package when the list will be modified ? I'll send out a few more reminders (about one per week) with updated lists, and will do a final check before packages are blocked. Could you please do this more often? TIA, Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
