Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org:
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13
/topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy
/topic FESCo meeting -- Free discussion around Fedora
You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, since we have a pretty full schedule). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase.
If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing...
Later, /B
On Wed, Dec 19, 2007 at 01:49:24PM -0500, Brian Pepple wrote:
Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org:
The automatic mailing of multiarch conflicts...
-- Pat
On Wed, 19 Dec 2007 13:49:24 -0500, Brian Pepple wrote:
Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org:
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13
/topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy
/topic FESCo meeting -- Free discussion around Fedora
You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, since we have a pretty full schedule). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase.
If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the
^^^^^^
?
other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing...
Later, /B
On 19.12.2007 19:49, Brian Pepple wrote:
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13
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.
While on the CTRL+C issue to prevent commit messages: will FESCo continue to ignore it?
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.
IOW: no real discussion comes up and contributers don't get involved into the decision finding process. That's not what FESCo wants -- or is it?
CU knurd
On Thu, 20 Dec 2007 09:15:57 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
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.
+1
IOW: no real discussion comes up and contributers don't get involved into the decision finding process. That's not what FESCo wants -- or is it?
No.
josh
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.
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. I could be wrong, but quite frankly on the list of things I'd like to accomplish, fixing this is pretty low on the list. I don't think /anybody/ in FESCo would turn down a fix for this, should some enterprising soul provide one.
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?
IOW: no real discussion comes up and contributers don't get involved into the decision finding process. That's not what FESCo wants -- or is it?
Nope, that's not what we want at all.
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:
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
On Thu, 20 Dec 2007 15:25:47 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
then yet another inflexible template
Is this a thinly veiled dig at the proposal template I created? Do you have actual feedback you'd like to give on it?
On 20.12.2007 15:34, Jesse Keating wrote:
On Thu, 20 Dec 2007 15:25:47 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
then yet another inflexible template
Is this a thinly veiled dig at the proposal template I created? Do you have actual feedback you'd like to give on it?
You mean http://fedoraproject.org/wiki/Development/FescoProposalTemplate ?
No, looks fine and certainly is helpful for those that want to be guided. But sometimes it might be easier for people to say it in different ways, and that should be allowed. And a problem I fear a lot is this:
Contributer: "I want to do foo, to do bar"
FESCo: "Please use the template"
Contributer: "But foo is self-explaining. Why do I have to write such a lengthy proposal? I have no time for such crap."
End result: nothing gets done.
Cu knurd
On Thu, 20 Dec 2007 15:54:27 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
No, looks fine and certainly is helpful for those that want to be guided. But sometimes it might be easier for people to say it in different ways, and that should be allowed. And a problem I fear a lot is this:
Contributer: "I want to do foo, to do bar"
FESCo: "Please use the template"
Contributer: "But foo is self-explaining. Why do I have to write such a lengthy proposal? I have no time for such crap."
End result: nothing gets done.
That's why it's listed as optional.
On Thu, 2007-12-20 at 15:54 +0100, Thorsten Leemhuis wrote:
You mean http://fedoraproject.org/wiki/Development/FescoProposalTemplate ?
No, looks fine and certainly is helpful for those that want to be guided. But sometimes it might be easier for people to say it in different ways, and that should be allowed. And a problem I fear a lot is this:
Contributer: "I want to do foo, to do bar"
FESCo: "Please use the template"
Contributer: "But foo is self-explaining. Why do I have to write such a lengthy proposal? I have no time for such crap."
End result: nothing gets done.
That is why the proposal template isn't mandatory, merely suggested.
Later, /B
On 20.12.2007 16:24, Brian Pepple wrote:
On Thu, 2007-12-20 at 15:54 +0100, Thorsten Leemhuis wrote:
You mean http://fedoraproject.org/wiki/Development/FescoProposalTemplate ?
No, looks fine and certainly is helpful for those that want to be guided. But sometimes it might be easier for people to say it in different ways, and that should be allowed. And a problem I fear a lot is this: Contributer: "I want to do foo, to do bar" FESCo: "Please use the template" Contributer: "But foo is self-explaining. Why do I have to write such a lengthy proposal? I have no time for such crap." End result: nothing gets done.
That is why the proposal template isn't mandatory, merely suggested.
I didn't say otherwise. I made the "I have something self-explaining that should be corrected without writing a proposal"-experience with another committee in Fedora-land ;-)
Cu knurd
On Thu, 2007-12-20 at 16:50 +0100, Thorsten Leemhuis wrote:
I didn't say otherwise. I made the "I have something self-explaining that should be corrected without writing a proposal"-experience with another committee in Fedora-land ;-)
Since I'm assuming that you're talking about the FPC here, let me state the reason why the FPC requires that all proposals be written up:
Because otherwise, we forget about them.
If they're written up on the wiki and added to our agenda list, then we remember them and discuss them.
We don't even require any format. Just write it up, put it in the list. If you can summarize the change in a single sentence, you can even just add that to the agenda.
See:
http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
~spot
(ps. if you're not talking about the FPC, my apologies, just think of this as a reminder for everyone on how to get issues on our radar)
On 20.12.2007 16:54, Tom "spot" Callaway wrote:
On Thu, 2007-12-20 at 16:50 +0100, Thorsten Leemhuis wrote:
I didn't say otherwise. I made the "I have something self-explaining that should be corrected without writing a proposal"-experience with another committee in Fedora-land ;-)
Since I'm assuming that you're talking about the FPC here, let me state the reason why the FPC requires that all proposals be written up: Because otherwise, we forget about them.
If they're written up on the wiki and added to our agenda list, then we remember them and discuss them.
a) if there wasn't ACLs in the wiki then I would have done the change in question myself after a proper discussion on the mailing list. No need to discuss that in the IRC meetings, no need for wiki changes, less work for the committee, no need to remember about it for days or weeks. In short: less bureaucracy for everyone. Sure, if a agreement can't be found on the list, then the committee in question needs to take care of it, which brings be to point b:
b) if you want it written down to prevent that you forget it then you have to write it down yourself now and then if the one that brings a issue up doesn't do it. That's how I handled it in FESCo when I was chair and that's how I handle in EPEL atm as well.
Sure, I sometimes missed issues, don't notice that something should be discussed further and some things fall of the radar after some weeks -- but I bring a lot of things up in the EPEL SIG meetings that were raised on the list, even if the reporter has moved on to something else in between. That what I expect from a committee and it's chair.
And sure, I would be happier if people always take care of stuff they bring up own their own. But they don't, I have to live with it and take care of the stuff to make sure things get improved, as a lot of people don't have the energy do deal with committees.
CU knurd
On Thu, 2007-12-20 at 09:15 +0100, Thorsten Leemhuis wrote:
On 19.12.2007 19:49, Brian Pepple wrote:
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13
I'd like to ask FESCo to please not realize the PackageACLOpening proposal without the NewMaintainerContainment.
-1
PackageACLOpening is a step into the right direction to colaborative maintainership, to less bureaucracy and to a more efficient and flexible workflow.
However, I find coupling it to NewMaintainerContainment would void most of the benefits PackageACLOpening opens, because it ties access to a small group ("sponsors"). That said, I think it should be extended to a more general notion of "groups", e.g. SIGs, <LANG>-specialists, etc., such that groups on people can collaborate on groups of packages[1].
Ralf
[1] E.g. perl packages. The perl-SIG recently tried to add "perl-sig" as owner of a larger set of packages whose maintainer got AWOL, but we've been told that the packagedb doesn't support this. We ended up with dividing the dead packages between us, and "informally mutually granting" access. If the NewMaintainerContainment became effective, we probably would have to resort to explicitly adding us to all of our packages (I am talking about several 100s of packages).
On Thu, 20 Dec 2007 15:01:16 +0100 Ralf Corsepius rc040203@freenet.de wrote:
However, I find coupling it to NewMaintainerContainment would void most of the benefits PackageACLOpening opens, because it ties access to a small group ("sponsors"). That said, I think it should be extended to a more general notion of "groups", e.g. SIGs, <LANG>-specialists, etc., such that groups on people can collaborate on groups of packages[1].
Ralf
[1] E.g. perl packages. The perl-SIG recently tried to add "perl-sig" as owner of a larger set of packages whose maintainer got AWOL, but we've been told that the packagedb doesn't support this. We ended up with dividing the dead packages between us, and "informally mutually granting" access. If the NewMaintainerContainment became effective, we probably would have to resort to explicitly adding us to all of our packages (I am talking about several 100s of packages).
Please don't think that new maintainer containment is a set in stone proposal. In fact, one of the open questions is who gets added to the set of folks who gain wide access. I want that group to be as big as possible, just not inclusive of new packagers.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 20 Dec 2007 09:09:03 -0500, you wrote:
Please don't think that new maintainer containment is a set in stone proposal. In fact, one of the open questions is who gets added to the set of folks who gain wide access. I want that group to be as big as possible, just not inclusive of new packagers.
On the propasal you can read something about a karma system to evaluate the new mainteiner from the new maintainers group into the whole access group.
Because that means some effort of changes on the FAS to implement this idea, I will suggest a time expiration idea. The new maintainer will added into the new maintainers group after he was approved from his sponsor. After a time periode for example two months a group add request to the whole access group will be generated automaticly on the FAS. Now the sponsor have to approve this new group request for the new maintainer, so he can get into the regular whol access group.
On a second step we may implement the discussed karma system. But I see the need for a guildlines about how a newbie can earn the karma he needs to rise into the whole access group.
For the groupname I will suggest:
cvsnew Group for the new maintainers
cvsextras General group for the packagers
A second topic should be finding a new name for the cvsextras group, because the name of this group is related on the obsolete Fedora Extras project. My suggust may be cvspckg which stands for Cvs PaCKeGers.
Best Regards:
Jochen Schmitt
On 20.12.2007 15:01, Ralf Corsepius wrote:
On Thu, 2007-12-20 at 09:15 +0100, Thorsten Leemhuis wrote:
On 19.12.2007 19:49, Brian Pepple wrote:
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13
I'd like to ask FESCo to please not realize the PackageACLOpening proposal without the NewMaintainerContainment.
-1 PackageACLOpening is a step into the right direction to colaborative maintainership, to less bureaucracy and to a more efficient and flexible workflow.
I'm all for "colaborative maintainership,"(I'd call it wiki-style maintenance effort), but I don't think that means we need to remove all things that protect the security of the bits we provide.
Opening CVS more sounds to me like having a club house with all the valuable things that were created over the past years in it and all inner doors unlocked where every just approved club member gets a key to the entrance. Would you do that in a club with over 500 members where it's not that hard to become a club member?
However, I find coupling it to NewMaintainerContainment would void most of the benefits PackageACLOpening opens, because it ties access to a small group ("sponsors").
See f13's post, it's not about sponsors, they are just a example and a group of contributers we trust. I agree with f13 that the group needs to be bigger then just sponsors (albeit I afaics want it a bit smaller then what f13 thinks about)
That said, I think it should be extended to a more general notion of "groups", e.g. SIGs, <LANG>-specialists, etc., such that groups on people can collaborate on groups of packages[1].
Sounds good -- maybe that could be added to NewMaintainerContainment, as the changes that are needed for that are likely similar?
[...]
CU thl
On 12/19/2007 07:49 PM, Brian Pepple wrote:
Hi,
Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org:
I will be unable to attend, sadly.
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13
+1 *IFF* NewMaintainerContainment is approved.
/topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13
In general, +1.
Discussion points:
* How do maintainers get added to the elevated group?
N number of people in the elevated group vouch for them. I think a good number of N is 2.
* What maintainers are grandfathered in?
We need to ensure that packagers that sometimes need to touch a large portion of packages that they don't own (for dependency rebuilds, package cleanup, rel-eng, etc) are still able to.
* Formal process for revoking access.
We should probably have a way to revoke access in the unlikely case someone goes postal...
/topic Status Update: Compat Policy http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages - jeremy
"It also means that security changes, fixes, etc. "
Huh? :-)
I think the idea is right, but it could be better organized. Bulleted lists make things easy to see. Something like.... http://caillon.fedorapeople.org/compat.html
-
Brian Pepple -
Christopher Aillon -
Jesse Keating -
Jochen Schmitt -
Josh Boyer -
Michael Schwendt -
Patrice Dumas -
Ralf Corsepius -
Thorsten Leemhuis -
Tom Callaway