Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)

Mattia Verga mattia.verga at tiscali.it
Sun Jan 15 19:37:16 UTC 2012


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 very important, however.


More information about the devel mailing list