Extras/SteeringCommittee/Meeting-20070125

2007 January 25 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

EPEL Update

• Still waiting on RedHat IT. Most of the necessary people will be at FUDCon, and the plan is to have session regarding EPEL at the HackFest.

Opening Core

• Warren discussed the basic plan on how the review of the Core packages will proceed. He is going to work out the final details before FUDCon.

Encourage co-maintainership

• thl sent an e-mail to the mailing lists with his proposal for co-maintainership which generated quite a bit of discussion. He will incorporate suggestions from the mailing lists and the meeting into his proposal, and bring it back to FESCo.

Syslog-ng Patent Problems

• bpepple is going to check with Greg DeKoenigsberg and spot to verify that this is in legal's queue.

Preparation for F7

• nirik is going to poke some folks regarding broken deps.
• The current plan is not to do a mass-rebuild of packages since there aren't any toolchain reasons for it.

Proposed ACL system

• notting gave a brief description on how the ACL system will work:
• there will be a file 'pkg.acl' that can be added either to the package toplevel or per-branch. It lists account names (one per line) that get access:
• no pkg.acl == wide open
• empty pkg.acl == 'owner' only
• 'owner' == owners.list + owners.epel.list owner
• only the owner or the CVS admin can add/modify the acl
• owners.list is going to be locked down.
• per-branch ACLs inherit from the toplevel ACL for the package
• e-mail notification: the package owner + anyone in the acl for the package will get e-mail notifications of all changes to said branch
• For more details, please refer to the IRC log.

Misc

• There will be no FESCo meeting on 2007-02-01, since most of FESCo will be traveling to FUDCon that day. FESCo will have a meetup during FUDCon.
• People attending the HackFest at FUDCon, please look at http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest

Log

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* warren here.
* jeremy is here-ish
c4chris here, but only for about 10 minutes...
<c4chris> shouldn't we be on #fedora-meeting ?
<bpepple> FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, thl, tibbs, warren
* nirik is here mostly.
c4chris c4chris|w
thl is around
abadger1999 is here
<bpepple> c4chris: I couldn't get Chanel OPs in time for the meeting.
<tibbs> I'm here.
<c4chris> bpepple, ah, ok
<tibbs> Cool, one less tab.
* spot is here
<thl> tibbs, I actually would like to get rid of tabs by using the meeting room for more meetings
tibbs, then I could get rid of fedora-qa and fedora-board
but well, usage cases depend :)
<bpepple> Alright, it looks like most folks are here.
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update
<f13> oh man, another meeting.
* bpepple doesn't see mmcgrath or dgilmore, so maybe we should come back to this.
<c4chris> yup
--- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon!
* dgilmore is breifly here
<mmcgrath> pong
<bpepple> whoop spoke to soon.
<mmcgrath> only gave us 47 seconds :-P
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update
<bpepple> Any word from RH IT?
<mmcgrath> So basically we've added a discussion to FUDCon.
no word from RH IT.
<dgilmore> bpepple: not yet :(
<mmcgrath> Though I start working there the monday after FudCon so I'll probably be following up directly at that point.
<dgilmore> we are going to do a QA session at FUDCon
as well we plan to work out the finer details there
<c4chris> QA being Questions/Answers ?
<dgilmore> c4chris: yes
<thl> is there interest for a small EPEL meeting at the hackfest, too? to discuss the near and long term future?
--> notting (i=notting@redhat/notting) has joined #fedora-extras
<bpepple> Is there someone we can poke at RH to speed this up, or will the discussion at FUDCon address the outstanding issues?
<mmcgrath> We could do that, i think all the key players will be there.
<bpepple> ok.
<mmcgrath> notting is our best contact for that.
--> rdieter (n=rdieter@sting.unl.edu) has joined #fedora-extras
<thl> mmcgrath, how much time would we need? when do you and quaid have time for it?
<dgilmore> i thinkthe people we need to deal with will be at fudcon
* thl wonders is quaid actually is around for the hackfest
<mmcgrath> I can easily make time for it because it involves the future of the infrastructure team (its where our packages will come from)
* rdieter runs in late.
<thl> mmcgrath, it's listed already on http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest
but has to time slot yet
but we can decide that dynamically at the hackfest, too
<mmcgrath> <nod>
<bpepple> dgilmore, mmcgrath: anything else regarding EPEL?
<mmcgrath> bpeppel: not much other than my neglect of the wiki site.
* mmcgrath will do it, promise.
<bpepple> Moving on then..
--- bpepple has changed the topic to: FESCO-Meeting -- Opening Core -- jeremy/warren -- plans for the mass review seem to be really needed soon!
<warren> http://www.tiki-lounge.com/~toshio/fedora/buglist.html
We're trying to nail down the final details
but the basics are
1) File a bug for every package
2) separate those bugs onto several different package category trackers, so it doesn't go too damned slow
3) Have cached's views of those trackers like Toshio's http://www.tiki-lounge.com/~toshio/fedora/buglist.html
<thl> who files all those bugs?
could we automate that?
<warren> 4) This will be separate from existing trackers like FE-NEW because they are of higher priority to happen, while FE-NEW contains things of questionable quality.
Automate, yes we could.
The only hard part is... how do we choose which goes onto what tracker?
<thl> s/could/should/ IMHO
randomly?
<nirik> what categories will there be?
<warren> Desktop tracker?  Java tracker?  everything else?
As long as we split it roughly evenly between 3 or 4 trackers this shouldn't be unreasonably sow.
slow.
<thl> or assign them all agains one tracker, and then allot them
<nirik> could they be split by comp groups? base/core/desktop/ et?
<c4chris> Sorry, guys: gotta run.  I can help with automated BZ filing if needed. I'll read the log later and see what was decided. Feel free to email me directly if I can be of help...
c4chris c4chris|w
later
<warren> I'm afraid that 1,000 bugs on one tracker will be far too slow.
<bpepple> c4chris: no problem.
<thl> warren, have then on one tracker and allot them is still easier then file all of them manually afaics
<warren> thl, what does this mean?
<nirik> could we use a new bugzilla instance for this? then fold the data back into the main one as each package gets accepted?
<warren> FDESKTOP-NEW -> FDESKTOP-ACCEPTED (no need for REVIEWED?  ASSIGNED can mean "taken"
nirik, no.
nirik, merging bugzilla databases is non-trivial and error prone.
<thl> warren, I just don#t want to file all of them manually :)
* rdieter suspects someone with enough bugzilla-fu could make it work (best). (:
<nirik> ok, just a thought.
<warren> the purpose of having one ticket per review is to have a paper trail for history
<thl> +1
<warren> thl, yeah, filing will be automated.
* quaid saw his name mentioned here but cannot look back up the buffer atm to see why
<warren> we just have to create the categories.
<quaid> I'm here for another m inute if there is something I can do right now?
* thl querys quaid
<warren> quaid, that topic passed a while ago
<quaid> ok,
<bpepple> warren: what is the plan for sponsoring current RH maintainers?
<nirik> warren: BASE? DESKTOP? KDE? JAVA? DEVTOOLS... or just leave it up to the person making the script to automate adding the bugs?
<thl> +1 for " leave it up to the person making the script"
* bpepple is fine with that also.
<warren> Doesn't matter how it is split, as long as it is automatic filed, and soon. =)
<abadger1999> warren: +1
<thl> soon +1
<warren> bpepple, I'm going to have to beat each RH developer individually.
<nirik> +1 for whatever. I don't think the blockers matter much.
<bpepple> warren: ok.
<warren> clue-by-four beating.
wait a sec
Shouldn't we figure out the category lists ourselves?
<thl> are the category lists that important?
<warren> well.. no
Another possibility, is to have the "core" stuff in one category, with less central dependencies in others.
eh... we'll figure something out, I'll talk with c4chris when he gets back.
move on
<bpepple> warren: ok.  On to the next topic.
topic FESCO-Meeting -- Encourage co-maintainership -- all
--- bpepple has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- all
<warren> Core merge does enable co-maintainership =)
<bpepple> warren: cool. :)
<warren> This really isn't a good topic anymore, just many pieces need to be done to make it easy .
<warren> next
<bpepple> thl?
<thl> well
I don#t think it's that easy
<dgilmore> sorry guys i gotta run
<bpepple> Or do we want more discussion on the list about it?
<thl> co-maintainership is much more than just to have two or more maintainers
I#d like to know what the FESCo people think about the whole idea
<bpepple> dgilmore: later.
<thl> last week I got a go with that stuff I wrote
and now it's completely disliked?
* bpepple wonders about that also.
<rdieter> not disliked, some folks took offense to the tone, thought it was to dictatory.
<thl> I admit that my wording might be a bit to direcdt here and there
<rdieter> I don't think anyone disagreed with the (core) mesage.
<thl> but that why I'm asked here before I send it out
I'm no native english speaker, so sometimes the tone might accdentatlly be more harsh then I#d want it to be
<rdieter> imo, it's (mostly) fine.  You can't please 100% folks 100% of the time.
<thl> if the direction is to improve the current proposal I can work further on it
<bpepple> rdieter: agreed.
<thl> but then I need a bit more backing in case some people dislike parts
<rdieter> I did appreciate the comment that policy should be separated from suggestions/best-practices.
<thl> I felt left there quite alone yesterday
no fsco members particiapted
or better: backed the idea
rdieter, well, we have that mix in other policies, to
too
<tibbs> Sorry, I participated in one thread, but then I suppose that was on a different mailing list.
<thl> tibbs, was, no problem
<nirik> I did throw in a comment I thought, but yesterday was really busy. ;(
<thl> what skvidal suggested is okay, but it leaves many thing that are IMHO important out
and we left them out far to long already IMHO
<bpepple> thl: Agreed.
* jwb is here now
<thl> we need ways for new contribnutors to get involved more
<rdieter> We could start simple, with something close to what skvidal/f13 suggested, and add to it as needed.
<thl> rdieter, what skvidal suggested is there already
<rdieter> That seemed to please most folks in the thread.
* notting strongly prefers skvidal's suggestion. leave long policies to when we run into more issues with people trying to adhere to that one
<thl> that what we said all the time alredy
<abadger1999> I think the main ingredient to add to what skvidal said is "Encourage comaintainers"
<f13> thl: I participated, I'm in FESCO...
<thl> abadger1999, that is old, too
<bpepple> abadger1999: How is that any different than what has already been done?
<abadger1999> thl: It's the actual topic for this discussion in fact.
<thl> f13, that's why I wrote "backed the idea" in the last line
<f13> ah
<jwb> from where i sit, i haven't seen a lot of cases where people are off wanting to package the same thing
<thl> s/last/line after that/
<jwb> i don't know if that's because they assume it's already taken so they won't bother, or what.  but adding some kind of blurb on the wiki about co-maintaining would be a good start
<f13> IMHO, the "policy" needs to be short and sweet, like skvidal's.  Complimenting the policy could be some text explaining WHY co-maintainership is encouraged and what problems it seeks to solve.
<thl> jwb, well, I for myself gave of a lot of packages in the past and that way got new people into the project
<jima> jwb: i've seen it happen a couple of times, but i don't think it's a major thing.
<thl> cwickert is such a example
* bpepple is doing that with the telepathy stack.
<jwb> thl, right but i'm saying how often is that the case?
<thl> we'd see how it goes
<abadger1999> jwb: Our packaging culture is kinda pointing in the wrong direction.
<thl> I did not force anybody to hand over packages
<jwb> abadger1999, meaning?
<thl> I just suggested that get co-maintainers first, and hand over packagers if they do a good job is another way we could use
<abadger1999> Packages are treated as being owned by the person who originally packaged them and co-maintainership is the specifal case.
<warren> I might be missing something important here, but why is the idea of co-maintainership so contentious?
<thl> abadger1999, +1
<jwb> abadger1999, treated by whom though?
<thl> I think it should be more clear that the projects sort of "owns" the packages
<bpepple> warren: no idea.  Some people seem awfully territorial about their packages.
<jwb> thl, +1
<warren> The new proposed ACL policy that f13 was talking about is simple:
<f13> thats because we have hte idea of ownership and responsiblity
<thl> and that certain project contributors that really now what they are doing should get access everywhere as  ralf suggested on the list
<warren> 1) By default, only owner may touch it.
<f13> _you_ brought this package to the collection _you_ are responsible for the bugs and keeping it working _you_ are on the line for issues.
<warren> 2) The owner may grant privs to others.
<thl> I wated to write a proposal where all maintainers are equal in the beginning
<abadger1999> jwb: Everything.  Comaintainership should permeate a pakcage's life cycle.
<thl> but that was disliked when I proposed that here
<jwb> i mean, i've never had a single person ask to co-maintain one of the packages i own.  i would love it if someone did, but i don't see a huge pent up demand for it...
<warren> 3) I suggested that a maintainer may grant not only individuals, but arbitrary groups.
* mmcgrath has had people ask to become co-maintainers
<jwb> i'm just wondering if we're trying to force something for which there is no demand
<abadger1999> jwb: You're doing too good a job.
<notting> owner is accountable, co-maintainers are responsible?
<thl> jwb, some people might step up if you would offer it
<rdieter> jwb: nobody is "forcing" anything.
<jwb> abadger1999, doubtful ;)
<notting> warren: individuals is easy. groups is hard.
<f13> warren: the idea isn't contentious.  Making policy that forces every package to have one or two co-maintainers is.
<rdieter> f13++
<abadger1999> I've only asked to comaintain packages where there's a problem (like the maintainer is short of time)
<jwb> thl, ok i'll be sure to do that
<bpepple> thl: agreed.  that's how I found co-maintainers for some of my packages.
<thl> well, let's stop here
I'll write something up
and send it to the list
<jima> there are a number of packages that i would offer co-maintainership for.
<abadger1999> f13: ++, the thing is that when I read the policy I read "should" everywhere... So partially it's interpretation of the guidelines.
<thl> maybe we should to the whole thing in smaller steps
<f13> abadger1999: the nature of how Fedora works there is package ownership, there is somebody that is responsible / accoutnable for what ahppens to a package.  Because of this, many don't want unknowns messing with what they are responsible for.
<rdieter> thl: good idea.
<jwb> thl, +!
er, 1
<thl> rdieter, more work for me :-/
<f13> abadger1999: there is a very clear difference between should and shal.
<bpepple> Ok, we should problaby move on.
<thl> bpepple, +1
<rdieter> thl: I know, that's life, just like in the packaging comittee... baby steps.
<f13> should == suggestion.  shal == forced policy
* XulChris is reminded of all the shalls in government software specification documents
<nirik> I think a better write up of why co-maintainers are needed would be good... as well as a 'how to find a co-maintainer'
<thl> nirik, I'll think about it
<abadger1999> f13: And I'm saying that I didn't see shall in a whole bunch of cases.
<thl> nirik, send me a note if I forget it
--- bpepple has changed the topic to: FESCo-Meeting -- MISC -- kernel-naming - What did davej find out about this?
<rdieter> nirik: I don't think anyone has ever suggested the idea co-mainters is bad... (:
<abadger1999> f13: I agree with your analysis of why people don't like to hand partial ownership to others.
(But not that it is the best thing for the project)
* thl likes to note that the topic came up on fedora-test-list last week once again, too
<jwb> jeremy, did davej ever get back to us?
<notting> he's still in .au, iirc
<thl> okay, we'll visit him there
<jeremy> jwb: he's not back yet
<jwb> notting, yeah..  jeremy said he had special ninja skillz to get ahold of him
<thl> rh pays the flight
* thl hides
<jwb> jeremy, failure to deploy the ninjas?
:)
--- bpepple has changed the topic to: FESCo-Meeting -- MISC -- No meeting on 2007-02-01, due to folks traveling to FUDCon?
<jeremy> jwb: nah, I thought that getting the answer could wait until he was back as long as he got the mission to ask :-)
<f13> well, davej is in an odd mix of sight seeing and sick as a dog
<jwb> jeremy, k
<f13> I don't think he's taking any time to respond to ninja smoke.
<thl> jeremy, maybe we should talk to him on the hackfest
* nirik will be on a plane then I think.
<tibbs> I will be on the way to the airport.
<thl> that's rpobably be easier for all people involved
* thl will be on over the ocean
<nirik> perhaps a special quick meeting at fudcon?
<thl> nirik, +1
<bpepple> nirik: That's what I was thinking also.
<f13> somebody get special fesco badges made up and pass around?
* f13 ducks
<rdieter> excellent idea, if nothing else, to get to meet everybody in person.
<notting> who fesco is *not* going to be there?
<abadger1999> nirik: +1
<bpepple> is awjb going to be there?
<thl> bpepple, nope
<jwb> not i
<thl> I havent seen hoim for ages
I think I should just ask him to leave FESCo
<Bob-Laptop> Fedora-QA is planing a meeting on Saturday FWIW
<thl> I think he's okay with that
<bpepple> thl: I was wondering about that also.  I don't remember the last time I saw him.
<thl> Bob-Laptop, our schedule is at http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest
<thl> bpepple, I'll try to contact him
<bpepple> thl: great, thanks.
<rdieter> why?  lost interest?  busy (with other stuff)?
<thl> he had some problems with this university
long story
<rdieter> give him our best..
<thl> If awjb and I would leave that would make fesco smaller (13 people again then)
<bpepple> When do people want to meet-up and FUDCon, or do we want play it by ear when we get there?
<f13> bpepple: play by ear.  It's an unconference
<rdieter> ear++
<f13> hell, we could meet up over at the Red Hat bar
<bpepple> sounds good to me.
<thl> wait
<rdieter> f13: even better!
<XulChris> redhat has a bar?
<f13> it's called the Red Hat Cafe, and it has nothing to do with Red Hat
<thl> that's a bit problematic, as dgilmore and abadger1999 might be involved with infrastrucute stuff
<XulChris> ok sign me up! ;)
<thl> a bit planing might help in this case
<notting> XulChris: http://www.bostonredhat.com/
<abadger1999> We should definitely set a time but it could be after we arrive.
<thl> abadger1999, in the kick of meeting Saturday morning maybe?
<tibbs> If wouldn't hurt for at least the folks staying in the hotel to get together and save on cab fare.
<abadger1999> tibbs: +1
<bpepple> tibbs: +1
<abadger1999> thl: +1
<f13> or bus fair
busses/T may be much cheaper
<tibbs> But AFAIK Rex and I are the only ones in the Fairmont.
* mmcgrath might have a car.
<f13> mmcgrath: I wouldn't recommend it.
<nirik> yeah, +1, but I am in a diffrent hotel. ;)
<f13> mmcgrath: driving in Boston and trying to park is a no win situation
<mmcgrath> I said no but I think it was assigned to me.  Will there be no place to park?
<bpepple> tibbs: I'm at the Fairmont.
<tibbs> Well, that's three at least.
<notting> theoretically, you can get from most hotels to other hotels via the T and reasonable walking
<f13> mmcgrath: Jack had some trouble with that last year
<abadger1999> tibbs: I think I'll be in the Fairmont too.
(Haven't made reservations yet.)
<Bob-Laptop> tibbs: thl is at the fairmont
<mmcgrath> k.
<f13> notting: indeed
<tibbs> Unfortunately the hotel tells me it's 12 blocks from the Fairmont to the university.
* nirik is at the Doubletree
* abadger1999 packs his hiking poles and a snack
<bpepple> anything else regarding FUDCon before moving on?
* Bob-Laptop pokes thl ... BTW you are at the fairmont
<wwoods> oh snap, I should make hotel reservations
<thl> thx Bob-Laptop , seen it (and thx again for helping with getting the room)
<thl> bpepple, please mention http://www.fedoraproject.org/wiki/ThorstenLeemhuis/HackFest in the summary
<bpepple> thl: no problem.
<thl> people attending the hackfest should look at that page
<thl> bpepple, thx
--- bpepple has changed the topic to: FESCo-Meeting -- MISC -- the "syslog-ng patent problems" - Has RH legal looked at this yet?
* nirik doesn't know how we can tell? someone in communication with legal?
<notting> 'no'
(short answer - it hasn't come up yet)
<bpepple> notting: It's in legal's queue though isn't it?
<notting> i don't know. might ask spot or gregdek?
it didn't come up in the board/legal discussion (probably b/c it didn't get on the agenda)
<bpepple> notting: I'll contact them and see if they know the status.
Onto the next topic.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation -- roadmap, broken deps, key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail to all package owners?
<bpepple> mschwendt wanted this added to the schedule.
<notting> bpepple: is there a slightly more  wordy description available?
<thl> notting, +1
<bpepple> oh, I'm sure. ;)
<nirik> there are fewer broken deps, but still some... I can try and poke some more people this weekend.
<thl> that would be a big help
why do wee need a FE7Target bug? we only need F7target afaics
<f13> since Test1 is coming up, it would be good to have a consistant tree
<nirik> what is the criteria for being added to a F7target?
<tibbs> Can we cajole the wxgtk maintainer into putting out a -compat package?
<nirik> yeah, wxGTK2 seems to still have lots of issues.
<spot> another one? :/
<notting> nirik: historically, there isn't one. although bugs may get removed if they're frivolous, impossible, etc.
<f13> nirik: A) not critical enough to block the release B) something we think we have a good chance at fixing for the release.
<nirik> ok, fair enough.
<bpepple> Are we planning on doing mass rebuilds again this release?
<nirik> They are a pain, but I would say yes... before t3?
<f13> bpepple: I haven't heard anything yet from the tools folks
* thl votes for no (I currently don#t see any good reasons for it)
<notting> bpepple: i don't think we have any toolchain related reasons to do so
<f13> without any technical reason, I'd rather not.
<rdieter> f13: +1
<jwb> but they're so fun...
<wwoods> there's bunches of things in core that would have linked against extras packages
<bpepple> f13: agreed.
<thl> f13, +1
<nirik> well, it does find awol maintaiers/orphaned packages... but yeah
<f13> unless you feel that getting them all buitl with the new buildsystem software is a technical reason.
<rdieter> wwoods: of course, but that's a separate issue.
<bpepple> so the plan is not to do rebuilds, unless the toolchain requires it.
<f13> nirik: thats a screw in search of a hammer.
<wwoods> rdieter: okay then
<tibbs> There was discussion of trying to get core rebuilt so that we could have the logs handy when reviewing.
<nirik> f13: yeah, probibly so. ;)
<thl> nirik, well, maybe we should have a real "find awol maintainers" solution (e.g. a database that sends out mails and tracks if they get answered or something)
<bpepple> thl: maybe that's something we can work on post F7?
<f13> I would think we'd find them naturally if bugs against their packages go unanswered for a period of time
<nirik> thl: or files bugs against packages and checks to see if they have been closed correctly by the maintainer, etc... but thats another discussion.
<thl> bpepple, that not urgent (but was proposed for F6 already, but never started)
<wwoods> I have a particular itch (sound-juicer built without id3 tag support) I want scratched, but if that type of problem can be fixed without mass rebuilds... then yay!
<thl> bpepple, somebody just needs to do the work...
<thl> but I don't consider it much important
<thl> nirik, yes, for example something like that
<f13> wwoods: I"d rather just see those requests be handed individually
<nirik> tibbs: I think thl asked mdomsch about doing that...
* thl did
<nirik> I was thinking about mirroring fc5/fc6/devel core/extras on a USB2 drive and bringing it with me to fudcon if it would assist any...
<thl> he evaluates if it's possible
nirik, I asked gregdek for a server with a local mirror
<nirik> ok, cool.
<thl> and two machines that can be used to start mock or for people without notebook
<tibbs> nirik: I was planning to have a checked out CVS tree and a mirror on my disk.
<nirik> anyhow, on this topic, perhaps we should ask mschwent to expand?
<notting> nirik: if nothing else a nslug + usb drive
<bpepple> Ok, I'll expand upon this issue on the wiki, and check with mschwendt to see if there's anything else he thinks we should look.
<mmcgrath> we should stick a builder on every box there :-D
<bpepple> nirik: agreed.
<tibbs> I'm going to try and bring an extra laptop as well.
<nirik> I should have access to my ppc/x86_64 boxes here from there too... can do builds...
provided my x86_64 box doesn't decide to keep locking up.
<bpepple> Is there anything else folks want to say in regard to F7 prep? Otherwise I'll move on.
<tibbs> Of course, assuming the network is reasonable I can get back to my home machines as well.  But I'm planning for it not to be, just in case.
<mmcgrath> wait, if we just need more builders...  Why don't we stick some in the colo?
<rdieter> mmcgrath: +1, hack-fest will pound them.
<jwb> we're getting a bit off topic, eh?
* mmcgrath adds a note to the admin schedule
<notting> bpepple: is a description of the proposed acl system & e-mail notification system wanted?
<thl> mmcgrath, then we'd need some kind of scratch repos, too (or am I missing something)
<jwb> notting, i'd like one
<tibbs> I'm not sure how the hackfest will pound the builders, as we won't be submitting things to the buildsys.
<notting> bpepple: or is that too much for here?
<bpepple> notting: I think it would be fine.
<tibbs> Perhaps the reviewed packages will be built  once we're done with them.
<notting> ok, so how ACLs will work: there will be a file 'pkg.acl' that can be added either to the package toplevel or per-branch. lists account names (one per line) that get access
no pkg.acl == wide open
empty pkg.acl == 'owner' only
per-branch ACLs inherit from the toplevel ACL for the package
<nirik> owner according to the owners.list?
<notting> 'owner' == owners.list + owners.epel.list owner
only the owner or the CVS admin can add/modify the acl
<jwb> notting, does this replace or augment owners.list?
<jeremy> jwb: builds on top of
<jwb> so the owner is listed in two places?
<notting> no
the acl lists non-owners allowed access
<thl> the "when to touch other peoples packages" policy allows certain people to touch all packages if there is a good reason too; how will that word with the new scheme?
<jwb> ah, i see
ok
<notting> owner is automatically allowed
<nirik> might need additional privs for security/fesco folks when a checkin/build is needed? ie, the clement stuff?
<thl> certain people: security team
<jwb> let's let notting finish describing it
:)
<notting> thl: there is ATM a cvs admin group with global access. we could work something else out on top of that
this acl mechanism allows for you to have multiple, comma-separated owners in owners.list. however, i suspect you'll break some other tool if you try that
<thl> notting, it's not that important, but you should might want to keep it in mind when you desing the stuff
<notting> (it will all move to the pkgdb eventually)
<jwb> notting, do we have a timeframe for rollout?
<nirik> sounds pretty good to me.
<notting> jwb: soon, very soon. i'd like to get it done before fudcon.
<nirik> on the subject of owners.list... is that a one-way gateway? ie, removing a package doesn't remove the bugzilla component?
<f13> probably
<jwb> notting, and package owners can add user accounts to pkg.acl for co-maintainership, etc?
<nirik> so is there any way to delete components once they have appeared for any time in owners.list?
<notting> big fat warning: as the ACL is used for access control (obviously), and owners.list feeds into the access control.... owners.list is going to be locked down. we apologize for the inconvenience :/
jwb: right.
<f13> but before you scream about notting's warning...
* jwb was just waiting for an explanation
<f13> the new buildsystem requires a buildsystem admin to "add" the package to a collection, before it can be built.
<thl> could that admin then do the cvs branching, too?
<f13> so there is already going to be a barrier of entry, the "add" the package step could populate the owners list, be it in flat file or db.
<rdieter> yay.
<notting> thl: probably the same group of admins that already does it
<f13> thl: technically they are nonblocking steps and can be done in parallel
<jwb> perhaps we should expand the list of admins by a couple people
<f13> you can branch all you want before/after adding the package to the collection, you just can't build before the package is added
<thl> notting, f13 , then I vote for parallel as those stuff often will be needed at the same time
<notting> e-mail notification: the package owner + anyone in the acl for the package will get e-mail notifications of all changes to said branch
<f13> thl: if it is one person doing it, hard to work in parallel sometimes 9:
<notting> thl: parallel of what and what?
<thl> f13, :)
<jwb> f13, hence adding more admins
<thl> f13, nearly parallel :)
<f13> jwb: indeed, this would be very rel-engy type stuff
*hint* *hint*
<thl> notting, add to the collection and request branches
<jwb> f13, sign me up
:)
* rdieter needs to run soon, elf needs food, badly.
<nirik> so what triggers off this? wiki page request? FE-ACCEPT addition?
<bpepple> notting: thanks, is there anything else?
<jwb> nirik, i would think wiki page request pointing to the review bug
* nirik would be happy to help doing these tasks as long as what to do was explained to him. ;)
<jwb> nirik, as is done for branch requests today
notting, oh and this sounds good to me
<nirik> ok. fair enough.
<notting> bpepple: not really.
<tibbs> So does this stuff all exist currently?
<notting> the import process is almost certainly going to change to fail-safe (existing but empty pkg.acl)
<bpepple> Ok, since we're running late we should probably wrap-up the meeting.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras
<notting> tibbs: written, needs finished testing
<bpepple> is there anything folks want to discuss before calling it quits for today?
<f13> nirik: well, if we get an honest rel-eng team built up, an email address that leads to a ticketing system might be better once the import has been done.
<tibbs> BTW, is the repository changing for the merge?  So extras maintainers will need to check out their packages again?
<nirik> would make it easy to find packages with no co-maintainers. ;)
* thl wonders where packages get uploaded in the future after the merge
<notting> tibbs: the old path will work
tibbs: one way or another
<nirik> wonder if some mirrors who don't carry extras will blow up with all of core+extras in a f7 dir... oh well, burn that bridge when we come to it.
<f13> nirik: mirrors will be kept in the loop of changes.
althought it may not be easy to transition them with the use of hardlinks like I did when I changed rawhide layout
* bpepple will end the meeting in 60, and objections?
<f13> so, pain for the mirrors.
<notting> nirik: we are currently discussing a proposed download layout with some mirrors and some community members. it will most likely be a new /pub/fedora/releases (or similar) heirarchy, so things will need to change anyway
<jwb> f13, _growing_ pains
;)
<nirik> we don't create pain, we just mirror it. ;)
* bpepple will end the meeting in 30
* bpepple will end the meeting in 15
<nirik> notting: yeah, and epel in the mix too.
<bpepple> -- MARK -- Meeting End