[ACTION REQUIRED] Retiring packages for F-17

"Jóhann B. Guðmundsson" johannbg at gmail.com
Sat Jan 14 10:31:10 UTC 2012


On 01/13/2012 09: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.

Agreed the current process only highlights the underlying cause.

There is no point in shipping packages in the distribution if there is 
nobody there to maintain it.

>
>> * The forced password and SSH key change caused us to lose many maintainers,
>> not all of whom would have become inactive if it hadn't been for such stupid
>> asinine and totally useless (since the keys were NOT compromised) "security"
>> bureaucracy being forced on them, wasting their time.
> Are you trying to say the Fedora Project has made it much too easy for them
> to leave and have their account disabled, too?

Agreed here as well and I have to say that I also agree with how 
infrastructure team is handling.

Their process both identifies who are no longer with the project and 
keeps it secure at the same time.

>
> What doesn't work is that we're supposed to "sponsor" people, who dump
> packages into the collection without really trying to take care of them
> afterwards. With no other users of those packages joining the team that
> tries to maintain the packages. With bug reports being ignored. With the
> initial packagers abandoning the Fedora Project without prior warning.

Agreed.

>> * The whole concept of packages being "owned", and by one person at that, is
>> broken.
> No, it isn't. Even in the scenario of project-wide write-access to packages,
> there must be someone to decide when to perform an upgrade. And someone
> dedicated, who would be reachable via bugzilla tickets. [Unfortunately,
> the latter doesn't work well anymore.] And someone to monitor upstream,
> or contribute upstream, and collaborate with upstream. [here insert stuff
> that has been discussed before]

Agreed.

>> 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, that's not entirely true, because there are still provenpackagers,
> who rebuild broken deps _if_ they are affected by them. I see no reason
> why I should spend time on packages nobody else takes care of. The packages
> need more treatment than rebuilds. There are open bug reports, too.

Agreed.

>> and I don't have the time to do it all alone anymore.)
> Which is proof that your entire proposal won't work either.

Agreed.

>> 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_. If there is at least one user for package, at least one of
> these users ought to contribute to the packaging.
>

Agreed with the added point that we also need to put limits on how many 
packages an single individual can own/maintain/co-maintain regardless of 
the nature of the package ( high maintenance/low maintenance).

Finding that magic number should not prove too difficult something along 
the lines of 8 hour sleep + 8 hours work + 2 hours in meals + 2 hours 
recreation/family leaving 4 hours of the whole day to do various 
voluntary community stuff.

Let's say on average it takes 30 minutes to deal with a single bug 
report against a component and let's say on average that each component 
in the project gets one report per day which gives us a maximum of 8 
packages which an single individual can maintain or co maintain within 
the project so 8 would be that magic number.

JBG



More information about the devel mailing list