[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