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, 09:03 AM
Hans de Goede
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

Hi,

On 01/15/2010 09:06 PM, 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.
>>
>> What about the other packages of these maintainers? E.g. in the
>> recordmydesktop case, there were four bugs open with working patches
>> attached for that package. I did not yet check the other packages, but
>> in case a packager does not have the time anymore to maintain one
>> package from this list, why do we assume that he has the time to
>> maintain the others?
>> So before the mass orphaning is done, it would be nice to do it in a way
>> that allows to at least easily spot which maintainers owned the packages
>> before the orphage, so non responsive maintainers can be found easier.
>> Or tell all maintainers in question and orphan all their packages. But
>> the current solution seems to be only half-baked.
>
> I made sure that no one who fixed a package was actually the package
> owner.
>
> Pre-orphaning:
>
> evolution-brutus bpepple
> geronimo-specs fnasser
> gmfsk bjensen (fixed by caolanm)
> gnome-scan deji
> Io-language orphan (fixed by caolanm)

Used to be owned by: hdegoede, who took ownership of it again
yesterday as he didn't knew it was orphaned. I hope you
didn't orphan it again, but I'll check.

> knm_new-fonts orphan
> libFoundation athimm
> ohm cjb (should be dead)
> perl-AnyEvent-XMPP allisson (WIP by spot)
> perl-Class-InsideOut cweyl (fixed by Ralf)
> perl-Jemplate cweyl (fixed by Spot)
> perl-MooseX-Traits-Attribute-CascadeClear cweyl (spot says kill it)
> perl-RRD-Simple cweyl (spot says kill it)
> perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it)
> perl-SVN-Simple iburrell
> prctl karsten
> qtiplot frankb
> skychart lkundrak
> smarteiffel orphan
> synce-kde awjb
> unifdef dwmw2
> widelands karlik (WIP by hdegoede)

I'll pick up this one.

> xpilot-ng wart (fixed by hdegoede)

I know wart as a very active Games SIG contributor, and I'm
against just orphaning this single package of him. I've not heard
anything from him in a while. It might be a good idea to actually
use the awol maintainer procedure here. This way we can find out
if he really is MIA, and if so deal with all his packages.

Note the same argument can be made for all of the packagers in
this list!

> xqilla10 orphan
> xqilla orphan
>

Regards,

Hans

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 09:08 AM
Hans de Goede
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

Hi,

On 01/16/2010 12:14 AM, Jesse Keating wrote:
> On Fri, 2010-01-15 at 22:58 +0100, Till Maas wrote:
>> But what about the other packages by these maintainers that do not fail
>> to build but are probably as unmaintained as the packages that fail to
>> build?
>>
>
> Because this isn't a fully proper non-responsive maintainer approach, we
> felt it was only necessary to orphan the particular packages in
> question. These maintainers may have been active elsewhere, and
> wholesale orphaning with very little notice does not seem appropriate.
>

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.

Regards,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 09:12 AM
Hans de Goede
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

Hi,

On 01/15/2010 08:17 PM, 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.
>
>> awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628
>> evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451
>> geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494
>> gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780
>> gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591
>> Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617
>> knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487
>> libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470
>> ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200
>> perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749
>> perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
>> perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984
>> perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570
>> perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964
>> perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770
>> perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729
>> prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64)
>> python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675
>> qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688
>> recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931
>> skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202
>> smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362
>> synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195
>> unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553

>> widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430
>> xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717

Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great!
Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ?

Thanks,

Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 10:55 AM
Michael Schwendt
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, 16 Jan 2010 10:59:56 +0100, Hans wrote:

> On 01/15/2010 09:01 PM, Till Maas wrote:
> >
> > What about the other packages of these maintainers? E.g. in the
> > recordmydesktop case, there were four bugs open with working patches
> > attached for that package. I did not yet check the other packages, but
> > in case a packager does not have the time anymore to maintain one
> > package from this list, why do we assume that he has the time to
> > maintain the others?
> > So before the mass orphaning is done, it would be nice to do it in a way
> > that allows to at least easily spot which maintainers owned the packages
> > before the orphage, so non responsive maintainers can be found easier.
> > Or tell all maintainers in question and orphan all their packages. But
> > the current solution seems to be only half-baked.
> >
>
> 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

That view is overly pessimistic.

We are in need of more automated procedures and more automated triggers.
And we need to find ways how to detect non-responsive, inactive or
overwhelmed contributors sooner. Fedora has grown out of proportions. It's
good to see the community of contributors grow further, but in some areas
it doesn't scale nevertheless.

There is only a single package owner in pkgdb. A single person who is the
default assignee of tickets in bugzilla. We should aim at making every
assignee in bz a person who is responsive OR have enough co-maintainers on
the watchbugzilla list to be responsive instead.

It doesn't work well if arbitrary packagers "keep alive" a package without
being the package's official maintainers -- and if the assignee is like
/dev/null for problem reports or perhaps has left the project already.
We can't wait for the one in a thousand bug reporters who will escalate a
problem instead of resigning in disappointment. Two months without a
reply, three months without a reply ... what to expect?

FESCo ought to give the FTBFS tickets a special status. Unhandled FTBFS
tickets will trigger the AWOL procedure for the assignee in bugzilla. The
assignee will have to respond to the various pings and fix the package
ownership in pkgdb if appropriate. A single reply in multiple weeks or an
extended period of time. No harm is done if others need to take care of
the package temporarily anyway. If somebody else has fixed the FTBFS
meanwhile, consider yourself lucky. Then you've avoided the FTBFS->AWOL
trigger, and some other monitoring software will need to detect
non-responsiveness, inactivity, orphans.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 01:50 PM
Matt Domsch
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt 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.

In general I've been running the FTBFS scripts about monthly; maybe
less so as we approach a release (nearly all packages get rebuilt,
especially if there's a mass rebuild that happens). I think that's
frequent enough to detect FTBFS; also we're not yet proposing dropping
packages that don't rebuild in F13 yet; only those that never got
rebuilt for F12. So the FTBFS now-orphaned packages are at 1 year old
with no real progress to speak of.


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

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?

Thanks,
Matt


--
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-16-2010, 02:31 PM
Kyle McMartin
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
> > unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553

i fixed this, but i think we should still remove it because it has been
superceded by the superior sunifdef.

regards, kyle
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 04:01 PM
Matt Domsch
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 05:13:29AM +0100, Ralf Corsepius wrote:
> >> perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
>
> I intended to take this one, but the packagedb doesn't offer me an
> option to take it:
>
> C.f.:
> https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut
>
> This package appears to be owned by owner "orphan" and doesn't offer the
> "Take Ownership" button, I see on packages listed on
> https://admin.fedoraproject.org/pkgdb/packages/orphans
> otherwise.

Fixed in pkgdb now, thanks to Toshio.

--
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-16-2010, 04:08 PM
Till Maas
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 08:50:14AM -0600, Matt Domsch wrote:
> On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:

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

I do not like such artificial conditions that should show that a package
is still maintained. It will bother all maitainers that already maintain
their packages correctly. But this could be a techninal implementation
but with other conditions when such tickets are created, e.g. these
tickets could have been created for all maintainers still having FTBFS
packages without commenting on their bug reports recently. But there
could also be other conditions that trigger this, which still need to be
implemented.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 04:10 PM
Toshio Kuratomi
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Fri, Jan 15, 2010 at 10:39:17PM -0600, Matt Domsch wrote:
> On Sat, Jan 16, 2010 at 05:13:29AM +0100, Ralf Corsepius wrote:
> > On 01/15/2010 08:17 PM, Matt Domsch wrote:
> > Unfortunately, this has proven to be hard/impossible so far.
> >
> > >> perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136
> >
> > I intended to take this one, but the packagedb doesn't offer me an
> > option to take it:
> >
> > C.f.:
> > https://admin.fedoraproject.org/pkgdb/packages/name/perl-Class-InsideOut
> >
> > This package appears to be owned by owner "orphan" and doesn't offer the
> > "Take Ownership" button, I see on packages listed on
> > https://admin.fedoraproject.org/pkgdb/packages/orphans
> > otherwise.
>
My apologies,

Fixed in the db now. Working on backporting the pkgdb server fix that went
into trunk but not the production setup that prevents this from happening.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 01-16-2010, 04:23 PM
Toshio Kuratomi
 
Default Orphaning Candidate packages for removal due to FTBFS, implications

On Sat, Jan 16, 2010 at 11:12:03AM +0100, Hans de Goede wrote:
>
> >> widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430
> >> xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717
>
> Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great!
> Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ?

My apologies. Issue fixed in the database, have assigned the two packages to
you, and backporting the fixfor this that went into pkgdb trunk but hasn't
gone to the production instance yet.

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

Thread Tools




All times are GMT. The time now is 11:18 PM.

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