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 01-16-2010, 04:39 PM
Kevin Fenzi
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 16 Jan 2010 10:39:54 +0100
Till Maas <opensource@till.name> wrote:

> > Indeed. I don't see much activity from them.
> > Have you tried sending them an email?
> > If not, I can.
>
> No, please go ahead.

I took the liberty right after I posted.

(Hopefully Ian doesn't mind me passing this along

Ian Burrell wrote:

> I am still around but haven't been busy recently and haven't done
> anything with my packages.
>
> I'll take a look at this weekend.
>
> - Ian
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 04:45 PM
Kevin Fenzi
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 16 Jan 2010 11:08:30 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> I don't see who the orphaning without following proper procedure is
> appropriate at all. Simply blocking the ones which FTBFS bugs were not
> fixed from F-13 inclusion would have been the appropriate response
> (as documented in our procedures), not
> some adhoc almost random response.

These packages have failed to build for over a year.

Sure, we could allow them to continue if someone steps in to build
them, but then who is answering bugzilla tickets on them? Who is
following upstream and updating them, in short: who is maintaining
them? Not the maintainer of record it seems.

if you want them to go on, take ownership.

Sorry for the bug that prevented people from doing this, it's been
fixed.

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 05:02 PM
Kevin Fenzi
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 16 Jan 2010 10:13:32 +0100
Michael Schwendt <mschwendt@gmail.com> wrote:

> It's a more fundamental problem, though. The AWOL-process is for
> people, not for packages. The people may still be active (and even
> known to be active somewhere) and not AWOL, but the packages which
> are assigned to them would still look orphaned. FTBFS is just one way
> to find packages that don't even build.
> However, if that happens, it may be much too late. Such a package may
> have been in an unmaintained desolate state for a long time already.
> With nobody handling the incoming bugzilla tickets. With some bug
> reports having been killed in an automated way at dist EOL. And worse
> if it turns out that packages which do build are unmaintained
> nevertheless, with the same symptoms in bugzilla and in package scm.
>
> Makes me wonder what bugzilla status report scripts we have? To
> create a list of potentially unmaintained packages earlier and to
> detect packages with non-responsive owners.

Yeah, there was talk a while back about setting something up to try and
detect poorly maintained/unmaintained packages, but I fear nothing ever
came of it.

I think it would be great to have some automated script that used a
variety of input info to try and come up with a list of packages and/or
maintainers who are not responsive. Unfortunately, this will be
tricky to get right as there are a lot of corner cases: This could
include:

- Process bugzilla.
Maintainers:
How many bugs are assigned to each maintainer.
How many of those have never had a comment by that maintainer.
How many of those are over a month old
How many of those are over a year old
How many of those are over 5 years old.

Packages:
Packages with the most bugs (would need to weight somehow
things like the kernel or X, and/or abrt bugs). Perhaps
divide by co-maintainers?
Packages that have upstream updates that haven't been acted on.

-SCM Commits / Bodhi / Koji

Packages:

Packages that have had no SCM commits in a cycle.
Packages that have had no updates in a cycle.

Maintainers:
Maintainers who have not commited to anything in a
cycle
Maintainers who have never submitted an update.
Maintainers who have never built anything in koji.
Maintainers who haven't built anything in a cycle.
Maintainers who haven't built anything in a year.

- Mail / FAS:
Maintainers who have never posted to fedora*
Maintainers who's fedora account system email bounces
Maintainers who's fedora account system email is never
responded to.
Sponsors who have never sponsored anyone.
Sponsors who have not sponsored anyone in a year.
Sponsors who have not sponsored anyone in 5 years.

- Planet:
Maintainers who have a feed, but no posts.

etc.

You can see there is a lot of info out there, but much of it may not
apply in reality. Ie, there is a package that doesn't update because
it's quite stable. It has no bugs against it and the maintainer isn't
doing anything else in Fedora.

So, it might be nice to have such a tool and have it generate a list of
possible maintainers/packages that need help. Then a human should look
over the list and try and contact maintainers/gather info on packages
and/or start unresponsive maintainer, etc.

Any takers for writing such a script?

kevin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 07:54 PM
Jesse Keating
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 2010-01-16 at 11:08 +0100, Hans de Goede wrote:
> Simply blocking the ones which FTBFS bugs were not
> fixed from F-13 inclusion would have been the appropriate response
> (as documented in our procedures), not
> some adhoc almost random response.

We are blocking them. Every release we round up the orphans and block
them from the release. Since this practice already existed, it made
sense to orphan the FTBFS packages and give folks a chance to reclaim
them before we block all the orphans, not just the FTBFS ones.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 07:56 PM
Jesse Keating
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 2010-01-16 at 10:59 +0100, Hans de Goede wrote:
> You know we have a procedure for this it is called the awol maintainer
> procedure and it would be nice if FESco would follow its on procedures
> here.
>
> Ah well I guess the rules don't apply to those who make them
>
>

The non-responsive maintainer process is a rather lengthy and involved
process, one which wouldn't lead to these packages being blocked in
time. Due to that we decided it would be best to special case these and
orphan them right away, so that this current set of packages can be
dealt with appropriately.

If a volunteer wishes to instigate a non-responsive process on all the
maintainers, that is a separate matter which can happen concurrently to
the current actions.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 10:10 PM
Matt Domsch
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 12:47:35AM +0100, Hans de Goede wrote:
> Bad idea (says someone who owns 150 packages). I don't feel like
> getting 150 bugzilla mails and having to (mass) close them each
> release.

OK; add a fedora-packager script that mass-closes bugs; or use the
bugzilla web interface to select all bugs owned by you also blocking
the blocker bug, and apply the same change to them all; again in one
fell swoop. This is solvable. This may still not be the "best"
approach, but it is possible and doesn't have to be onerous.

--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-17-2010, 06:26 AM
Till Maas
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 05:10:17PM -0600, Matt Domsch wrote:
> On Sat, Jan 16, 2010 at 12:47:35AM +0100, Hans de Goede wrote:
> > Bad idea (says someone who owns 150 packages). I don't feel like
> > getting 150 bugzilla mails and having to (mass) close them each
> > release.
>
> OK; add a fedora-packager script that mass-closes bugs; or use the
> bugzilla web interface to select all bugs owned by you also blocking
> the blocker bug, and apply the same change to them all; again in one
> fell swoop. This is solvable. This may still not be the "best"
> approach, but it is possible and doesn't have to be onerous.

We could also include a cron script, that does it all twice a year. ;-)
There are already afaik three such timeouts that hit maintainers, can't
we use this data? One is asked to change the password in FAS and
bugzilla regularly and the client certificate to create builds and
upload to the lookaside cache expire every 6 months iirc.

Imho the solution to detect whether a package is still maintained should
support maintainers as much as much is possible and not just be created
in a way that's easy to implement, but highly annoying to maintainers.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-17-2010, 06:48 PM
Till Maas
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote:
> On Sat, 16 Jan 2010 10:39:54 +0100
> Till Maas <opensource@till.name> wrote:
>
> > > Indeed. I don't see much activity from them.
> > > Have you tried sending them an email?
> > > If not, I can.
> >
> > No, please go ahead.
>
> I took the liberty right after I posted.

Did also contact the recordmydesktop maintainer?

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-17-2010, 06:52 PM
Till Maas
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Fri, Jan 15, 2010 at 02:06:09PM -0600, Matt Domsch wrote:
> On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote:
> > On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
> > > On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
> > > > The following 30 packages, with respective FTBFS bugs, have been open
> > > > since the Fedora 11 time frame, and continue to fail to build. These
> > > > are the oldest non-building packages in the distribution, everything
> > > > else (over 8800) managed to build for Fedora 12 or newer already.
> > >
> > > At today's FESCo meeting, it was agreed that all the below packages
> > > would be marked orphan. I know several of these have been fixed by
> > > provenpackagers already - you are welcome to un-orphan and maintain
> > > them going forward, or the original package owner may choose to do so.
> >

> I made sure that no one who fixed a package was actually the package
> owner.
>
> Pre-orphaning:
>
[...]

The list of packages you announced that are going to be orphaned and the
list of packages that were orphaned are not the same. recordmydesktop
was on the to-be-orphaned list but afaics was not orphaned and also was
not mentioned in your list about which provenpackager fixed which
package.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-18-2010, 02:46 AM
Seth Vidal
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 16 Jan 2010, Matt Domsch wrote:

> We could easily create a new class of bugzilla ticket, say
> "MAINTAINED". An automated process would generate such tickets,
> blocking F13MAINTAINED. The ticket would ask the maintainer to close
> the ticket to remain the owner of the package. Tickets still open
> after $SOMEDELAY would be candidates for orphan or non-responsive
> maintainer process. Repeat at $SOMEINTERVAL, perhaps once per release
> cycle (more would be too onerous I think).
>
> With a slight modification, my ftbfs bugzilla script could generate
> the tickets.
>
> Thoughts?

I like the idea. I like it even more if we could make a make-target for
saying "I'm here, shut the hell up" so it can be done easily.

So, for Hans' situation - if he has 150 pkgs - we file a 'MAINTAINED' bug
on any of the pkgs which has not had any change in a full release.

that should narrow the number of bugs he has to deal with, I'd think.


-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:32 PM.

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