New package cvs requests. opt out of cvsextras commit rather than in?

Lubomir Kundrak lkundrak at
Wed Dec 5 12:59:16 UTC 2007


On Wed, 2007-12-05 at 13:25 +0100, Thorsten Leemhuis wrote:
> On 05.12.2007 13:02, David Woodhouse wrote:
> > On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote:
> >> I think open by default is reasonable. 
> > I agree.
> I disagree for packages that have at least one co-maintainer.

Definitely makes some sense. Packages that have a more maintainer are
more likely to deserve all the love they deserve compared to ones who
get to Fedora from Core and have a single maintainer with cvsextras off
by default (I've seen a maintainer of ex-Core package that was not even
aware that noone else but him can commit).

> >>  For those packages that want tighter control perhaps "Private
> >> Commits" would be good wording.
> > It would be nice if you also needed to give a _good_ reason for making
> > it private. Perhaps even a reason which is approved by FESCo in advance.
> "I fear that a just sponsored contributer puts something bad in one of
> my packages" and "the CTRL+C trick in CVS still works, thus I as
> maintainer might not even get a mail if someone changes my package(¹)"
> are the reasons why I excluded cvsextras for those of my packages that
> have co-maintainers.

Why would he put something bad? Being malicious? He can do that in
different places also when he has a FAS account, is in cvsextras and can
build packages. Being not experienced enough? That's the purpose he has
a sponsor for. (btw that CTRL+C thing should get fixed, is there an
infra ticket for it?)

> OTOH I think we IMHO should have a group in FAS called something like
> "experienced maintainers" with sponsors and long term contributers that
> gets access everywhere; I trust those way more then a just-sponsored
> contributer that came out of the blue.

I'd say all sponsored people are "experienced maintainers". Those who
are not experienced do post their work in bugzilla. At least I think of
sponsorship should serve exactly this purpose, if you believe it is not,
then it is unuseful and have to be dealt with somehow. If we solved that
by separating the group further, we may end up with something like
"extra most super experienced maintainers" groups.

Lubomir Kundrak (Red Hat Security Response Team)

More information about the fedora-devel-list mailing list