Updated co-maintainership proposal -- guidelines

[Hans de Goede]

Thorsten Leemhuis wrote:
> On 19.02.2007 10:47, Hans de Goede wrote:
>> The new parts look good, I still see little value in the:
>> "=== Don't (co-)maintain too many packages ===" and
>> "=== Other aspects of co-maintainership ===" pieces, they make the 
>> whole document way too long to read with little added value IMHO.
> 
> I think they are worth it. I want to get new contributors into the 
> project and that is the first step into this direction for a alternative 
> way. Sponsorship doesn't scale endlessly.
> 
> It doesn't work already anymore. Just imagine *me* wanting to start 
> getting involved today (if I wouldn't have started years ago) -- I would 
> not know what to package as everything I use or I'm interested in is 
> packaged already. But I could start as a co-maintainer for another 
> package, without access to the buildsystem and observed by the primary 
> maintainer.
> 
> But if you have a better idea to get new people involved and grown up in 
> Fedora Packaging lang: tell us, as I really think that's hardly needed, 
> as otherwise we have a "open" Fedora (Core) sonn, that's only open to a 
> small group (~300 people) of formally Extras packagers, but still closed 
> to the rest of the world, as it doesn't find a way in. That would be 
> nearly no improvement.
> 

I don't object to the message, but I feel an vision piece like this, 
about how things should be, doesn't belong in a guidelines document, no 
matter how soft/hard the guidelines in the document, the vision piece of 
it doesn't give much guidance and thus belongs in a seperate document.

About there not being much interesting stuff left to package, I 
disagree. I can still give a long list of somewhat pupolar games missign 
(glchess for example) and currently I'm working on packaging 
cross-compilers for the avr microcontroller and the gp2x handheld. But I 
agree that it would be usefull to have a different entry path. The 
problem here is, that most of us are currently maximally loaded with FE 
"work", thus if we get co-maintainers we (I) don't want that to cause 
any additional work, the concept of co-maintainers should lower the 
actual workload of the primary maintainer. I myself would like to see a 
couple of people who will be able to take a bunch of the more simple 
packages of my hand, and that I then become the co-maintainer, watching 
over their shoulder for a while to catch any grave mistakes.

Regards,

Hans