On 20.12.2007 14:46, Jesse Keating wrote: > On Thu, 20 Dec 2007 09:15:57 +0100 > Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> 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: http://fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines 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 meetings. 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>") Cu knurd -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
