DevHeads.net

Proposal for revitalizing the sponsorship process for packaging

For a while now I have been working on a proposal for some changes to
both the way we elevate packagers to sponsors and what (to a small
extent) sponsors actually do. Please note that this is not a proposal
for any changes to how people are made members of the packager group in
the first place and does not change the privileges of existing sponsors.

My proposal is at
<a href="https://fedoraproject.org/wiki/User:Tibbs/RevitalizingSponsorshipProposal" title="https://fedoraproject.org/wiki/User:Tibbs/RevitalizingSponsorshipProposal">https://fedoraproject.org/wiki/User:Tibbs/RevitalizingSponsorshipProposal</a>

I've run this by FESCo, whose response was favorable, so I'm sending
this to a larger audience. Please let me know what you think.

- J<

Comments

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 05:01

There are a few unfortunate sections in the first paragraph already:

| users have to go through an almost endless set of steps (which also
| needs revision, but that's another topic)

Compared with a few years ago there are many newbie-packagers, who
apparently are not interested in the 'Packaging' related Wiki pages and
not in the 'ReviewGuidelines' either.

Such package[r]s in the review queue sit and wait for a reviewer to do
__all__ the work including most basic tasks like running rpmlint or
running a test-build. And that inspite of the Wiki documents being
detailed and helpful enough nowadays ... compared with the brief
QACheckList from ancient times. Things commented on by reviewers often are
applied to a spec file only reluctantly, without proper/clear
acknowledgement. A single "okay, I see" or "that makes sense" often would
make a difference.

With regard to 'mentoring', I favour people, who show better communication
skills and who are more responsive. I appreciate feedback, even if
somebody disagrees and wants to discuss the guidelines instead of simply
applying a spec file fix. Worse, however, are those who start with Fedora
criticism in either bugzilla or private mail (such as considering the
guidelines as needless bureaucracy and finding fool language for that
even). A negative point of view related to how Fedora does something is
not motivating potential sponsors.

A few years ago, when I received private mail from somebody about
sponsorship, my reply would result in either a longer thread where to
discuss something or in a short acknowledgement and work move into
the review request. Nowadays, private mail mentions the wish to be
sponsored, but communication stops at that point because pointing
at the PackageMaintainers Wiki entry page apparently is considered
too much homework for the people who mail me.

| and then pin their hopes on a review ticket that, due to an insufficient
| number of active sponsors, may not get looked at in a reasonable amount
| of time.

It's disappointing to see that your "activity report" does not cover
activity in the review queue. I may be one of those, who has not sponsored
anyone in the past year, but I post helpful (and detailed) review comments
regularly and encounter inactive package submitters both in the normal
queue and in the needsponsor queue. In the same way packagers cannot
guarantee to return with a reply in less than 1-3 months, I cannot
guarantee sponsoring somebody already with only a _single_ submitted package,
where I have had to point at the Packaging Documentation multiple times.

Also, I think it has become more important to be more careful about who to
sponsor, because we are facing a growing number of orphans due to
packagers leaving the project without notice, as well as packagers who
grab N>1 packages in pkgdb without actually handling them properly in
bugzilla (if at all).

| Make some criteria that sponsors need to meet if they wish to remain sponsors.

Forcing sponsors to fulfill such criteria is the wrong way IMO. It may
result in even more blanket-approval sponsorships.

Re: Proposal for revitalizing the sponsorship process for packag

By Jason L Tibbitts III at 04/26/2012 - 09:20

MS> There are a few unfortunate sections in the first paragraph already:

Except that they're all true.

That's not really within the scope of the document. I haven't proposed
lowering the standards for reviewing packages. And yes, this is a
problem, but as stated by the parenthetical note which you quoted, it's
not the problem I was targeting with my proposal.

MS> It's disappointing to see that your "activity report" does not cover
MS> activity in the review queue.

Since the focus of the document is sponsorship, simple activity in the
review queue was beyond the scope of what I'm trying to do. And in any
case, I did state that getting useful statistics out of bugzilla for
this is beyond what I am able to do. Maybe you could come up with some,
though; I'd certainly be happy to look at them.

MS> I may be one of those, who has not sponsored anyone in the past
MS> year, but I post helpful (and detailed) review comments regularly
MS> and encounter inactive package submitters both in the normal queue
MS> and in the needsponsor queue.

And that's great, thanks.

MS> Forcing sponsors to fulfill such criteria is the wrong way IMO. It
MS> may result in even more blanket-approval sponsorships.

I don't happen to agree, but at some point shouldn't sponsors do
something? Otherwise why do they have permission? What do you suggest
as expanded criteria for keeping sponsor access? Or do you advocate no
criteria at all, and sponsorship is lost by vote? Or are you saying it
should never be lost once gained?

- J<

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 10:43

Are we talking past eachother? :-/

What if sponsors _try_ but for some time haven't found anyone who
shows enough interest in the Fedora Packaging?

Or, for example, recently I've rejected sponsorship for someone, who used
strong language when referring to Fedora's packaging related requirements
(and, uhm, this time the person has not even tried to excuse/explain, so no
chance to get to know that person).

In another case, I've worked on multiple review requests by the same person,
but silently (= without communication), the person was sponsored by somebody
else without following the sponsor's guidelines. Months later, the packages
have still not been reviewed or approved, and I've had to mail the sponsor
privately to sort this out.

What if there are sponsors with expertise in special areas,
who are available to help'n'sponsor other contributors in such areas only?

What if sponsors have become more careful and want to observe a
potential contributor's long-term commitment first? For example,
what to think about people, whose email address doesn't appear anywhere
else in bugzilla other than in the single package review request?

What do you gain by removing sponsors so violently?

For me it would be like slamming a door into my face, and I would likely
discontinue spending time on visiting bookmarked pages like
<a href="http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html" title="http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html">http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html</a>
and the normal review request queue.

Sponsors can leave the group in FAS themselves. Send out a reminder to all
sponsors, which you consider "inactive or not active enough", and ask them
to decide whether they think they will not be sponsoring anyone in the
future anymore (e.g. due to time-constraints or lack of interest).

Re: Proposal for revitalizing the sponsorship process for packag

By Jason L Tibbitts III at 04/26/2012 - 11:37

MS> Are we talking past eachother? :-/

I don't believe so, no. I do believe that you are reading something
into my proposal that simply is not there, however.

MS> What if sponsors _try_ but for some time haven't found anyone who
MS> shows enough interest in the Fedora Packaging?

I've amended my proposal to the following:

Sponsors should expect to participate in the review of at least one
NEEDSPONSOR ticket per year, assuming there are sufficient new
packagers who require sponsorship and sufficient packages within the
realm of expertise of the sponsor to fulfill this requirement.

Although that isn't the cleanest of constructions, ugh.

MS> What if there are sponsors with expertise in special areas, who are
MS> available to help'n'sponsor other contributors in such areas only?

That was intended to be covered by the "assuming there are
sufficient..." language in the proposal. I have revised it as above
since it obviously wasn't clear to all.

MS> What do you gain by removing sponsors so violently?

Firstly, I must state that I believe your definition of "violence" must
differ significantly from mine. I do not believe I have mentioned any
type of "physical force intended to hurt, damage or kill someone or
something" or "strength of emotion or an unpleasant or destructive or
natural force". I sincerely hope I'm not just being trolled here,
because I've put a lot of effort into this and I chose my words
carefully.

Now, I do request that you re-read my proposal. There is one instance
of language involving loss of sponsorship:

Loss of sponsorship is automatic if the account goes inactive or is
disabled (in FAS terminology). It can always be requested again.

I don't see what value there is in keeping sponsorship status on
accounts which have been marked inactive. Those accounts have no access
to any Fedora infrastructure in any case. Why should they show up in
any list of prospective sponsors?

MS> For me it would be like slamming a door into my face, and I would
MS> likely discontinue spending time on visiting bookmarked pages like
MS> <a href="http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html" title="http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html">http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html</a> and
MS> the normal review request queue.

I'm really not seeing the need for the drama here.

MS> Sponsors can leave the group in FAS themselves.

Of course they can. Perhaps if my proposal is accepted you can submit
your very reasonable proposal for how sponsors leave the group. I've
rather intentionally left it out of my proposal because I've wanted to
avoid just this type of discussion.

- J<

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 12:19

Which is not the only meaning of "violent". According to what I've
learnt it is used also related to "temper" or "controversy", for instance.

Your proposal contains

| Make some criteria that sponsors need to meet
| if they wish to remain sponsors.

plus:

| Sponsors should expect to participate in the review of at least one
| NEEDSPONSOR ticket per year [...] to fulfill this requirement.

That's the other "non-automatic" loss of sponsor status, isn't it?
It could be a sponsor, who's been busy reviewing and approving other
packages.

I did not say I fear I wouldn't meet this requirement. Still, why do
you consider it necessary to put pressure on existing sponsors? A comment
on a NEEDSPONSOR ticket just to meet some criteria may be less productive
and less helpful than comments on other review requests, where a packager
would be thankful for the comments.

Then let me expand on this as it doesn't become drama just because you
name it so. Another bookmarked page is this one:
<a href="http://fedoraproject.org/PackageReviewStatus/NEW.html" title="http://fedoraproject.org/PackageReviewStatus/NEW.html">http://fedoraproject.org/PackageReviewStatus/NEW.html</a>
When I visit it, I don't pay attention to the colour and whether it's
a needsponsor's package that raises my interest or an existing
packager's ticket. It happens regularly, however, that I click on
a green package only to find it is being worked on by me or somebody
else, but is waiting for a reply for a longer time. Then I move on.
Why force sponsors to hunt for other tickets just to meet some
requirement? If I worked on a needsponsor review of a terminal based
dungeon adventure game, would that be considered more valueable than
leaving comments in arbitrary review requests? I've thought we need
more reviewer and not less.

Re: Proposal for revitalizing the sponsorship process for packag

By Ralf Corsepius at 04/26/2012 - 11:43

On 04/26/2012 06:37 PM, Jason L Tibbitts III wrote:
I regret, but this assumption simply does not apply in reality.

Apart of this, remember you can't force volunteers, unless you want to
do everything yourselves ;)

Ralf

Re: Proposal for revitalizing the sponsorship process for packag

By Ralf Corsepius at 04/26/2012 - 10:09

On 04/26/2012 04:20 PM, Jason L Tibbitts III wrote:
[Will be news to some folks listening, but finding somebody to sponsor
equally difficult as finding a sponsor is to newcomer packagers.]

May-be they are (temporarily) distracted from reviewing, may-be they
haven't found anybody to sponsor?

Ralf

Re: Proposal for revitalizing the sponsorship process for packag

By Paul Wouters at 04/26/2012 - 09:32

I think there is quiet a group of experienced packagers, who do not
consider themselves provenpackers, but who would like to help out and
sponsor people. I know I'm one of those.

Especially with fedora-review as a base for the mundane work, it should
be a relatively easy (and fun!) task to bring on more people.

Using a co-maintainer status between packager and sponsor seems a good
idea to me. It would help in cases where new packagers vanish.

Paul

Re: Proposal for revitalizing the sponsorship process for packag

By Matthias Runge at 04/26/2012 - 13:34

On 26/04/12 16:32, Paul Wouters wrote:

Re: Proposal for revitalizing the sponsorship process for packag

By Jason L Tibbitts III at 04/26/2012 - 13:37

MR> exactly, I fully agree. I think, we should lower the barrier to
MR> become a sponsor, maybe dropping the necessity to become a proven
MR> packager first.

I can't quite tell; are you aware that this is the core point of the
proposal I've put forward at the beginning of this thread?

MR> In many cases that is really not needed; a sponsor
MR> could/should become co-maintainer of the first packages of a new
MR> packager.

That's in the proposal, too.

- J<

Re: Proposal for revitalizing the sponsorship process for packag

By Matthias Runge at 04/26/2012 - 13:57

On 26/04/12 20:37, Jason L Tibbitts III wrote:
Regarding activity report: When doing statistics, I'd love
to see the review-status report again. I don't remember when and why it
vanished; it makes work of packagers/reviewer more transparent. Even
knowing how many sponsors/packagers/proven packagers are out there would
be valuable. (Yes, one could dig into FAS, to get those numbers.)

Digging further in that direction:
Would it make sense to create some credits, like crowns in some forums?
Something to check in fas? E.g. "congrats John Doe, this last week you
reviewed two packages, sponsoring one new packager"?
Or to report top 20 "Packagers/Reviewers/Sponsors of the week"?

Something like that works well in learning environments, why it should
work here?

Re: Proposal for revitalizing the sponsorship process for packag

By Matthias Runge at 04/26/2012 - 13:59

On 26/04/12 20:57, Matthias Runge wrote:

Re: Proposal for revitalizing the sponsorship process for packag

By Nicolas Mailhot at 04/26/2012 - 10:07

Le Jeu 26 avril 2012 16:32, Paul Wouters a écrit :
I think one of the main points of being a proven packager is knowing his own
limits and only touching other's packages you understand well enough not to
break. Being a proven packager does not mean mastering the whole Fedora
package universe.

IMHO if you feel solid enough on some kind of packages to help new packagers
and sponsor them, you should ask for the provenpacker upgrade.

OTOH if you don't know your limits, and are not solid for any kind of
packages, sponsoring is not more for you than provenpackaging.

Re: Proposal for revitalizing the sponsorship process for packag

By Alexander Kurtakov at 04/26/2012 - 05:43

I absolutely agree with this one. Not to mention that some of us might not do reviews/sponsorship at the same pace we do that in the past we are still very active in helping people doing there reviews, submit packages, update them through other channels - irc, mails, etc. And this is exactly what a sponsor is supposed to do. So this formal requirements are not correct. If someone wants to speed up the review process - we have to pay our technical debt. A gerrit like solution which checks the source rpm, build it, run rpmlint and add this as comments automatically so reviewers can fix their stuff prior to talking to a sponsor. And having an automated tool is great as people can not argue with it.

Alex

Re: Proposal for revitalizing the sponsorship process for packag

By =?UTF-8?B?IkrDs... at 04/25/2012 - 17:43

On 04/25/2012 10:03 PM, Jason L Tibbitts III wrote:
Why not just drop the sponsorship process and just raise the barrier of
entry for the packaging process instead?

Like having to have been a comaintainer for atleast one release cycle
then completed x many reviews in the next etc. ( essentally what you
propose there just without the "sponsor" ) and finally you are
maintaining your own package or if we drop that outdated ownership model
we have in place are free to roam "free" in the packaging community and
assist when ever, where ever possible...

JBG

Re: Proposal for revitalizing the sponsorship process for packag

By Stephen Gallagher at 04/25/2012 - 19:08

On Wed, 2012-04-25 at 22:43 +0000, "Jóhann B. Guðmundsson" wrote:
This approach completely disregards the very common example of "I'm an
upstream maintainer of a cool project. I want to package and maintain it
for Fedora." Under your approach, they'd first have to become involved
in other projects before being allowed to add their package. This is
unacceptable and would basically guarantee that no upstream would
willingly involve itself with Fedora.

Re: Proposal for revitalizing the sponsorship process for packag

By =?UTF-8?B?IkrDs... at 04/26/2012 - 10:27

On 04/26/2012 12:08 AM, Stephen Gallagher wrote:
Do you think there is anything preventing upstream from getting a VIP
pass through that process?

JBG

Re: Proposal for revitalizing the sponsorship process for packag

By Nelson Marques at 04/26/2012 - 06:18

No dia 26 de Abril de 2012 01:08, Stephen Gallagher
< ... at redhat dot com> escreveu:
I was asked by a upstream to maintain a package for Fedora due to the
high demand it has from Fedora users, unfortunatly I backed down from
the proposal for several purposes:

1) Someone claimed to own the package since 2009, but there's no
packages at all available on Fedora (weird huh ?); Upstream confirms
that they never got any information about this.
2) For newcomers the review process takes way to long... Not long ago
a 3 year old request was approved... I have pending reviews for nearly
a year...

For this situation in particular, upstream is providing Fedora/RHEL
RPM's through a competitors service, openSUSE Build Service. This is
by far not elegant at all :)

The review process needs to be faster... And I go further... On my
dayjob we mirror a lot of stuff from EPEL which is mainly the only
repository we have trust with. We have people available to maintain
other packages on EPEL, and some of my colleagues are even part of
upstream in many cases (perl modules, java stuff, etc)... But we can't
contribute to EPEL for example with reviews that take countless time.
Currently we're preparing yet another public repository with our own
packaging and enhancements because reviews take a huge ammount of
time... Though this contributions would be mainly aimed to EPEL which
is what we use.

I find hard to become a packager for Fedora specially when there's
already background experience with another vendor.

NM

Re: Proposal for revitalizing the sponsorship process for packag

By Alexander Kurtakov at 04/26/2012 - 07:11

Well, if you are at least 2 guys you can do reviews for each other and the speed of the review will depend on you two only. I can ensure you that a number of people act this way. Find a number of people having similar interests as you and help each other to speed up the thing.

Alex

Re: Proposal for revitalizing the sponsorship process for packag

By Alec Leamas at 04/26/2012 - 06:59

On 04/26/2012 01:18 PM, Nelson Marques wrote:
Still, besides this sad experience, isn't this the kind of cooperation
we should encourage? Now and then those great people with great apps
want their app in Fedora. Instead of saying "Wonderful, welcome", we
send them a list of an actually quite complicated set of requirements to
become a packager. But those people don't want that, they just want
their application packaged. And although they havn't the packaging
skills, they know their app. And that's actually a damned good starting
point.

What I'm talking about is to tell these great people that there are two
ways to get their app packaged. One way is to become a packager, and so
far this discussion is about that path,. Obviously, the requirements
here are beyond knowing an app, though.

The other way should be to find, persuade (bribe?) a packager to take
care of the package in cooperation with the developer. As I understand
it, there is no such path today(?) I think it's a pity, because the
cooperation between a developer and a packager is actually a good way of
doing it.

Just my 5 öre ;)

--alec

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 08:02

Is it? You want packages that will be well-maintained and will stay
in the distribution for more than half a year.
There have been packages, which have been trivial to review'n'approve
because of the simplicity of their spec files, but that doesn't mean the
packager/maintainer follows Fedora closely enough as necessary to handle
bugzilla/ABRT tickets, rebuilds, updates, bug-fixes, or packaging-fixes
(reported by scripts or for Rawhide). For various reasons. Oh, it's fun
if some breakage seems to be specific to Fedora (or specific to
leading-edge releases), and an upstream maintainer is not interested
in dealing with that.
Sometimes even Rawhide's daily broken deps report is considered
intimidating. I've answered tons of mails when I generated the extra
broken deps reports for the released dists. And more often than not, the
mails were negative and not positive/curious.

The package review process ensures that the packagers learn
to know what will be necessary to build in a minimum build environment
such as with koji/mock and that there are several packaging mistakes
which lead to increased trouble/maintenance or even unreproducible builds.

Sure there is! And that's _two_ people already, who would work on the
package. The theory fails, if there is no volunteer packager to begin
with.

And anyway, how many packages have more than one _active_ maintainer?
It would be fairly easy for interested packagers to become co-maintainers
and become more familiar with Fedora Packaging that way.

Re: Proposal for revitalizing the sponsorship process for packag

By Alec Leamas at 04/26/2012 - 08:17

On 04/26/2012 03:02 PM, Michael Schwendt wrote:
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?

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 09:58

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".

Re: Proposal for revitalizing the sponsorship process for packag

By Alec Leamas at 04/26/2012 - 10:32

On 04/26/2012 04:58 PM, Michael Schwendt wrote:
My theory is that packaging actually takes place from time to time
despite all these obstacles, and that a motivated upstream contact makes
this easier.

[cut]
I would really like to reconnect to Jon's reply at
<a href="http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html" title="http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html">http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html</a>.
What can we do to support those people who have a great app they wan't
into Fedora, without forcing them to be (possibly bad) packagers?

This is related to the sponsorship process if we can find a way for some
of those which doesn't include sponsoring a new packager.

--a

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 10:49

The point is that not all submitters are collaborative, and others don't
seek for sponsors actively. In the needsponsor queue are lots of tickets
where packages are not ready or where a reviewer is simply waiting for
the submitter to respond. It isn't sooooo easy to find submitters who
are willing for compromise and adapt the Fedora's requirements.

I've sponsored people before _without_ requiring them to perform package
reviews, _without_ requiring them to submit a new package first, but on
the promise that they want to take over an orphan because they are
interested in the package. This hasn't always worked flawlessly, because
some people disappoint you and drop off silently. Then it's no surprise
some sponsors (and I know a couple of others have proceeded similary) get
more careful.

Re: Proposal for revitalizing the sponsorship process for packag

By Alec Leamas at 04/26/2012 - 11:13

On 04/26/2012 05:49 PM, Michael Schwendt wrote:
Going this way would certainly enforce delays in queues, but I guess
people could accept that (well...) if they knew that the alternative
was to become a packager? A simple "How to get a package into Fedora"
page explaining that you either must become a packager yourself or find
one? That you must either submit a package review request or a ...
packaging request? In either case you need a scarse resource: a
sponsor or a packager.

With that said, I understand that such events causes you to be more
careful.

--a

Re: Proposal for revitalizing the sponsorship process for packag

By =?ISO-8859-1?Q?... at 04/27/2012 - 07:32

Dne 26.4.2012 18:13, Alec Leamas napsal(a):
I am thinking about some "dumping" repository, where people would dump
their packages and they would need almost no qualification. Of course
using such packages would be without any warranty. The packages would
not be owned by anybody, so everybody would improve them (or eventually
corrupt them ;)). Once somebody would be interested enough to become
official maintainer, he would apply to official review and the package
would get into official Fedora repo.

Actually it shouldn't be that hard to achieve it with tiny changes to
current infrastructure IMO. It seems to be still better option then to
trust to 3rd party repo or OBS.

Vit

Re: Proposal for revitalizing the sponsorship process for packag

By Alec Leamas at 05/02/2012 - 01:55

On 05/02/2012 05:34 AM, Horst H. von Brand wrote:
I sort of like the "submit a provisional spec" approach. It will qualify
the requests, and the requester will get some basic understanding making
future communications with an upcoming packager easier. And, of course,
there will be users out there using the provisional package. There might
even be feedback.

Still, the basic approach would be a path for people involved in a Great
Application out there to bring both the package and themselves into
contact with a packager. From the packagers perspective, it would be a
opportunity to find not only applications but also a qualified upstream
contact. Despite the obstacles, many being listed in this thread, I see
opportunities in this. One aspect is to not force people without
motivation to become packagers - this might in turn decrease the
pressure on sponsors. Jon's approach was a bugzilla request, something
like a "Packaging request". For me this looks like a very reasonable
starting point for "How?"
(<a href="http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html" title="http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html">http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html</a>)

Actually, I know examples of Great Applications which are now sitting in
review queue submitted by people who are not likely to become packagers
- the barrier is too high for them. This creates an extremely bad
situation. The submitter eventually drops off, with the feeling that
Fedora is... well, nothing nice. And the application becomes "blocked",
since no other packager can "take over" the request. Yes, there are
technical solution to this, but nothing acceptable from a social point
of view in many cases.

Things would be so much better both for the submitter and the community
if this had been handled differently.

--a

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 05/02/2012 - 05:56

If not packaged correctly, there might not be any feedback at all.
Imagine a broken/empty -debuginfo package which would make ABRT fail.

Truth is, in case of problems, many users would rather install from source
tarball (or a 3rd party repo) than visit bugzilla to submit a bug report
_manually_.

For broken dependencies -- imagine the worst-case scenario of a new package
not being installable at all (and it happens that its packager doesn't
notice -- it's pretty common to ask in message boards, but not react
when somebody suggests filing a bug report. It is equally common for users
to assume that the packagers notice a problem themselves. Even if after
several weeks a problem still is reproducible, a user doesn't submit a
bug report.

I've made several experiments, pointing users at the convenient
<a href="http://bugz.fedoraproject.org/PACKAGE-SRC-RPM-NAME" title="http://bugz.fedoraproject.org/PACKAGE-SRC-RPM-NAME">http://bugz.fedoraproject.org/PACKAGE-SRC-RPM-NAME</a> page for easier
entry into bugzilla, and more often than not they would find an excuse
for not submitting a bug report nevertheless.

What makes you think so? Where did you read that an "application becomes
'blocked'"?

So-called "stalled reviews" don't "block" anything:
<a href="http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews" title="http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews">http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews</a>
However, activity from a submitter/packager and a reviewer is needed.

As "Great" as an application may be, if there are no volunteers to do the
packaging, the testing, the long-term maintenance, the handling of bug
reports, a fundamental problem cannot be solved. A dumping-ground for
poorly maintained (or unmaintained) packages bears much more risks than
offering potential. Those who remember the ancient "Red Hat Contrib" know
the server full of aging src.rpms with questionable benefit.

With the current process, when the first user feedback arrives (especially
in bugzilla), a packager may _have to_ consult existing documentation on
packaging (in order to apply patches and fix packaging bugs), on using the
Fedora Build System and the Updates System. You can skip reading that
documentation during the review process, but suddenly a new hurdle is
discovered when the first package update is needed. Sponsors exist to help
the sponsorees, but they cannot guarantee that a packager drops off
nevertheless. It doesn't scale to add lots of new packages without adding
new contributors for them.

Remember, you can contribute to Fedora in several ways, not just low-level
packaging. Everything would be better, if more users were brave enough to
help with bug-triaging, be upstream liaison, be update/release master,
to name a few tasks that I could think of. And if a working src.rpm exists,
updating it to include a newer tarball isn't rocket science anyway.

Re: Proposal for revitalizing the sponsorship process for packag

By Alexander Kurtakov at 04/27/2012 - 08:29

I have seen way too many problems caused by people installing such *nonmaintained* packages to even think this will cause more troubles than it will solve.

Alex

Re: Proposal for revitalizing the sponsorship process for packag

By =?ISO-8859-1?Q?... at 04/30/2012 - 03:48

There is still plenty of such packages all around the internet. I have a
few packages I am using but haven't have the motivation to push them
through the review and i am not even sure if they could go through, but
I am positive that somebody would benefit from them.

Vit

Dne 27.4.2012 15:29, Aleksandar Kurtakov napsal(a):

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/26/2012 - 11:36

We are in need of _more_ packagers, not less packagers who grab a hundred
packages each without actually maintaining them all properly (and sometimes
even without using the package at all).

Especially if as a packager you're not involved upstream, you need to stay
in contact with upstream through other ways and e.g. observe upstream scm
commits, forward bug reports and fixes, ...

Same answer as above. Plus:

A wishlist, whether 1.0 or 2.0, is just another sort of queue. Existing
packagers may take a look and process items on the list. You need N>0
packagers for each item on the list. A user doesn't help in that case.
A user's contact with upstream is useless, too, unless the user joins the
Fedora Project and contributes __something__ to the package, whether it
be bugzilla work or filing of updates, at least __something__ at all.
And an upstream developer is available always (unless it's software that
isn't maintained anymore).

So, what has been proposed before (years ago even) is for advanced
packagers (aka "provenpackagers" or experienced packagers) to lower the
hurdle and trust them more in that they know their stuff. They would not
need to wait for somebody else (possibly a fresh packager) to
review'n'approve a package or just its licensing. It's considered
ridiculous by some that "senior packagers" still need approval for
even simple new packages or package renames.

Re: Proposal for revitalizing the sponsorship process for packag

By Stanislav Ochotnicky at 04/27/2012 - 09:10

Quoting Michael Schwendt (2012-04-26 18:36:51)
I am a provenpackager and I would be *extremely* dissapointed if this
came to become a reality. Package review is a good thing, no matter how
skilled the packager is. I have packaged quite a few packages, mostly
Java ones (65 to be exact) and I still make mistakes! Guidelines change,
people miss things (such as bundling, licensing issues, wrong
permissions, etc.). I will put it bluntly: getting rid of package
reviews would be an incredibly stupid thing to do.

Re: Proposal for revitalizing the sponsorship process for packag

By Guido at 04/28/2012 - 01:31

Il giorno 28 aprile 2012 00:10, Stanislav Ochotnicky ha scritto:
I completely agree with you. To go back to initial proposal of
revitalizing sponsor role, I think it would also be a good thing,
given that we leverage on new possible sponsor responsibilities
(ie, supervise new sponsorees' commits for X time after package
creation, not just step in when there is something to fix).
More sponsors should bring more control, not easier membership.

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/28/2012 - 04:02

That's no new responsibilities. Sponsors have always been expected to do
that. With pkgdb, it requires "watch*" access to the packages. Else
it requires subscribing to the scm-commits list and filtering by
username/packagename. I've done that, and I've been aware of sponsors
who have done that, too.

The 'X time after package creation' has never been defined anywhere,
and I don't think it would be a good idea to define it as a constant.
The level of hand-holding varies a lot.

Too vague. Please expand on that.

Re: Proposal for revitalizing the sponsorship process for packag

By Guido at 04/29/2012 - 04:31

Il 28 aprile 2012 19:02, Michael Schwendt < ... at gmail dot com> ha scritto:
I wasn't aware of that; if it isn't a best practice, but a must do,
the wiki page
<a href="http://fedoraproject.org/wiki/Package_sponsor_responsibilities" title="http://fedoraproject.org/wiki/Package_sponsor_responsibilities">http://fedoraproject.org/wiki/Package_sponsor_responsibilities</a> should
be updated.

If this page is updated (I have no idea):
<a href="https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor?order_by=approval" title="https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor?order_by=approval">https://admin.fedoraproject.org/accounts/group/members/packager/*/sponso...</a>
the sponsors group has not grown as a function of packages, nor as a
function of package maintainers. Possibly because of the sponsor is a
provenpackager thing, possibly because that was meant as "we need X sponsors
to take care of the Y new maintainers requests we get each given time window".
If we intend the sponsor as a mentor and a supervisor instead, the
number of packages
of his sponsorees couldn't reasonably grow too big, or control would
be loosened.
But I am not saying that a sponsor should be turned to a forced
comaintainer for the
time being, either.

Hope this makes sense

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/29/2012 - 09:19

You've found a section in the Wiki that isn't pretty. :-)
There's this other page:

<a href="https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Sponsoring_Someone_for_Fedora_Package_Collection" title="https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Sponsoring_Someone_for_Fedora_Package_Collection">https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Sponsori...</a>

| You should be sure to review their commits to the Git repository for
| how they look, and consider watching their Bugzilla activity at least
| for a while (Account->Email->Users to watch).

Rest assured, no such variables X and Y are in use anywhere related to the
packager sponsor group. Potential sponsors either nominate themselves or
get nominated by somebody else:

<a href="https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor" title="https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor">https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor</a>

That wouldn't work well in all cases anyway. There is no requirement for
sponsors to have indepth knowledge of the software the sponsoree has
packaged. Not even the first package the sponsor has reviewed. Doing
packaging and reviewing a package is one thing, being intimately familiar
with the packaged software is another. Review-time testing of the packaged
software is only a SHOULD in the guidelines. It is assumed that the
package submitter is familiar with the software and that the reviewer
is sufficiently familiar with packaging to not break the software by
making false recommendations. ;)

Re: Proposal for revitalizing the sponsorship process for packag

By Nelson Marques at 04/30/2012 - 04:53

2012/4/29 Michael Schwendt < ... at gmail dot com>:
My apologies for deviating the thread earlier. I would address this
issue in a different way:

1) Assigning a sponsor to a new potential contributor takes a lot of
time from an active 'sponsor' and there's no ensurance the contributor
will go through it and succeed; in case it fails, it's 'wasted' time
that could be used into something more productive from the sponsor.

2) Motivational issues: this are important, either from the sponsor
and from the potential contributor; While for the potential
contributor slow response times can break his motivation, for the
'sponsor' motivation can be affected by non-responsive contributors or
people who just 'disappear'

This are probably the most relevant factors, sponsor's workflow and
motivational issues. There's no easy fix for it, so my suggestion
would be to face the current issues from a whole different
perspective:

a) Packages should be owned by a group of people and not necessarily
from a single person; face this as the real 'owner' of the package is
"X", where "X" stands for the group of all co-maintainers of the
package, which can be coordinated by a SIG;

b) Introduce a more collaborative way; Imagine I want to get package
'foobar' updated; The step would be to encourage the current person to
file a bug report requesting the update and provide already a git pull
with the changes; When it comes to review one of the persons which
maintains the package can review the git pull request and merge
it/rebuild it or request further changes. This is the fase where
there's know-how transiction and everyone would be allowed to submit
changes to Fedora without being a packager. The review still happens
and isn't bound to a single person, but instead to a group of persons,
which should reduce the heat.

c) Such a method would also mean that packages are harder to get
orphaned out, since theres more people looking after them;

d) This should provide a faster review and response;

e) This should allow that the 'trust' escalation on potential
contributors still happen;

f) The integrity of the project and quality of the packages should be
maintained as there's always a higher review;

g) People can escalate in trust based on past contributions to the
project, and this allows people with less technical skills to still be
able to contribute in a secure way to the project; furthermore, it
allows collaboration and provides also a know-how transfer from more
experienced users to newcomers;

I know this isn't perfect, but for me, such a method would be far more
easier; instead of being nagging people to do rebuilds/updates, etc,
potential contributors should actually be able to submit code directly
and having a group of people to review it and merge it when
accepted...

Would this make any sense and in your opinion would it be possible ?

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 05/01/2012 - 04:13

A sponsor who has made a bad experience could sound like that. ;)

It's not necessarily a "wasted" effort, because for the reviewer it's
useful practice. And often, multiple reviewers visit a review request
ticket and read through the comments. Sometimes only as a self-test to
find out whether they would notice the same issues with a package. But
one can learn from reading [some] reviews.

Which is also one reason why newbie packagers and needsponsor-packagers
are encouraged to try reviewing somebody else's package. That this could
speed on the sponsor-finding process should be enough motivation.

I'm more concerned about the apparent increase of package-orphans due to
packagers who drop off silently. No statistics known, but it seems to be a
steady percentage of the total number of packages. One one side of the
package collection there are attempts at adding new packages faster, while
on the other side packages must be orphaned because maintainer is AWOL.

But this is possible already since the introduction of pkgdb!

Even if the interface lists one of the maintainers as "owner" (aka the
initial assignee in bugzilla), additional maintainers can be added to the
four ACLs, getting full access to the package, including even the ability
to approve further maintainers within pkgdb.

Additionally, the SRCRPMNAME-owner Fedora Project mail alias can be used
to reach all maintainer of the package. For some packages, the mail is
forwarded to a special mailing-list even.

Nothing (except for lack of motivation) really stops an interested
volunteer from signing up as the bug triager for a package, for instance.
The "watchbugzilla" ACL in pkgdb makes that easy. The person only needs to
be sponsored, which shouldn't be a big hurdle, provided the person does
the preparatory work, such as "signing the deal" with the existing package
maintainer(s). Another person could handle releasing the updates in bodhi,
and so on.

As I mentioned elsewhere in this thread, a problem IMO is that once there
is a single package owner already, hardly anybody else wants to take care
of this package, too. Unless the owner becomes non-responsive or doesn't
update the package frequently enough. Potential orphans have a higher
chance of attracting a co-maintainer, which likely becomes the new "owner"
if the previous owner drops off actually. Actual orphans are picked by
existing packagers like low-hanging fruit, sometimes apparently without
real interest in the packages.

Same as above. Or?

Btw, we're facing the problem that update requests in bugzilla (similar
to bug reports in bugzilla) are not handled for some packages.
Non-responsive maintainers, different/conflicting workflows, too many
tickets per component, etc. And still, bugzilla isn't a place where bug
reporters would volunteer as co-maintainers.

Well, there are small and larger teams of maintainers for some packages
already. It's possible. Still there are thousand of packages, which are
maintained by a single person.

Imagine the following:

If the current package review process were turnt into a package popularity
contest, it would stall almost completely. For example, if the reviewer
were forced to become an initial co-maintainer, or if there were a
requirement for a package to be maintained by two initial people and not
just the single submitter.

"Trust" is something beyond this topic, IMO.

I think it has been possible for a longer time already. It doesn't solve
the fundamental problems, however. It's all too easy to point the finger
at the packaging guidelines, and call them "unneeded bureaucracy" for
example, and not sign up as a contributor.

Re: Proposal for revitalizing the sponsorship process for packag

By Michael Schwendt at 04/27/2012 - 09:29

Package reviews would be _optional_ for provenpackagers, not mandatory
anymore. You could still open a review request and wait for a reviewer.
Especially for non-trivial packages.

The bottom half of your paragraph misses the point completely, btw.
We don't have a review process for packages _after_ package approval.
Mistakes happen, and it's possible that with any unattended version-
upgrade you would introduce mistakes. Does that imply you would want
mandatory reviews for every commit in git? No. Hopefully not. ;)

Re: Proposal for revitalizing the sponsorship process for packag

By Alexander Kurtakov at 04/26/2012 - 11:32

Nice idea if there was a pool of packagers just waiting for something to package. While the reality is exactly the opposite. Most packagers are overloaded and we even drop packages intentionally as we can not keep the pace. So it's in Fedora's best interest to get more people working on the packages instead of creating wishlists for packagers.

Alex

Re: Proposal for revitalizing the sponsorship process for packag

By Jon Ciesla at 04/26/2012 - 10:53

On Thu, Apr 26, 2012 at 10:49 AM, Michael Schwendt < ... at gmail dot com> wrote:
Exactly. So for some people, what you've done is great. In other
cases, it's better if they have a way to ask that an existing packager
be the maintainer. Many of us are willing to do that, especially if
the requester is an upstream user or developer of the software that's
willing to work with us to make sure the package works the best way
possible.

-J

Fwd: Re: Proposal for revitalizing the sponsorship process for p

By Alec Leamas at 04/26/2012 - 10:43

I got the trailing link wrong, here is same message with link OK (no
punctuation )

On 04/26/2012 04:58 PM, Michael Schwendt wrote:
My theory is that packaging actually takes place from time to time
despite all these obstacles, and that a motivated upstream contact makes
this easier.

[cut]
I would really like to reconnect to Jon's reply at
<a href="http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html" title="http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html">http://lists.fedoraproject.org/pipermail/devel/2012-April/166429.html</a>
What can we do to support those people who have a great app they wan't
into Fedora, without forcing them to be (possibly bad) packagers?

This is related to the sponsorship process if we can find a way for some
of those which doesn't include sponsoring a new packager.

--a

Re: Proposal for revitalizing the sponsorship process for packag

By Jon Ciesla at 04/26/2012 - 07:30

On Thu, Apr 26, 2012 at 6:59 AM, Alec Leamas <leamas. ... at gmail dot com> wrote:
I've been asked to package things before, by friends, colleagues,
upstream devs, etc. My response it typically, "Oh, neat, I'd never
heard of that!" <rushes off to make an RPM and submit a review> I
know we have a wishlist, but I'm not sure it's being used by
non-packagers, or packagers for that matter.

-J

Re: Proposal for revitalizing the sponsorship process for packag

By Alec Leamas at 04/26/2012 - 08:02

On 04/26/2012 02:30 PM, Jon Ciesla wrote:
Seems that when this happens, it's going the informal way - which is
good. But someone who just tries to read the webpages, will eventually
submit a bugzilla package review request. And in many cases things have
gone terribly wrong then IMHO.

I might be totally out in the blue, but my feeling is that there's a lot
of information on "How to become a Fedora packager" - but very little
about "How do I get my package into Fedora?". If this is true, it might
possibly reflect that this issue havn't been thought of as needed.

Being a newbie I havn't seen the fedora wishlist (but rpmfusions's). The
first thing which strikes me when I check it is that the there's no link
to the person who submitted the request. For me, this is essential -
having a motivated contact upstream makes a difference.

--a

Re: Proposal for revitalizing the sponsorship process for packag

By Jon Ciesla at 04/26/2012 - 08:13

On Thu, Apr 26, 2012 at 8:02 AM, Alec Leamas <leamas. ... at gmail dot com> wrote:
Yes! Exactly. I'd love to see this fixed. What if we had a simple
process where someone could file a BZ with a component of Wishlist or
something, and we could direct this sort of thing there? Then
existing packagers could check it out, file a review BZ blocking that
Wishlist bug, and the submitter therefore would be reachable, and
could follow the whole process. Also, since BZ is searchable, people
could search it before submitting a Wishlist or Review, to see if it's
already out there being worked on, if it was tried and failed, why
that might be, etc.

I'm not sure if this needs a Whole New Process, or simply a new link
and BZ component.

Thoughts?

-J

Re: Proposal for revitalizing the sponsorship process for packag

By Adam Williamson at 04/26/2012 - 06:40

This seems like a specific case of weirdness and nothing worth drawing
general conclusions from. Why not just describe the specific situation
here and see if it can be resolved instead of phrasing it as if it were
a single example of a general problem?

This can vary hugely; it depends to a large extent on a) how interested
other people are in your package and b) how hard you try and get someone
to review it.

For instance, the review for Cinnamon was picked up within days of being
filed, because of widespread general interest. (It's been held up by
technical issues, but it was picked up quickly and followed actively).
If your package is 'plugin for obscure scientific framework that three
people in the entire world care about', you can expect the review to
take longer, especially if you make no active efforts to try and find
someone to review it - by mailing the list, offering review swaps,
poking people you know within Fedora, pulling in favours etc. If you
just file a review for anything but a very popular package and leave it
sitting there, you're relying on one of the few people who consider
'going through the pile of packages for review methodically' to be a
good time.

OBS now stands for Open Build Service, specifically because SUSE think
it should be a generic service. Obviously it's not as good as being part
of the distro, but from all I know about it, it seems like a perfectly
good second choice. Isn't calling it 'a competitor's service' and
implying it would somehow be better if there were some Fedora-affiliated
remote build service and the package used that instead simply an example
of NIH thinking? If OBS does the job, why should Fedora spend resources
creating a 'competing' service?

Re: Proposal for revitalizing the sponsorship process for packag

By =?UTF-8?B?IkrDs... at 04/26/2012 - 12:15

On 04/26/2012 11:40 AM, Adam Williamson wrote:
This is a part of a problem not a solution which needs to be addressed...

JBG

Re: Proposal for revitalizing the sponsorship process for packag

By Nelson Marques at 04/26/2012 - 06:58

No dia 26 de Abril de 2012 12:40, Adam Williamson
< ... at redhat dot com> escreveu:
BZ718430

Yeah, Cinnamon is tricky specially with Muffin typelib provides issue
(typelib(Meta-3.0)). I've withdraw it from openSUSE as well before I
left.

Adam, the main point is that users, upstream and myself believe that
if the package is provided on Fedora it's better for everyone,
specially for end users. Sure if you doin't want to have more packages
on Fedora, then we have a solution already... which eventually is more
complicated for everyone, mainly for end users than a simple: yum
install <PACKAGE>...

But there's no issues what so ever from my side, it's actually less
work for me...