FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-07-2008, 09:52 PM
Toshio Kuratomi
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

Michael DeHaan wrote:
>
>>>> Rather than
>>>> having a large group of people with commit to (nearly) everything for
>>>> fixing minor issues, the focus should be on significantly increasing
>>>> our
>>>> levels of co-maintainership. The ideal should be for every package in
>>>> the distro to have at least 1 extra co-maintainer, or preferrably 3
>>>> or 4.
>>>> People with a little domain knowledge for the package who can handle
>>>> both the low-hanging fruit the main maintainer misses, with less risk
>>>> of making mistakes due to lack of package specific knowledge. Sure it'd
>>>> take more people resources than 'provenpackager' solution, and likely
>>>> require a big community publicity campaign to kick it off, but long
>>>> term it'd be more helpful & safer - particularly for 'infrastruture'
>>>> packages (python, perl, etc runtimes & important addon modules) and
>>>> security sensitive packages (openssl, gnutls, func, koan, etc).
>>>>
>>
>> This makes a lot of theoretical sense but has had mixed results in
>> practice. I can recall at least two drives to get comaintainers for
>> packages in the past. This has had some more people sign up for
>> comaintainership for some packages but it hasn't gotten us near to 100%
>> coverage. Some of the things it doesn't address:
>>
>> Trust: If I'm a new contributor who just needed to get X.Y.Z in because
>> I just started using it on my shiny Fedora Desktop, I may not have any
>> contact with any other Fedora Contributor. If I don't trust the
>> provenpackager group with this software, I'm not likely to trust an
>> unknown packager who asks to be a comaintainer either. In fact, if
>> there was an over-all group of people who seldom make a mistake and know
>> packaging and software backward and forward, I'm more likely to entrust
>> that group with the ability to modify my package than the random
>> packager.
>>
>
> I would hope the process here is to:
>
> (A) email package-owner@fedoraproject.org about the version and/or file
> a bugzilla
> (B) have a process to handle things if the owner is MIA
>
You're looking at it from the opposite angle from what this paragraph
does. You're playing the potential co-maintainer. I was playing the
potential maintainer. As a maintainer who doesn't know anyone in this
community I'd be much more likely to give access to a packager group
that Fedora says is made up of people who can teach me a thing or two
about packaging than a random contributor who shows up and says they'd
like to comaintain. Having a "comaintainer campaign" is going to create
more of the latter.

The normal process of attaining comaintainers (you submit a patch. You
submit another patch. Either you ask for comaintainership or I get
tired of being your proxy) is separate from such a campaign and would
more or less follow the steps you outline.

> Let's take the "I need X.Y.Z" case. If someone can't make a change in
> a week --- that in itself may not be a problem -- provenpackager may be
> trying to be helpful, but may not have the domain knowledge about the
> app -- say version X.Y.Z is not ready for prime time. I would say "I
> need version X.Y.Z" now is not a strong enough reason to require an
> override by a provenpackager if a maintainer is not immediately
> reachable (say, on vacation). If the package maintainer is orphaned by
> our definitions, it needs a maintainer. I certaintly would not want
> someone updating the package and being suprised by that -- and then
> having to revert those changes because they were wrong for the package.
>
Sure. But how often does this happen? We're pretty wary of stepping on
each other's toes. Michael Schwendt's fixups are one example of things
that went through a long amount of time and multiple emails before
getting to cvs. The FTBS process is another one. Having a higher level
packaging group should be populated with people who are careful about
things, take time to think things through, are thorough about their
announcements of changes.

Note, that provenpackager does not meet these criteria IMHO.


> And yes, I'm not likely to trust someone I don't know to co-maintain a
> package, but likely are people that we /do/ know in many cases.
> provenpackagers seems to imply a whole new need for a level of oversight
> -- especially if any provenpackager can make more.
>
I would argue that that's not true. The people that are well known are
the people who are vocal on the mailing lists, on irc, and involved with
upstreams. Other people are not. If we have a campaign to get
comaintainers for every package we're going to quickly exhaust the
supply of known participants.

>> Non-Responsiveness: If the package in question is getting bug reports
>> from people about the low-hanging packaging bugs but the bug reports are
>> not being answered even if there are two or more maintainers, there
>> still needs to be a way for the changes to be applied to the packages.
>> We also need to have a means of adding comaintainers when the maintainer
>> does not answer the requests to add a comaintainer.
>>
>> A non-responsive, forced comaintenance policy would help deal with the
>> second part of this problem.
>>
>> Interest in fixing an error that is easily checked for: Contributors
>> like Michael Schwendt have written and run checks for specific packaging
>> errors and then opened bugs for them against many packages. When the
>> bug is not replied to, they have written patches. When those aren't
>> acknoledged they have applied them where the acls are open. When the
>> acls are closed the process breaks.
>>
>>
>
>
> This /seems/ to be why we have the "MIA maintainer" policy. If the
> maintainer is unresponsive we have a larger issue and a temporary fix to
> the package will still leave the package out of date, and it starts to
> be maintained ad-hoc and is likely to grow more out of date.
>
We can block a package from the next release if we know that it is
effectively orphaned. Packages that are in released distros need to be
maintained until the package goes EOL. Perhaps all we need is to
specify that orphaned packages will have their provenpackager ACL opened
automatically and then the MIA policy will be sufficient.

>> A non-responsive: forced acl opening policy would work for this.
>>
>> Interest in a package: If the packager is the only one interested in
>> doing work on a package, then there won't be a comaintainer. That
>> doesn't mean that the package won't have common problems so that someone
>> looking for common problems won't need to get changes applied to it
>> later.
>>
>
> I think it's covered by the above too, isn't it?

Note that MIA does not address the question of getting a comaintainer on
every package which this email was a reply to. I'm arguing that a
comaintainer campaign is insufficient as there will always be some
packages which are not interesting to more than one packager.

That said, MIA policy is a lot of work and effort. Because of that, it
is mostly applied by people who want to take over maintainance of a
package. People who are taking care of a bug that's widespread
throughout the distribution are concentrating on getting the most
packages fixed rather than getting a specific package fixed. So
packages that should be orphaned and dropped from the distro aren't
getting dealt with.

Having a streamlined policy for orphaning packages once a release under
terms similar to the MIA policy could help. ie: once a release, take
candidate bugs/packages for MIA status. Send email to the owners of
those packages, file new bugzillas if necessary. For those packages
that don't get responses, orphan them and give people an opportunity to
take them over before the orphan culling that happens near release time.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 10:24 AM
Tim Lauridsen
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

Jesse Keating wrote:

For rawhide, somebody would be able to commit a change and do a build,
and it would automatically go out in rawhide. But for a released
package, since it has to go through bodhi, only the "owner" can do bodhi
updates at this time. There are plans to enable co-maintainers to
submit updates too, but that would again be specifically granted people,
rather than members of a larger group.

Are you sure this is right, i maintain yum-utils upstream and in fedora,
but Seth

is the owner. I have no troubles submitting updates in bodhi to yum-utils.

Tim

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 11:06 AM
Michael Schwendt
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

On Sat, 08 Nov 2008 12:24:05 +0100, Tim Lauridsen wrote:

> Jesse Keating wrote:
> > For rawhide, somebody would be able to commit a change and do a build,
> > and it would automatically go out in rawhide. But for a released
> > package, since it has to go through bodhi, only the "owner" can do bodhi
> > updates at this time. There are plans to enable co-maintainers to
> > submit updates too, but that would again be specifically granted people,
> > rather than members of a larger group.
> >
> Are you sure this is right, i maintain yum-utils upstream and in fedora,
> but Seth
> is the owner. I have no troubles submitting updates in bodhi to yum-utils.

When exactly did you do that the last time?
It's quite a recent change in the bodhi production instance, afaik.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 11:23 AM
Michael Schwendt
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

On Fri, 07 Nov 2008 16:59:41 -0500, Michael DeHaan wrote:

> I would hope the process here is to:
>
> (A) email package-owner@fedoraproject.org about the version and/or file
> a bugzilla

* There's a small group of people who complain to you if you mail them
privately instead of using bugzilla for EasyFix stuff. I do understand
that, but I hope they do watch their cvs commit notifications closely and
notice any changes merged by other committers, because if such changes
are overwritten (and that has happened before), the entire system fails.

* There's a larger group of people who can't handle all their bugzilla
traffic. They refer to bugzilla notification mails as "spam". This has
been discussed several times before. You can file a bug, and it won't be
looked at. You can file a bug and get a reply, but the issue won't be
fixed. You can ping such people repeatedly, and the issue would remain
unfixed even after many months. It's tiresome for reporters to deal
with such tickets and the additional disturbances from triagers or
scripts that threaten to close aging tickets for EOL.

> (B) have a process to handle things if the owner is MIA
>
> Let's take the "I need X.Y.Z" case.

Are any examples known about X.Y.Z version upgrade requests that have not
been fulfilled and have been a problem before? Or is it just FUD, to
believe that someone from the provenpackager group (is that the final acl
group name?) runs mad in cvs/koji/bodhi and prepares such version upgrades
without a very good rationale and without permission from FESCo?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 12:40 PM
Tim Lauridsen
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

Michael Schwendt wrote:

On Sat, 08 Nov 2008 12:24:05 +0100, Tim Lauridsen wrote:



Jesse Keating wrote:


For rawhide, somebody would be able to commit a change and do a build,
and it would automatically go out in rawhide. But for a released
package, since it has to go through bodhi, only the "owner" can do bodhi
updates at this time. There are plans to enable co-maintainers to
submit updates too, but that would again be specifically granted people,
rather than members of a larger group.



Are you sure this is right, i maintain yum-utils upstream and in fedora,
but Seth
is the owner. I have no troubles submitting updates in bodhi to yum-utils.



When exactly did you do that the last time?
It's quite a recent change in the bodhi production instance, afaik.



18/9.

So if it is recent, then i might be that way today,* so it seams that i
will not be able push updates to yum-utils, until the

co-maintainer thing is implemented



Tim





--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 01:52 PM
Till Maas
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

On Fri November 7 2008, Jesse Keating wrote:

> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide. But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time. There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.

Can the comainters edit the update after it is created, e.g. add bugs and a
description and request moves or is this now all left to the primary
maintainer?

Is there are timeframe until it will be possible to completely comaintain
packages again? E.g. I started to comaintain some packages where the original
maintainers did not have enough time to completely maintain them, so if they
are now again needed to do more work, this does not really work out. :-/

Regards,
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 02:10 PM
Jeroen van Meeuwen
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

Jesse Keating wrote:
But for a released

package, since it has to go through bodhi, only the "owner" can do bodhi
updates at this time.


I think that isn't entirely accurate:

https://admin.fedoraproject.org/pkgdb/packages/name/rubygem-fastthread#Fedora9

https://admin.fedoraproject.org/updates/rubygem-fastthread-1.0.1-1.fc9

/me goes to request co-maintainership for the package now.

Kind regards,

Jeroen van Meeuwen
-kanarip

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 02:20 PM
Kevin Kofler
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

Jesse Keating wrote:
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide. But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time. There are plans to enable co-maintainers to
> submit updates too, but that would again be specifically granted people,
> rather than members of a larger group.

Ouch... If that's true, that's a really big regression! Bodhi has allowed
comaintainers and even members of packager to submit updates for quite a
while now, and this has been seen as a good thing.

An "owner-only" policy is going to severely impede pushing KDE updates, as
we need to submit updates for a big group of packages with different
nominal primary maintainers (but all effectively team-maintained by us).
And they need to be pushed as a group because all the new KDE packages
depend on the new kdelibs (it's backwards- but not forwards-compatible).

Other updates which need to be pushed as grouped updates are also similarly
affected (e.g. xulrunner and dependent packages).

I think it is absolutely essential for at least people with explicit commit
access to be able to push updates.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 02:53 PM
Michael Schwendt
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

On Sat, 08 Nov 2008 16:20:29 +0100, Kevin Kofler wrote:

> Jesse Keating wrote:
> > For rawhide, somebody would be able to commit a change and do a build,
> > and it would automatically go out in rawhide. But for a released
> > package, since it has to go through bodhi, only the "owner" can do bodhi
> > updates at this time. There are plans to enable co-maintainers to
> > submit updates too, but that would again be specifically granted people,
> > rather than members of a larger group.
>
> Ouch... If that's true, that's a really big regression! Bodhi has allowed
> comaintainers and even members of packager to submit updates for quite a
> while now, and this has been seen as a good thing.

Here's where I heard about it for the first time:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02281.html

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-08-2008, 03:29 PM
Jesse Keating
 
Default Concerns about 'provenpackager' and why I didn't mass ACL open

On Fri, 2008-11-07 at 12:15 -0800, Jesse Keating wrote:
> For rawhide, somebody would be able to commit a change and do a build,
> and it would automatically go out in rawhide. But for a released
> package, since it has to go through bodhi, only the "owner" can do bodhi
> updates at this time.

Whoops. This wasn't quite right.
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02282.html



--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 10:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org