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

Mattia Verga mattia.verga at tiscali.it
Mon Jan 16 17:47:32 UTC 2012


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.


More information about the devel mailing list