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: 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: 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: 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: 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: 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
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: 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: 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
