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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux