Announcing the release of Fedora 15 Beta!!

[Michael Schwendt]

On Tue, 26 Apr 2011 19:11:16 +0200, KK wrote:

> > Will you resurrect the packages when their package maintainer retires
> > them after F-15 gold despite of you having fixed them to build?
> 
> Retiring the packages is evil in the first place, and IMHO we're making it 
> way too easy. Packages should only get retired if they are replaced by 
> something different with equivalent or superior functionality or if they 
> really cannot be made to work at all (e.g. because they depend on an online 
> service that went away). The mere lack of an active maintainer shouldn't be 
> a reason to retire a package.

It's the opposite. The lack of an active maintainer is harmful. In particular,
if the maintainer used to work on multiple packages. That moves one step
closer to the infamous dumping ground for poorly maintained packages. The
"nobody is responsible for this package - anybody is free to mess with
packages - and it could be that a package just doesn't get any love at all
because nobody even _tries_ to give it some love".

Who will decide on when to upgrade? Who will monitor upstream development
(for the case that the pkg maintainer is not an upstream dev)? Who will
work together with upstream on fixes where upstream development is
beneficial?
 
> > Do you take over packages where it is discovered that they are
> > unmaintained in Fedora for a long time?
> 
> Depends on the package. But see above, I don't think being unmaintained 
> should be a reason for dropping the package, as long as it works.

What about packages that don't work? (where a rebuild or build-fix doesn't
make the software work) What about existing problem reports? Who will
handle them? Who will forward them upstream? Who will see if upstream
has pending fixes in their source repo?

If you have interest in a package beyond just fixing something in Rawhide,
you should sign up as a [co-]maintainer of that pkg for the dist releases.

> An effective way to distribute the load is to form a SIG of provenpackagers 
> stepping in to fix broken dependencies, FTBFS issues etc. This has been 
> proposed a few times, I'd still be willing to sign up! The point is to 
> DISTRIBUTE the load instead of relying on a single point of failure (the 
> maintainer of the package).

Here I also experience the opposite. An increasing number of package
maintainers just don't have any spare cycles to even consider spending
time on other people's packages. Except when there are dependencies that
need to be dealt with (and e.g. require porting something to a changed
API). Also pay attention to what people give as reason when they declare
a package an orphan. No time, no interest anymore, not using the pkg
anymore. And *you* want to jump in everytime that happens and play with
the growing pile of packages whenever you like to?

> Well, yes. I cannot sign up to maintain 1000 packages (this just doesn't 
> scale), but I can step in and make them build again when they're broken. 

How many? 100? 1000? ;-)

> (I've done it several times in the past.) And as I said elsewhere in this 
> thread, it's better to have a package available as is than to not have it at 
> all!

Unconvincing. You want the "quantity vs. quality" game? It's still better
to _try_ to offer stuff that works and _try_ to add some value to it
(bug-fixes, updates, testing, cherry-picking of releases perhaps, ...).
Even without any guarantees, it's the attempt that counts.

> That's exactly why I shouldn't be the only one doing this work! I haven't 
> been able to do broken dep fixing for a while and it shows.

With a statement like that, you've just driven a nail into the coffin.
One or two overworked members of the "Dumping-ground Maintenance Squad",
and the whole plan of jumping in where possible, becomes unfeasible.
First you try to replace missing maintainers, then it becomes necessary
to replace a lack of SIG members. ... And eventually the SIG learns that
the number of non-working packages (with a growing bug count) increases
despite the steady grunt-work to rebuild stuff.

> By the way, I'm not the only one who used to fix broken dependencies every 
> so often. Alex Lancaster often fixed a lot of them, as did some other 
> people. But instead of encouraging such fixing and having an organized SIG 
> formed for it, we get told not to do it. Do you really think this is in the 
> best interest of our users?

Yes, for the various reasons given before. 

The commitment to rebuild arbitrary packages doesn't say anything about
what would be done to _try_ to maintain the packages as one piece of
the Fedora Package Collection.

> > Don't generalize. I refer to the scenario where weeks or months pass
> > without a package "owner" doing basic package maintenance and without
> > asking for help. There are various examples, and I've looked up one
> > for you:
> > 
> >   https://bugzilla.redhat.com/460557
> 
> I think you, or any provenpackager really, should just fix those obvious 
> issues. I might even do it myself, even though I don't use this package at 
> all.

Where does this start? Where does it stop? One person spends some time on
pushing a package through the review process, and some time later you find
something more on your SIG's plate.
 
> >> I think it is of value to Fedora to ship as much (useful and properly
> >> licensed) software as possible.
> > 
> > _Working_ software. With the Fedora Packager handling incoming problem
> > reports, because the problems may be specific to Fedora.
> 
> The software usually works. If it really doesn't, we need to get somebody 
> (whoever) to fix it, even if it's a fire-and-forget fix. The important thing 
> is that the package is working. How it gets working is not so important.

Wishful thinking.
 
> >> That software is clearly useful to somebody
> >> or it wouldn't have been packaged in the first place.
> > 
> > "Somebody" could be just the package submitter. And if that person isn't
> > active anymore (sometimes without prior announcement), who else is left?
> 
> If really nobody uses the package, why do we care if it's broken?

What matters is whether we offer installable software that doesn't work.
We can't tell how many users try and give up (and continue with an own
build to /usr/local because it might be that upstream offers something
that works). And uninstallable packages (with unresolvable deps or
conflicts) are considered painful by our users.