Extras/SteeringCommittee/Meeting-20070208

2007 February 08 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Thorsten Leemhuis (thl)
• Warren Togami (warren)
• Jeremy Katz (jeremy)
• Christian Iseli (ch4chris)
• Toshio Kuratomi (abadger1999)
• Jason Tibbitts (tibbs)
• Tom Callaway (spot)
• Dennis Gilmore (dgilmore)
• Bill Nottingham (notting)
• Rex Dieter (rdieter)
• Josh Boyer (jwb)
• Kevin Fenzi (nirik)
• Jesse Keating (f13)

Absent

• Andreas Bierfert (awjb)

Summary

thl

• thl is leaving FESCo due to possible conflicts with his day job. FESCo would like to thank Thorsten for all his hard work while he was on FESCo. Thanks! BTW: here's a link to his blog entry about quiting FESCo: http://thorstenl.blogspot.com/2007/02/leaving-fesco.html

Core/Extras Merge

• FESCo will wait a week before making a decision regarding the Core Review process, to get further feedback from the community.
• Waiting for the new build system (Koji), which is still going through legal for the licensing.

Co-Maintainership

• thl worked on the proposal and adjusted the wording. He'll send it to FESCo members for review, and then to the public mailing lists.

cvs-import

• The plan is to modify cvs-import to 1) warn 2) look at a diff 3) make them type in a cvs comment.

Incompatible package upgrade policy

• Maintainers should be aware of the effects that changes to their packages may have, and should alert other maintainers on the mailing list of updates which contain ABI or API changes which may cause dependency problems for other packages.
• In the future, the new updates system will not let repo breakage occur.

Packaging Committee Report

• FESCo didn't have any objections to the Packaging Committee's guidelines regarding:
• non-pear PHP extension paths
• desktop files - http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles
• makeinstall clarification - http://fedoraproject.org/wiki/PackagingDrafts/MakeInstall
• Making the suggested buildroot mandatory
• All binaries must be built from source - http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
• buildrequires clarification - http://fedoraproject.org/wiki/PackagingDrafts/BuildRequires

MISC

• There was a discussion whether to have acl's enabled by default on new packages.
• notting discussed that FAB had recently talked about firmware which would require:
• make up a license tag for non-modifiable firmware for easy finding for users
• modify the EULA to add an exception clause for firmware (similar to the one currently for trademarked logos)
• release note the eula change
• start poking vendors
• jeremy mentioned that the bugzilla update script from owners.list should be running every 4 hours now.

Log

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
--> tibbs (n=tibbs@fedora/tibbs) has joined #fedora-meeting
<Bob-Laptop> Meeting in 6 blocks...
* dgilmore needs food
* jima munches on leftovers from dinner
<nirik> me is here.
sigh, and I can't type /'s apparently.
* jima hands nirik a / refill kit
<tibbs> me is here too.
<nirik> thanks jima
* thl is here, too
<jima> no problem
* thl is wondering if he is still in FESCo
<thl> what did we agree on regarding that
<bpepple> thl: I think it was fine if wanted to leave.  I can put something into today's minutes.
<nirik> thanks for all the hard work thl... hopefully you will be able to devote some time to epel and other fun things. ;)
<bpepple> FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
Hi everybody; who's around?
<c4chris> here
* thl sits down besides jima on the rable  seats
<rdieter> here
* dgilmore is here
cweyl|work hands thl some rabble popcorn
jeremy is here (or will be in a few minutes)
spot is here
wwoods lurking
<thl> bpepple, please make a note than I'll concentrate on EPEL and maybe some other stuff, and that I have due to my day job
<bpepple> thl: no problem.
* thl asks cweyl for a coke
<bpepple> Ok, it looks like most of FESCo is here, so we can probably get started.
--- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- status update
* bpepple doesn't see warren.
<nirik> I think there is confusion on the process, but things are moving along...
<bpepple> nirik: agreed.  I think the suggestion to wait another week, and then have FESCo make a decision sounds good.
<abadger1999> nirik: Thanks
<jeremy> bpepple: yeah, I think that's sane
<jeremy> and it lets us play with tweaks with the merge reviews just to see how well they work
<nirik> we have touched 13.8% of the core package reviews so far it looks like.
* jwb is 25% here, sick kid
<bpepple> jeremy: agreed.
<nirik> I like warren's last proposal, with one exception...
any status on brew freedom, and/or package database progress?
<dgilmore> nirik: not that i have heard
<bpepple> jeremy: what other items do we still need to address regarding the merge?
<dgilmore> abadger1999: have you looked at any of the things we talked about with the package DB
<jeremy> bpepple: I think buildsys is the big blocking thing right now...  I might need to spend some time being a pain for other people :-/
<abadger1999> dgilmore: Referring to fudcon discussions?
yes.
<dgilmore> abadger1999: yes
<tibbs> Does anyone know if the merge will preserve history?  Or are we importing the packages afresh?
<cweyl|work> just for clarification, the new review process only applies to the core/merge reviews at this point, yes?
<dgilmore> jeremy: please poke people till i get code
<abadger1999> My tentative plan for F7 is to have the packagedb sit on top of brew.
<notting> tibbs: i'd like to try to preserve history
<jeremy> cweyl|work: correct
<dgilmore> jeremy: if need be tell them i make visits
<jeremy> dgilmore: that's a scary concept :-)
<cweyl|work> jeremy: thx :)  makes me feel a little better about it
* f13 is getting very very upset at the delay :/
<abadger1999> Packagers can interact with the packagedb and it will pass along relevant commands to Brew.
Collection admins will probably have to interact with both :-(
<jwb> quick question...
<dgilmore> jwb: sure
<f13> abadger1999: koji can be used as an interface into the database
<jeremy> cweyl|work: the hope, though, is to move towards it for everything
<jwb> if a core package is orphaned (jfsutils, xfsutils) do we go ahead and review it and import it into extras CVS?
<abadger1999> f13: koji can interface with its own database.
<f13> abadger1999: koji add-pkg --owner=foo --cc=bar,baz dist-f7 <packagename>
<dgilmore> jwb: if we dont want to keep its cvs history
<abadger1999> But the longer we don't have the koji schema/koji system, the longer we have to wait to get work done.
<jwb> dgilmore, yeah, that's why i'm asking...
<notting> jwb: if you've got a maintainer, sure. but i want to know any such packages
<f13> abadger1999: there is no reason why the package DB and the Koji DB can't be one in the same.
<jwb> notting, jfsutils and xfsutils were orphaned by jgarzik
notting, i intend to pick up jfsutils
<f13> abadger1999: our guys internally hate it when we call it the "brew database" because it isn't.  Its a database that brew/koji makes use of, but not exclusively.
<cweyl|work> jeremy: which is probably a good long-term plan; but I've always been a plan of trying out significant changes like this on a subset first, work out the inevitable bugs/etc
<dgilmore> f13: they can be and long term will be
<abadger1999> And I'd like to get cvs ACLs working ASAP
<jeremy> cweyl|work: yep
<dgilmore> f13: but we need some additional stuff in the package db
<f13> dgilmore: indeed
<abadger1999> f13: I agree that by F8 I'd like to ave the two DBs merged.
<f13> databases are wonderful, they can have extra fields that are not cared about by some users.
<c4chris> any chance F7 will be built from a unified package pool ?
<dgilmore> c4chris: depends on getting code
<abadger1999> The problem is that there's no koji code right now that I can start to merge.
<f13> c4chris: F7 is composed from both package pools.
c4chris: pungi cares not what produced the packages, only that the packages are in a yum repo
<c4chris> f13, right, but current core packages cannot depend from current extras
<jwb> i think that rule needs to be broken
<dgilmore> c4chris: if need be we will have to bring core into plague  short term
<c4chris> jwb, sure, but only if the buildsys supports it
<f13> c4chris: technically no, it could break the buildsystem.
c4chris: we're poking at the lawyers many times a day to get this done.
* c4chris lends f13 a +7 sword :-)
<rdieter> f13: for kde, we *really* need (ok want) Extras' BuildDeps.
<dgilmore> rdieter: we need it
we need for the kdegraphics-extras packages to die
same as kdemultimedia-extras
<bpepple> Ok, we should probably move on, before this gets to off-topic.  jeremy, is there anything else we need to discuss regarding the merge?
<jeremy> not that I know of
<bpepple> Alright, moving on unless anyone objects.
--- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- all
* thl still here for two minutes
<thl> regarding co-maintainers; I worked on the proposal and adjusted the wording in a lot of places during my flight back from boston; but I need to check it once more; I'll send it to one or two FESCo members, then to the FESCO list again, then to the public
sorry, that's all for now
* thl needs to go afk soon
<thl> that way okay for everybody?
<bpepple> thl: works fine for me.
<jwb> yes
<jeremy> sounds good... thanks thl
<abadger1999> sure
<nirik> sounds good.
<c4chris> thl, yup, thx
--- bpepple has changed the topic to: FESCo-Meeting -- MISC -- kernel-naming - What did davej find out about this?
<bpepple> Did anyone get a chance to talk to Dave about this at FUDCon?
* thl now afk, cu guys
<dgilmore> seeya thl
* f13 remembers somebody talking to him about this
<jeremy> bpepple: I had a discussion with him about it before fudcon
<spot> we talked some during his presentation
<tibbs> Several of us talked about it with davej there.
<dgilmore> bpepple: there was a talk on making the kernel suck less
<spot> but he dodged it a bit
* dgilmore missed it though
<jeremy> realistically, things change significantly as we try moving towards keeping the kernel in git
<jwb> explain?
<jeremy> (which is the experiment about to be tried)
<nirik> perhaps we could continue discussion of it in the kernel package review.
<jwb> what does the SCM have to do with the RPM naming?
<jeremy> the marker for what's 2.6.20-git3 (or rc2 or whatever) is far less clear
<jwb> um...
well, true
<jeremy> not going to be doing 2.6.19 tarball + upstream patch + pile of patches
instead, git tree that follows along
<notting> or, 2.6.20-git3+dscpae+execshield+netdev
<nirik> perhaps it should just move to a YYYYMMDD scheme or something?
or whatever the guidelines says for git snapshots.
<jeremy> nirik: it's already just a monotonically increasing number
<jwb> jeremy, but it's _fedora's_ git tree right?
<jeremy> jwb: correct
<jwb> jeremy, why can't we create our own tags and base the rpm name off of that?
<jeremy> nirik: datestamps only work if you do one a day, which is commonly not the case with the kernel
<nirik> true. ;(
<notting> jeremy: kernel-%{time_t}
<warren> also with datestamps, what if you want to make an update release of an old datestamp?
<f13> just as long as we aren't using the git hash
<c4chris> down to the last jiffy :-)
<warren> confusing.
<jeremy> jwb: off of the tree hash?  or trying to do "wait, this commit is where rc2 is"?
<jwb> jeremy, no, an actual tag in git
<tibbs> The bottom line for me is that I am open to giving the kernel a pass on anything that doesn't actually break something.  It has maintenance requirements that are significantly different from most of the packages in the distro.
<jeremy> jwb: what would you like to name said tags?
<rdieter> imo, don't care, kernel (and glibc for that matter) deserve a fair amount leeway when it comes to packaging details.
tibbs++
<jwb> linus does 2.6.20-rcX tags, we could do 2.6.20-rcX-<something>
<bpepple> rdieter: I'm of the same opinion.
<jeremy> jwb: one thing that davej did say he'd look at was trying to make sure that LINUX_KERNEL_VERSION remain 2.6.20 when in 2.6.20rc, etc
<jwb> jeremy, that would be what i'm most concerned with
but it would be nice if the RPM NVR matched uname too :)
<dgilmore> jwb: except 2.6.20-rcX-<something>  is newer than 2.6.20-<something>
<jwb> oh, true
<jeremy> so package version remains 2.6.19-1.2619.fc7 (or whatever) until 2.6.20 comes out, but LINUX_VERSION_CODE at least shows 2.6.20-ish
<f13> well
to be fair, we have rules to accomplish this
2.6.20-0.
we have pre-release guidelines, if we're going to change up how the kernel is versioned, it might be nice to see if those guidelines can fit.
<dgilmore> f13: sure it would need to be 2.6.20-<something>-rcX
<jwb> jeremy, that might be a good compromise
<dgilmore> where <something starts with 0.
<f13> dgilmore: yeah, thats our pre-release guidelines
<jeremy> f13: I'm not sure there's a good way to do so... dave and I talked for a while about it one day last week
it's a maze of twisty scary crap :-/
<f13> I know.
<jeremy> (the kernel, not the versioning guidelines which are pretty clear for the majority of cases)
<bpepple> jeremy: how should we proceed on this item?  work with dave some more?
<f13> but if uname says 2.6.20, kernel package should probably to.
but I'm OK with "can't do that, for scary reasons foo, bar, baz"
<jeremy> bpepple: I think working towards the compromise is probably a good first  step.  and also, I just saw mail from davej saying his first experiment at using git for managing the kernel ended up failing disasterously ;-)
* f13 saw the same mail
<nirik> bummer. ;(
<notting> jeremy: where?
<bpepple> ok, anything else on this?
<jeremy> not from me
<bpepple> cool.  moving on....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- disallow cvs-import for everything but the initial import?
<bpepple> warren: ?
<nirik> I think cvs-import.sh should just print a big scary warning if used for other than inital import, and should also prompt the user for a cvs log...
<dgilmore> bpepple: i dont think it will happen
<rdieter> heard some mumblings at FUDCon about that: nirik++
<bpepple> dgilmore: right, I think warren was going to work on nirik suggestion.
<dgilmore> bpepple: however i think cvs-import.sh  needs modification to show diffs
<c4chris> nirik, +1
<cweyl|work> I think it's a good idea.  I mean, it's not like the cvs makefile framework doesn't provide the tools to do local builds right from inside the sandbox
<abadger1999> dgilmore: +1
<nirik> diffs would be fine too...
<dgilmore> and get a propper log
<notting> i would rather just disallow it, personally
<bpepple> notting: I'm in the same boat.  But if it shows a diff and pops up a message, I can live with it.
<cweyl|work> it seems like allowing it for subsequent imports just causes/raises too many potential problems than it's worth
<nirik> how can we though?
<dgilmore> notting: as would I
<rdieter> I'm ok either way, but I can understand how some folks depend on that for their current workflow.
<dgilmore> cweyl|work: i aggree.  however alot of contributors seem to use it
<nirik> we could push a new version that disallows it, but people might well get mad and just keep the current version around...
<cweyl|work> nirik: as part of the "add to CVSROOT/modules" check, just make it die horribly if the module already exists?
well, there is that.
<bpepple> nirik: I think you can safely assume some people will be vocal about the change. ;)
<c4chris> some are vocal no matter what...
<bpepple> I believe warren was working on this, and I'll follow-up with him after the meeting.
<nirik> perhaps we could poll the people using it and see why they do, or if they would be ok with diffs/warnings?
<abadger1999> Yah.  I don't think getting rid of it will actually stop anyone.  Enhancing it to make it safer seems like it'll have the most effect on people's behaviour.
<nirik> I think we can tell who does via the cvs commit mails...
<cweyl|work> nirik++
<bpepple> abadger1999: agreed.
<cweyl|work> having more information before making process changes is always good.
<bpepple> anything else on this before moving on?
<nirik> I'd be happy to try and get more info from cvsimport users if that would help...
<dgilmore> bpepple: move on
--- bpepple has changed the topic to: FESCo-Meeting -- MISC -- Incompatible package upgrade policy - http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00069.html
<bpepple> scop wanted this brought up today.
<notting> is it too much to say "for anything released: DON'T."  ?
<tibbs> Yes, there are often reasons why we want to do this.
<c4chris> at least COMMUNICATE
<abadger1999> notting: Unfortunately, yes.
<bpepple> I believe this sorta falls under the Maintainer Responsibilty policy. http://fedoraproject.org/wiki/Extras/Schedule/MaintainerResponsibilityPolicy
<dgilmore> bpepple: the new updates system will not let repo breakage occur
<tibbs> Well, there's also the question of -compat packages.
<nirik> Should mail maintainers, should mail signers not to push while updates are building, should only push to devel and wait and see what else breaks first
<bpepple> dgilmore: good.
<jeremy> abadger1999: exceptions can always be granted when they're needed (*cough*firefox*cough*)
<dgilmore> so in this instance  the package would not have gotten pushed
<jeremy> abadger1999: but it really feels like the policy should be "DON'T"
<notting> fer example, someone tried to push a curl update to fc6 that changed abi :/
<tibbs> I prefer "please really try hard not to",
<nirik> how far away is the new update system?
<tibbs> but then we've had instances where the maintainers cooperate and everything works great.
<dgilmore> nirik: its getting there   we want it in place for F7
the new updates system will require changes in teh way everyone works
once you have built there is some extra steps
<nirik> I've had no problems with Xfce updates... cwickert and I cooperate closely on making sure we push all the plugins and the core packages at the same time.
<cweyl|work> yeah.  this seems to be mainly a matter of common sense.
<dgilmore> nirik: :)  you guys a in the minority
<nirik> I think people might not realize all the other things that depend on their package...
<cweyl|work> if you know you're going to break something, at get in touch with the other maintainers (e.g. bugzilla tix, whatever)
<rdieter> bpepple: +1, MaintainerResposibility covers this.
<bpepple> Ok, so people for now should communicate changes, and in the future this should go away with the updates system.
<notting> bpepple: well, they should communicate even with the update system, but yes.
<cweyl|work> bpepple: sounds good
<bpepple> ok.
moving on....
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<spot> ok
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo
(so you can follow along)
<tibbs> Are we going over the things we went over at the fudcon meeting?
<spot> non-pear PHP extensions need to use /usr/share/php for their Class files
tibbs: yes
<tibbs> cooll
<spot> http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles was passed
We clarified the %makeinstall section, adding more specifics on why it should not be used (unless absolutely necessary)
The formerly suggested buildroot is now the mandatory buildroot.
(ideally, this will go away with rpm setting a sane default buildroot for us, but in the interim...)
<XulChris> cant sanity checking of debuginfo files be done in rpmlint?
<notting> XulChris: rpmlint uses binutils tools, which (IIRC) doesn't seem to like them. probably needs to use elfutils
<nirik> rpmlint does work on debuginfo files... at least I usually use it on them...
<spot> All binaries in Fedora packages need to be built from source: http://fedoraproject.org/wiki/PackagingDrafts/SourceRequirement
<notting> spot: firmware != binaries?
<spot> notting: indeed.
There are some exceptions to that rule, the document covers it pretty well.
<XulChris> nirik: i dont think it currently detects missing source files
<dgilmore> spot: does that allow for bootstrapping?
<XulChris> i could be wrong though
<spot> dgilmore: yes
And, last but not least:
<warren> bpepple, talking about cvs-import.sh?
<spot> We clarified some of the text around BuildRequires helper tools (now mentions mock and mach)
<bpepple> warren: yeah, we did a little earlier.
<warren> bpepple, I wasn't working on that aspect.  Didn't we agree on modifying it to 1) warn 2) look at a diff 3) make them type in a cvs comment?
<spot> Are there any objections with these items? :)
<dgilmore> spot: none from me
<nirik> spot: all sound good to me. +1 here.
<notting> spot: i agree with some of matthias's concerns about desktop files
<bpepple> spot: sounds good to me. +1
<dgilmore> warren: yes  but lets talk about it later
<c4chris> spot, all fine with me
<abadger1999> notting: What in particular?
<spot> notting: we can always revise the guideline
<nirik> FYI, how to bring up a item to the packageing comittee? mailing list?
<notting> abadger1999: when to have vs. not have .desktop file
<spot> nirik: that is the best way, its even better if you write a draft and put it in PackagingDrafts/
<abadger1999> nirik: If possible make a draft under PackagingDrafts/ on the wiki.  then announce onthe list (and make sure one of the PC people puts it on GuidelinesTodo)
<f13> I'd rather table the .desktop proposal and rework it before making it official
<nirik> ok. Have a question about log files brought up by the acpid review. will try and write something up
<abadger1999> notting: k.  I'm in agreement with spot for now.  though... I may not think xeyes belongs on the menu but someone else might.
<rdieter> one is always able to create a .desktop file with Hidden=true.
<abadger1999> Not having the .desktop file means lack of options.
<notting> rdieter: and the point of that is...? :)
<jeremy> abadger1999: having a desktop file, though, means that the menus are cluttered and it's that much harder to find the things that people _do_ care about
<rdieter> folks can use menu editors to (re)enable it, if they wish.
<nirik> if it's hidden can't you still use menu editors on it?
<rdieter> nirik:+1.
<XulChris> we need a microsoft feature to highlight most frequently used menu items :)
<rdieter> XulChris: kde has that... (:
<abadger1999> jeremy: Yes -- but menus *are* cluttered.  We've kind of reached the UI limitations of menus at this point.
<notting> ok, we're off in the weeds.
<jeremy> notting: indeed
<bpepple> notting: agreed.
So, the only item people had a problem with is the desktop file?
* rdieter is failing to see what the problem is exactly.
<XulChris> has anyone here seen the games menu after installing all possible games?
<wwoods> XulChris: not *all* of it
<abadger1999> I'd like to note that the suggestion to not have a desktop file for all GUI apps is a change from the current guidelines.  So failing to pass this will still leave the menu clutter.
<spot> XulChris: yes, but is that the fault of desktop files or inflexible menus?
<XulChris> spot: my opinion is that we need more submenus (subdivisions)
<jeremy> okay, we're way off in the weeds now :)
<f13> foo->more->morer->most
* dgilmore needs to go
<dgilmore> seeya soon
<bpepple> Ok, I'm not sure where we are at regarding the desktop file.  Could I get a quick vote  from FESCo folks on this?
<abadger1999> We need a proposal on how to limit .desktop files (Matthias's proposal, for instance, could be written up) and the PC needs to discuss that regardless of whether we pass or fail this.
<spot> I vote for it, noting that it is ALWAYS open for refinement
<bpepple> +1
<rdieter> +1
<abadger1999> +1
<tibbs> +1
<nirik> +1
<c4chris> +1
<bpepple> notting, jeremy?
<notting> *shrug* it's not perfect, but it's something. +1
<rdieter> probably sitll finding their way back from the weeds.
<jeremy> rdieter: indeed (and going to reread the proposal :-)
<bpepple> Ok, I don't see any -1, so I believe this is ratified.
<jeremy> I don't think we're any worse off with it... so +1
<bpepple> spot: anything else from Packaging?
<spot> nope, thats it for this week
<abadger1999> I have one thing
<spot> err, ok. :)
<abadger1999> I'm trying to smooth the Packaging Committee packager interaction for the Core Merge.
So if anyone notices that a packager/reviewer seem to be at an impasse over guidelines feel free to ping me about it.
<bpepple> abadger1999: ok.
<rdieter> those darn "Packaging Committee folks on high" kind of comments? (:
<c4chris> soothe? :-)
<abadger1999> I'll try to explain the current guidelines and make a proposal for change.
<spot> rdieter: hey, get off my throne. ;)
<abadger1999> thx.
<bpepple> abadger1999: anything else?
* rdieter kindly steps aside.
<c4chris> pesky kinda guys :)
<nirik> abadger1999: might make that offer on the maintainers list too?
<abadger1999> bpepple: That's it.
<f13> I wasn't too fond of being referred to as the Peoples Republic of Packaging Committee.
<bpepple> abadger1999: great, thanks.
<abadger1999> nirik: I'll do that.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras
<rdieter> f13: hee, that's good.
<bpepple> Anything else people want to discuss?
<notting> i have a couple of items
<f13> notting has the talking beer.
<bpepple> notting: shoot.
<notting> 1) new package imports - by default - acl or no acl?
<nirik> I would prefer no acl.
* bpepple leans towards acl.
<c4chris> no acl -> least changes from previous status
* rdieter doesn't care, as long as it is documented, and folks can change it if they wish.
<nirik> except for the merge packages, they should be owner + sponsor.
<warren> I prefer no ACL.
<XulChris> I am confused why old starndard is different than new
<spot> no acl, with the documentation on how to enable acl very clear
<warren> See my post to fedora-maintainers list to describe how it works now.
<XulChris> i mean with regards to default acls on checkin
<f13> I don't really care.  Either we get yelled at by Extras folks, or we get yelled at by Tin Foil Red Hat folks.
either way, somebody is going to be upset.
<warren> Subject: "ACL's, Why a Big Deal?"
No ACL by default, except when the core packages are put in.
<jeremy> I was initially no acl, but I've been converted to lean towards acl by default
<warren> many core packages will be opened because the owner doesn't care that much
<nirik> I think ex-core packages can default to owner + sponsor, and that might quiet some of the tin foil hat problem... we can then talk some of them into opening things up.
<f13> the more things we have with no ACL, the higher the risk threat.
<warren> jeremy, reasoning?  (curious)
<jeremy> warren: see what f13 just said
<warren> f13, now that owners are mailed when things change, isn't that easier to track?
<bpepple> f13: agreed.  that's why I'd lean toward having acl by default.
<f13> warren: we haven't fixed the commit mail bug
<warren> I'm *OK* with acl by default, as long as people have the option to remove it.
<XulChris> so all existing packages should get acls too then, correct?
<f13> warren: and if somebody changes something at 3am and pushes it out, I may not notice until 9am
<nirik> f13: I posted a suggestion on that... no one has commented tho.
<warren> f13, commit mail isn't instant?
<f13> nirik: I don't know CVS well enough to know if that will work.
warren: commit mail is instant, _I_ am not.
<notting> <just add water>
<jwb> enable only the maintainers to push out their packages
<f13> and thats reactionary, rather than proactive.
jwb: I don't know if we can get infrastructure up for that in time.
<warren> build could be a different permission than checkin
<jwb> f13, that would suck anyway
<warren> Anyhow, I think on by default is fine.  Just don't disallow turning it off.
I would slightly prefer off by default.
<abadger1999> Is maintainer push part of the new updates system or is it collection-owner push?
<f13> abadger1999: updates system is usually pushed by a releng person
<bpepple> Do we need a show of hands for having acl's on by default?
<f13> abadger1999: who has rights to sign the packages
+1 for ACLs by default
<warren> there's 3 steps to update pushing
<bpepple> +1 here also.
<warren> 1) checkin and build
<notting> +1 from me.
<warren> 2) owners fills out the update form in the updates system, writes release notes, etc.
<abadger1999> f13: I was trying to recall if lmacken built some workflow into the tool.  Maintainer adds to the queue with release notes (CVE fixes, etc).  releng does the sign and push.
<warren> 3) release engineer signs & pushes
<nirik> -1 from me, but I will bow to the majority...
<abadger1999> -1 from me as well.
<jwb> abstain
<jeremy> +1 for acls by default
<c4chris> abstain
<warren> I'm for choosing SOMETHING now, but I am against sticking with it as a matter of policy forever.
<jwb> i agree with the technical reasons for ACLs
that's all
<nirik> any evil packager can push an evil package... of course the more popular the package is the more people it will effect.
<tibbs> I'm at -0.5 at the moment.
<f13> abadger1999: thats how it works.  maintainer requests the update, the releng person just pushes the buttons and twists the knobs.
<rdieter> +1 for acls
<tibbs> We really have to get the default access levels worked out before we lock down too many things.
* XulChris comments we should be consistent between old and new packages no matter what is decided
<notting> note: this does not involve changing current packages. just the default on new imports
<bpepple> It looks like it's 5-for, 2 against, and 2 abstain right now.
<warren> +1 for default acls, only if we revisit this issue later.  I suspect we will find that it works in ways we don't expect and we will want to adjust it.
<tibbs> Am I correct in thinking that the security team is locked out by default now?
<abadger1999> f13: Right.  So the maintainer has to be involved before the push is made.  If I build a malicious gcc package because the ACLs are open, jakub still has a chance to stop it.
<bpepple> warren: agreed.
<warren> tibbs, that is easy to fix.
<nirik> also sponsors are locked out I think.
<jeremy> tibbs: we can fix that pretty quickly
<warren> nirik, we can automate that too, but as I mentioned on fedora-maintainers we need to be careful about policy.
May I call for a more specific vote?
<bpepple> +1 for acl.
<f13> abadger1999: I don't think anything stops you from requesting an update for gcc
<c4chris> warren, ?
<f13> abadger1999: I don't believe it has ACLs that say the maintainer of hte package is the only person that can request the update.
<nirik> so the acl's are needed for the core import? how about default to off for now, and then revist before importing core packages?
<warren> Vote: Default ACL's with sponsor by default in pkg.acl and other possible considerations, with the intention to revisit this issue later as we have a clearer picture of what it becomes.
<bpepple> +1
<warren> nirik, well, I prefer that
<tibbs> warren: "sponsor" meaning direct sponsor or all sponsors?
<notting> warren: does that mean arguments when the owner removes the sponsor?
* XulChris notes that his sponser is no longer with us
<warren> nirik, a paranoid concern is... import without ACL by default, somebody changes something in the hour before the ACL syncs and becomes in effect.
<tibbs> XulChris: We could reparent you in the sponsorship tree.
<warren> notting, perhaps, but I think we can easily make FAS allow unsponsoring. =)
<rdieter> warren: a valid concern, makes me lean even more for acls by default.
<tibbs> Basically, I'll vote for ACLs on by default as long as we're allowing trusted members of the community in by default.
<jeremy> tibbs: we'd have to have him go through a package submission and review first ;-)
<abadger1999> Guys, I have to head out.
<warren> rdieter, I think it is an overly paranoid concern.
<nirik> I am thinking more and more that acls for cvs is bad, but we should have acls on updates/builds...
<warren> abadger1999, thanks
<f13> warren: introducing sponsor by default has some technical troubles, like the account doesn't exist, and requires more work of the import software.
<bpepple> abadger1999: later.
<notting> darn, and i still had one more agenda item :/
<abadger1999> I'll tie my ACL vote to tibbs  if it makes a difference :-)
<bpepple> abadger1999: ok,
<c4chris> I think I'm with tibbs too
<f13> tibbs: cvs-admins have full rights.  We can add more people to cvs-admins as desired
<warren> nirik, we need to think about policy implications.  Certainly more fine grained ACL's are possible for such things, but does it gain us anything?  (I suspect yes, but we don't know yet because it isn't formed yet.)
f13, indeed we need some from Europe
<tibbs> f13: Unfortunately that's not really enough of the trusted people I'm thinking about.
<f13> tibbs: you're thinking about the security folks.
<bpepple> so where are we regarding acl?
<f13> and I definitely want them to be in a group that has access to everything.
<tibbs> Security folks and sponsors.
<nirik> I'm ok with doing something now, and revisiting... I want to ponder more on it... and I suspect community will have more import.
<f13> tibbs: I'm with you on security, not sure about sponsors.
<warren> I believe as these things shape up, it will become apparent that a certain group of people can be trusted not to fuck things up.  But I can't convince people of this just yet, because they are too afraid of other changes.
<tibbs> I want people to be able to do what nirik did with going in and fixing broken deps.
<warren> Thus I suggested revisiting the policies regularly.
<f13> tibbs: but thats just gut feeling.  Might make becoming a sponsor far far harder.
<warren> f13, it would be a level higher than just sponsor
<tibbs> Either that or inventing another level.
<warren> Ultima!
Note that we're talking about ranks.
I'm totally for ranks.
<f13> another subject for another day.
<tibbs> If cvs-admins is that other level, then fine, but it seems to have another connotation.
<warren> yes, subject for another day.
<c4chris> f13, yes
<rdieter> notting: next topic? (:
<bpepple> rdieter: +1
<notting> ok, at the board meeting, we discussed firmware.
<warren> Let's just build shit for now, and deal with those details later.
<rdieter> amen brother.
<notting> some of you noted the one-word change to the packaging guidelines ;)
<tibbs> Indeed.
<warren> where?
<notting> warren: s/distributable/redistributable/
* dgilmore is back
rdieter is shocked, shocked and appalled, those Board members on high.
<tibbs> http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff
<notting> our plan, from the board level, was to act in the following ways:
<tibbs> Or for posterity, http://fedoraproject.org/wiki/Packaging/Guidelines?action=diff&rev2=82&rev1=81
<notting> 1) make up a license tag for non-modifiable firmware for easy finding for users
2) modify the EULA to add an exception clause for firmware (similar to the one currently for trademarked logos)
3) release note the eula change
4) and start poking vendors
<nirik> 5) profit!
<notting> any objections to doing this, and therefore start shipping things like ipw2200-firmware in the main distribution?
* bpepple doesn't really have a problem with it.
<nirik> +a lot from me as long as the lawyers are happy.
<tibbs> Please do this.
<f13> notting: I have none.
* XulChris thinks underpants should be in there somewhere
<warren> Note the implications
FSF will declare us to be evil and non-free, by their definition of Free.  Even though we are more Free than Debian or Ubuntu or OpenSuSe.
Note, I DON'T CARE.
<c4chris> notting, you mean, now we can't ship ipw2200-firmware, but with the change we can ?
<warren> FSF is pretty extreme in this regard.  They don't like Creative Commons only because an optional CC license is non-free.
<jwb> wiat
<nirik> that would be too bad... especially after all the trouble to clean out licenses
<warren> well, I had to mention it, because we have to understand the implications.
<jeremy> c4chris: correct
<warren> some people will be upset about this
but really, this is INSANE
<jeremy> nirik: cleaning up the licenses is *still* a good thing
<warren> the FSF is simply not reasonable.
<nirik> jeremy: agreed.
<notting> c4chris: pretty much, yes.
<c4chris> k, fine with me
<jwb> this is fine with me
<tibbs> Actually, a spin without the firmware should be just fine.
<notting> the underlying question is: are we OK with shipping non-modifiable firmware in the base distribution
<warren> Fedora can be the most Free and license compliant distro out there (other than gnusense), but with redistributable firmware, our users have nuisance free out-of-the-box functionality.
This does NOT violate the GPL or copyright.
<f13> what happens when we want to do new wireless tools but th efirmware won't suppor it?
support it?
<jwb> notting, firmware, yes.  binary modules no
:)
<f13> do we stall and wait for the firmware?
<notting> f13: no.
<warren> redistributable firmware does not violate the GPL or copyright laws like nvidia or ATI drivers do.
<dgilmore> warren: we are already eveil in there eyes
<warren> Then so be it.
* notting notes 'GPL or copyright laws' is redundant :)
<bpepple> Are there any -1's on this?
<jwb> notting, we should define what firmware means.  e.g. a binary blob that is loaded on the device itself, not something running on the CPU under the kenrel
<jeremy> f13: the firmware is tied to the driver...  I'm not quite sure what you're getting at
<notting> jwb: see guidelines
<warren> Apparently, I hear from a 3rd party that RMS doesn't like us merely because of our size too, no matter what we do.
<jeremy> jwb: yes.  that's very explicit in the current firmware guidelines
<jwb> ok cool
(sorry, only sorta here)
<f13> jeremy: I don't know.
<nirik> http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware
<warren> In any case, this is not in conflict with the GPL or copyright law, and it benefits our users.  We simply don't agree with one extreme and unreasonable aspect of the FSF.
This is little different from hardware itself having onboard firmware.
<rdieter> gotta run, I'm +1 (for what it's worth).
<notting> warren: technically, it's in violation of our own EULA. see points #2 and #3 above.
so, we probably can't push this back to FC6 or earlier
<warren> notting, so we modify our EULA?
notting, that's fine.
<notting> right, the eula gets modified. which puts a FE-LEGAL blocker on the final release, but oh-well
<warren> net win for us
so... are we done?
--- rdieter is now known as rdieter_away
<notting> ok. just wanted to run it by fesco before we told the packagers to go ahead
<f13> oh boy, eula changes (:
<nirik> also for the ipw ones doesn't intel have to do a release with a good license?
* f13 mumbles something about eula getting hammered during package review
<notting> nirik: no. the license was cleared.
<bpepple> notting: ok, sounds fine, and I don't see anyone objecting.
notting: anything else?
<nirik> notting: I thought they changed the web page, but haven't released a version with the new license on it yet?
<notting> we're at 2:20 already. no. :)
<dgilmore> bpepple: lets finish up
<bpepple> Ok, if there's nothing else I'll wrap this up.
* bpepple will end the meeting in 60
<notting> nirik: the gist of it was that the prior license was ok in its horribly worded form; the web page was just a restating
* bpepple will end the meeting in 30
<nirik> ok.
* bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End
<jeremy> bpepple: one quick announcement (not a question)
<nirik> thanks bpepple.
<bpepple> jeremy: shoot.
<jeremy> the bugzilla update script from owners.list should be running every 4 hours now.  for real this time :)
<dgilmore> jeremy: thanks
<bpepple> jeremy: cool.  I'll add that to my meeting summary.