[ACTION REQUIRED] Retiring packages for F-17

[Ralf Corsepius]

On 01/13/2012 10:51 PM, Michael Schwendt wrote:
> On Fri, 13 Jan 2012 21:03:09 +0100, KK (Kevin) wrote:
>
>> When we're in danger of losing so many packages, it's a sign that our
>> processes are broken:
>
> That's a dubious conclusion.
I concur with Kevin.

>> * The whole concept of packages being "owned", and by one person at that, is
>> broken.
>
> No, it isn't.
To me, it's obvious, this concept doesn't work well anymore.

> Even in the scenario of project-wide write-access to packages,
> there must be someone to decide when to perform an upgrade.
... but this someone doesn't have to be an individual nor does it have 
to be the package maintainer. It can be a group, it can be an expert or 
a group of experts etc.

The "1 package:1 owner" model works in commercial environments, where 
"supposed to be skilled professionals" are supposed to be in _charge_ of 
"customer care". It doesn't work well in an environment run by 
volunteers, who often are laymen, work in their spare time and can not 
be forced to anything.

>> Fedora as a whole should feel responsible for those packages, commit
>> access should be open to ALL packagers (not just provenpackagers) as in the
>> good old Extras, and there should be experienced packagers actually stepping
>> in to rebuild packages with broken dependencies, fix FTBFS issues etc. (I
>> used to do that, but I had to mostly give up because nobody else would help
>> (Alex Lancaster used to help fixing broken dependencies, but mostly doesn't
>> anymore)
Well, I also did several times, but often found me stuck in bureaucracy 
and often got stuck in a web of bugs elsewhere - in short, not a pretty 
tedious experience.

>> Any package which is removed from Fedora is a package our users will no
>> longer be able to use. Removing a package should only be a last resort if it
>> cannot be made to work at all.
>
> No. We need _more_ packagers, even if that means, many more _newbie
> packagers_.

Do you realize that such "demands for more people" often are symptoms of 
a failing system?

The common alternatives are to "improve efficency" and to "improve 
productivity" using those resources you have available. Approaches into 
this direction would be "teaming up", "less burecracy" and a "less 
volatile basis" to work with.

Ralf