Re: Proposal for revitalizing the sponsorship process for packaging

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

 



On Thu, 26 Apr 2012 15:17:09 +0200, AL (Alec) wrote:

> I'm not talking about cooperation in that sense. I'm talking about a 
> more formalized way for people who want something packaged to find a 
> packager. As an alternative to force people without informal connections 
> to become packagers for a single package. Because there are many reasons 
> that's  a bad idea; you have listed some of them ;) Still, having a good 
> connection with upstream helps, especially in the initial phase IMHO.
> 
> Of couse, the theory fails if there is no volunteer packager. Same 
> applies to  for sponsorship. But packagers occasionally wants to package 
> things(?) and contacts with someone who wants the thing packaged 
> actually helps. Or?

Isn't the  wishlist  filled by _users_ rather than packagers?

One could ask the same for s/users/upstreamdevs/, i.e. an upstream
developer's interest in getting software included in the Fedora package
collection is not sufficient, if nobody volunteers to do the packaging
(which sometimes is a *lot* of effort due to bundled stuff or dozens
of unpackaged dependencies).
With regard to a single person showing interest in a package (with no
other existing packager being interested enough to be the reviewer), the
current sponsorship process is risky, because it makes it possible to join
quickly (==> with the sponsor fixing the package up to its approval) but
without the submitter having planned long-term commitment.

And for the second part, that somebody has "a good connection with
upstream", I'm not sure how that will help, *if* not even one packager
is available. Worse if the single person with interest in the software
also doesn't want to become the Fedora packager for it.

IMO, the whole co-maintainer dilemma is that once there is first packager
(aka "the package owner"), everyone else hopes that the package is taken
care of (read: the existing packager does all the work). Of course, in
case of bugs or a package getting out-of-date, still nobody is willing to
contribute.

Else it would work like this:

  1. find an area of interest, e.g. a package in need of fixes/updates/upgrades
  2. contact the current packager -->  SOURCERPMNAME-owner @ fedoraproject .org
     and ask whether co-maintenance access would be granted
     (of course, another dilemma here are non-responsive maintainers,
      but we have lists where to ask whenever somebody doesn't respond)
  3. if sponsorship is needed, propose the plan from steps 1+2 on a public
     list

For step 2, it would be interesting to learn which package owners would not
want to grant access and why.

Step 3 may need visible/perceivable motivation, perhaps a pointer to activity
in other parts of the Fedora Project (or outside of it), and possibly a pointer
to previous/past packaging work. Should be doable. Even if no RPM packaging
has been done before, oh my god, one could ask a sponsor to skim over a
proposed patch or revert a brown-paperbag commit in git even.


What I cannot take serious: if someone has submitted a package review
request in 2010 and in 2012 complains that the package is still in the queue.
If during such a long time, the submitter has not tried to review the own
package (or a different package in the queue) in accordance with the
guidelines. Very strange are also package submitters, who "talk to themselves"
by posting src.rpm updates in bugzilla without feedback from any reviewer,
but again without saying themselves "hey, I could take a look at the
ReviewGuidelines page myself and try to figure out whether my package is
ready, and if I think it's ready, join a list and announce that". 

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.2-8.fc17.x86_64
loadavg: 0.02 0.02 0.05
-- 
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