[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PackageACLOpening and NewMaintainerContainment Re: Plan for tomorrows (20071220) FESCO meeting

On 20.12.2007 14:46, Jesse Keating wrote:
> On Thu, 20 Dec 2007 09:15:57 +0100
> Thorsten Leemhuis <fedora leemhuis info> wrote:
>> I'd like to ask FESCo to please not realize the PackageACLOpening
>> proposal without the NewMaintainerContainment. In fact if FESCo should
>> I'll continue to lock down my packages just because I fear the risk
>> that a just-sponsored-contributers puts something bad (e.g. malicious
>> code) into one of my packages in CVS (even if then there are much
>> better targets to get bad code out to users easily) and uses the
>> CTRL+C trick to prevent a commit message.
> I see them as somewhat related as well.  However if you notice from the
> proposal that maintainers will be given the opportunity to easily
> opt-out of opening their packages, so that we /could/ if we so choose
> do the opening now before new maintainer containment is in full swing,
> since that will likely prove to take longer to set up.

Well, sure, but it might mean double work for some maintainers (first
agreed to open, later close again when the containment is in full
swing). The end results also might be quite different depending on how
and when the "PackageACLOpening" is announced, as most people won't flip
the bits twice.

Currently the whole things sounds a bit like:

now: ACLs for all packages get removed by default to allow everyone
access everywhere to fix things
soon after: we do a proper solution where trusted people get access
everywhere as giving everyone (including freshly sponsored contributers)
access everywhere is a security risk

I'd much prefer to omit the first step, continue a few weeks more with
the current practice and merge the "PackageACLOpening" into the
"NewMaintainerContainment" with a sane default.

/me wonders if we actually need a "Package open for all cvsextras
members" at all once the NewMaintainerContainment is in place; why
should we give new packagers access on packages they should not deal with?

>> While on the CTRL+C issue to prevent commit messages: will FESCo
>> continue to ignore it?
> From what I gather in the past, there is no way to fix this outside of
> moving to a different SCM. 

Last time we looked was about one year ago and for Extras only. Now
after the merge the problem IMHO is way more dangerous as more popular
packages (better targets) are in the mix.

>> Further: I'd like to ask FESCo to add a rule to that all proposals
>> have to be posted to this list as full text with a special tag in the
>> subject (something like [Proposal for FESCo voting]) -- currently its
>> IMHO way to easy to miss a proposal that come up for FESCo voting.
>> And often only links gets posted to the wiki pages -- the result
>> afaics is that only a few people click on the link, even less read,
>> and even less comment on it; if they comment then in the wiki, where
>> others miss it.
> That's not a terrible idea.  Would you be willing to work up a "how to
> propose something to FESCo" page on the wiki?  I looked for one once I
> created an easy to use wiki template that can optionally be used for
> creating proposals, but I couldn't find it.  Would you like to make one?

I wrote that months ago already ;-) See:


Section "Meeting shall be quick";
So we need to get informations exchanged all of the time and prepare the
meetings properly. That means for example:
* proposals need to be written before the meetings and put up for
discussion or further enhancements for some time -- discussions should
happen on fedora-devel-list normally, as that allows non-FESCo-members
to get involved, too (and that's what we want!). The results from the
discussion should be integrated into the proposal. Mention things that
are controversial in the status section and we'll discuss them in the

Clarifying the wording or adding something like a "proposal must be in
the wiki and posted as full text (by copying the sourcecode of the
wikipage) to the list" somewhere should do the trick and is likely way
better then yet another inflexible template or written down bureaucracy
("to do <something easy> you have to follow <these ten steps>")


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]