--- jds2001 has changed the topic to: FESCo meeting -- init
jds2001FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* j-rod here
sharkcz here
notting is here
nirik is somewhat here. Dealing with a work issue as well.
jds2001hehe work tried to get me on a call with 10 minutes notice now.
I said my 1PM was somewhat inflexible :)
jds2001jwb and bpepple won't be able to join us.
jds2001dgilmore: you around?
* jds2001 looking for reliable quorum :)
jds2001dwmw2: ping?
well, i guess we can start with unreliable quorum :)
--- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets
jds2001.fesco 102
zodbotjds2001: #102 (Asking for sponsoring status (+ provenpackager): mcepl) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/102
jds2001I see six +1's, so we've approved mcepl's request for sponsorship. I'll upgrade him after the meeting.
dwmw2sorry; distracted by electronics
jds2001.fesco 109
zodbotjds2001: #109 (Sponsor self-nomination: Michel Salim) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/109
jds2001dwmw2: no problem :)
* jds2001 was looking for the mail thread, sorry
jds2001OK, I see five +1's, so we've approved Michel's request.
jds2001.fesco 114
zodbotjds2001: #114 (Sponsor self nomination: Nils Philippsen / nphilipp) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/114
jds2001anyone else?
jds2001there we go :).  We've approved the request, I'll upgrade him after the meeting
jds2001.fesco 118
zodbotjds2001: #118 (Asking for sponsoring status (+ provenpackager): mmaslano) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/118
jds2001i didnt put this on the agenda and haven't asked for feeback yet, sorry
let's defer to next week.
jds2001.fesco 112
zodbotjds2001: #112 (Provenpackager request: oliver) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/112
jds2001I see five +1's, so we've approved oliver's request, I'll add him after the meeting
jds2001.fesco 117
zodbotjds2001: #117 (Provenpackager request: oget) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/117
jds2001so there were some objections to this on the list.
* jds2001 looks for thread to remember what they were.
jds2001so they were around him would have broken some packages.
dwmw2like that's a reason to withhold it ;)
you going to take mine away too? :)
jds2001if pathes were applied, and applying seemingly random version upgrades when not co-maintainer.
* nirik is able to pay attention now.
j-roddid the co-maintainers complain?
or just ralf?
dwmw2let's just ask him to be careful in future, and grant it
nirikI think many of the objections were that he needed more time to understand things...
notting'seemingly random version upgrades when not co-maintainer' == bad
nirikand the other is that he wanted to bypass a maintainer thats not very active, but I would rather see him take over those packages.
j-rodI think oget is generally quite useful. perhaps a touch cavalier at times. still a bit on the fence.
nirikie, https://bugzilla.redhat.com/show_bug.cgi?id=490398 was brought up.
* nirik thinks he does good work though.
j-rodthe "seemingly random upgrades when not co-maintainer", its possible a maintainer gave the go-ahead
dwmw2that bug is hardly a showstopper. He failed to spot that it could have arch-specific plugins?
jds2001yeah, not sure what the story is behind that.
nirikdwmw2: agreed, just pointing out that he is a bit eager. ;)
j-rodI don't see any real issues w/that bug either
people make mistakes, news at 11
dwmw2as I said: grant it, ask him to be careful.
dwmw2we can always take it away again
+1, please be careful :)
j-rodso here's my thing...
approving someone w/a 'please be careful' caveat says maybe they haven't really fully proven themselves yet
nottingyeah, i'd still vote -1
* dgilmore is with j-rod
nottingif he wants access to fix some packages, apply for co-maintainership
j-rodand/or, the same nutters who wanted provenpackager reseeded might throw a shit fit
* jds2001 agrees come to think of it.
dwmw2it's hard to prove that he won't do things... while we prevent him from doing so :)
j-rodyeah, I know
dwmw2I suppose you have a valid concern about nutters though
can we at least set a time period after which he should reapply, if we're going to say no?
j-rodthat's what I was just kicking around in my head
jds2001I'd like to see specific bugs with patches, too.
nirika month?
jds2001thats what i was thinking.
dwmw2"To balance the concerns raised about overenthusiasm, as well as the concerns which led to re-seeding the provenpackager group in the first place, FESCo has decided not to grant this request for now. Please try again in a month's time, pointing to some specific bugs/patches demonstrating your work."
jds2001dwmw2: sounds great :)
jds2001.fesco 120
j-rodyeah, I like that
zodbotjds2001: #120 (Provenpackager request: mjakubicek) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/120
dwmw2did we actually have concensus on that last one?
consensus even
jds2001dwmw2: there was no way a positive vote could win.
dwmw2: i guess we should be formal about it though
dwmw2fair enough
nottinghrm. the examples given for s-c-cluster and s-c-vsftpd... won't those fixes be possibly overriden the next time an upstream release is made?
j-rodI don't remember seeing any feedback at all on the sponsors list. or did I just conveniently ignore it?
jds2001possibly, but he should be pusing the same stuff upstream.
j-rod: there was feedback :)
mejlanotting: well, in case of s-c-cluster, it might be, but the package is out of upstream interest at all :( They try to move everything to the web based tools (ricci, lucci...etc.)
dwmw2notting: maybe. But hopefully not.
he seems to be making sane fixes after reasonable notice in bugzilla, and not going wild
I'm inclined to say yes
jds2001and hopefully pushing fixes upstream whenever possible.
nottingmejla: makes me wonder if the package itself should be dropped if there's no upstream
but that's sort of neither here nor there
dwmw2jds2001: good point about upstream
jds2001j-rod: two items of feedback, both on 3/15
both +1
* nirik is +1 here.
mejlanotting: the upstream exists but plans to replace the package in the future
* notting is +1
j-rodok, I'll follow the crowd :)
jds2001i see seven +1's, so we've approved mejla's request.
* mejla thanks
jds2001ok, done with sponsor/provenpackager stuff
i promised j-rod last week I'd do this
jds2001.fesco 65
zodbotjds2001: #65 (Fedora Creative Commons Content repository) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/65
jds2001so what's the deal here?
dgilmorewe sent that to the board right?
jds2001the board was sort of wondering why this had to be done under the Fedora umbrella aiui
j-rodI'm not particularly, like, "we MUST have this", I just think it would be kinda cool to provide
jds2001stickster: ping
j-rodthe board wanted to know more details on how it would be implemented, iirc
sticksterjds2001: Yes, Mr Stanley!
jds2001we're talking about the CC repo proposal.
nirikproblem here is that the orig requester didn't provide any details, just that it would be nice to have something like that.
jds2001Could you summarize the board's concerns if possible?
nirikso, we need to make up our own details or the like. ;)
dgilmoreif we make a repo for it.  then content would be packaged as noarch rpms that can be installed on all active fedora releases.
j-rodand rhel releases
* stickster goes to consult the meeting notes so as not to misstate things
dwmw2is rpm the best way to 'package' such content?
dgilmorej-rod: right
* nirik nods at dwmw2. I was just typing that.
dgilmoreso we would probably build on RHEL4
sticksterThere was partial buy-in for the concept, because after all it is free content.
jds2001where do we put it?
dgilmoreso that everything EPEL/fedora supports should be covered
dwmw2I like the idea, but shouldn't any such repository be done in a form that can be used from _all_ kinds of devices? And RPM doesn't really offer that
j-rodmaking it a multi-distro thing would also be cool though
dgilmorejds2001: /pub/fedora/cc/
* notting still isn't sure of the scope of what sorts of content should be covered, and doesn't feel comfortable approving it without that
sticksterOne of the problems is that packaging content in a repo bypasses the originator's delivery channels, meaning they don't pick up whatever traffic helps them
jds2001dgilmore: no, I mean on the installed filesystem :)
j-rodbut how do we deliver !rpm content via yum?
nirikj-rod: does it need to be via yum?
dgilmorejds2001: oh right
j-rodnirik: not necessarily, but it'd be nice to have packagekit-alike integration so you can browse what's available
j-rodand do the same as 'yum search foo'
nottingj-rod: at which point, i think we want a sponsor with a clear idea of what we should do. do we have that?
dgilmorenotting: pdf's, images, ogg video and sound, mp3 mpeg4  etc content  would not be ok
jds2001stickster: isn't that sort of the point of CC - whatever distribution medium suits you?
nirikdgilmore: what exactly do you invision as ok content?
* stickster refers to https://fedoraproject.org/wiki/Board/Meetings/2009-03-03
j-roduh. yeah, what? pdfs are okay...
jds2001stickster: not saying it's a good idea :)
dwmw2I think this is a distraction from our core purpose
nottingdgilmore: but pictures? replacing flikr?
dgilmorej-rod: thats probably a better option. packagekit like search app that puts things into ~/content/
jds2001ogg would be fine with me.
non-porno, etc.
nirikdwmw2: I am inclined to agree. I think also something like this would be nice to be cross distro.
j-rodone of the prime examples was distribution of the linux device drivers pdfs
dwmw2it's a cute project -- providing hosting and collecting CC content. But I don't think it's Fedora
dgilmorenirik: books, music,
* jds2001 wondered at the very beginning if this was Fedora fodder or not.
dgilmoredefinetly no adult content
j-rodis there not CC porn? ;)
jds2001j-rod: im sure there is :)
dgilmorethe more i think of it i think it would be better to do in a distro agnostic way. and have it be its own thing.
jds2001j-rod: we would want nothing to do with it, though :)
sticksterThe only other substantial objection raised was that some of the more propeller-heady folks on the Board (and I mean that in the fondest sense) are concerned about some of the tech. issues that haven't been resolved
j-rodtrue, true
sticksterThe Board seemed to be *generally* in favor of promoting free culture
jds2001stickster: yep.
sticksterBut adding repos to the One True Repo wasn't an immediately popular idea.
j-rodthe thing with waiting for a distro-agnostic thing is... who's actually going to do it?
If there were a fedora-provided content repo, I'd be happy to dump a few things into it
but if I have to go set up this distro-agnostic thing... I just don't have the time
* stickster notes that both RH Docs and Fedora Docs, for example, are working on material that might be cross-distro
nirikmanaging a repo like that also gets into further sticky questions, like: is there a quality bar? who is checking to see if it's not porn? offensive content ok? 10,000 things that are only slightly different ok?
j-rodwell, I think you'd have to have package reviews for anything that went in
nirikie, there would need to be very clear guidelines of what is what.
nottingdo we have a SIG that wants to take this up?
dgilmorei imagine it would end up with millions of items of content
notting: i think we should ask for one to start up around it
jds2001j-rod: would you be interested in leading such a thing?
j-rodif it has to go through review, that sets a bar for entry that people hopefully won't want to put in the effort to clear for utter crap
dgilmorej-rod: i think however delivered all content should be reviewed
j-rodjds2001: perhaps, but I'm severely lacking in time to put toward such a thing
* abadger1999 takes a seat in the back
nirikbut then you need reviewers, etc... would this take away from our already small pool of package reviewers?
nottinghonestly,while it fits with our ideals, i don't think it fits with the idea of concentrating our (somewhat) scarce resources where they work best
jds2001yeah, dunno
nirikisn't there a linux distros list somewhere for distro coordination stuff? perhaps someone interested could bring it up there and see if a community forms?
nottingif it was a group of people coming saying "we'd like to do this, here's our plan", i'd be more in favor
jds2001nirik: yeah, distributions@lists.freedesktop.org
* nirik nods.
jds2001I can take it there and see what happens, or j-rod could :)
j-rodyeah, dunno that there's enough manpower at the moment for anything to actually happen, mostly just a few people who think its a neat idea
j-rodjds2001: I can try to write something up
* nirik def thinks it's a neat idea. I would love a 'cc browser' thing that would let me browse/update/download cc content... but I have no time to work on such a thing.
j-rodnirik: exactly. :\
nirikperhaps the creativecontent community would like to work on something like that too? then we could package it for fedora. ;)
so how are we going to leave this?
j-rodI'll see if we can stir up any cross-distro interest
that's a rather quiet list
jds2001yeah :/
ok, so I missed one sponsor request since i miscategorized it.
just noticed
j-rodbut yeah, let me see if I can drum up some cross-distro collaboration interest and get back to you/us
jds2001.fesco 106
zodbotjds2001: #106 (ProvenPackager and/or Sponsor request: tuxbrewr) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/106
oh, and :)
provenpackager was already approve.d
nirikyeah, we approved him I thought.
jds2001for provenpackager, not sponsor
nirikoh, sponsor... right.
jds2001this is hte sponsor part :)
nirikI think he's been doing good work with kde packages... first triage, then reviews maintaining... I am +1 for him as a sponsor.
oh, and sugar work too. He's reviewed a bunch of sugar packages.
rdieternirik: he has been a great help indeed
jds2001+1 in case it wasn't clear
one more?
jds2001I see five +1
so we've approved Steven's sponsor request.
jds2001.fesco 10
zodbotjds2001: #10 (Review list of non-provenpackager committable packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/10
jds2001rdieter: ?
so the question here is one that came up a long time ago.
* nirik wonders if we can get a current list, or is that the current list?
jds2001what to do about packages that continue to be locked down. I figured that in light of hte reseed, this is the right time to discuss that.
abadger1999: ?
abadger1999Let me see... I think the query was easy to run.
rdieterjds2001: doh, konversation notifier/autoresponder going mad, sorry.
jds2001rdieter: np :)
abadger1999And it's even in the ticket :-)
* nirik suspects it means you need a psql query to the pkgdb... can anyone do that?
abadger1999yeah... running
abadger1999102 packages.  I'll post to the ticket.
* nirik is inclined to send email to all the maintainers/comaintainers here and say that we will be opening their packages to provenpackage next week unless they provide some justification to before next meeting.
nirikto us rather.
dwmw2nirik: +1
dwmw2make that 'file a ticket with justification, so that it can be considered and voted on'
jds2001I can draft and send such a mail.
nirikdwmw2: yeah, +1
dwmw2or 'file a request to remain closed'
nottingdidn't we do this once already?
sharkczI think we already voted that fesco approval will be required to have closed acls
jds2001notting: it was talked about, but we never retroactively applied it.
nirikyeah, we just deffered this until the provenpackager was reseeded.
sharkcz+1 to nirik
nirikabadger1999: is 'b' a legit package?
abadger1999nirik: I was just checking that...
nirikor 'Common documentation files for oVirt' :)
nottingabadger1999: " Perl extension for portable daemons"
abadger1999There's definitely two bogus ones in there.
* nirik is probibly to blame.
jds2001nirik: you broke it :)
nirikprobibly typoed adding some package... ;(
nirikanyhow, shall we do that then? and have a deadline of next meeting?
jds2001yep, I'll get that out this weekend.
i guess we probably should vote on that :)
nottingnirik: i'd say 2 weeks, but *shrug*
sharkcz+1 for the email & reseed
nirikwe could do that to allow for vacationing people... I don't much care.
jds2001yeah, 2 weeks is cool with me.
nirik+1 for email and 2wks deadline.
jds2001i see no objections, so moving right along....
jds2001.fesco 110
zodbotjds2001: #110 (Policy on Flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/110
nirikwhats the issue here?
spot: you around?
nottinghe's in a phone meeting
nirikok. I'm unclear what problem this is solving off hand...
jds2001so reading this, it appears that this came from legal. I'm fine with this policy.
nirik: i think a legal one.
nottingit's documenting the existing policy of "Flags? NO." better
nirikso we can have installs that don't install -flags subpackages?
dwmw2if we ship a Taiwanese flag, we get banned from China
so we choose not to ship any flags at all.
jds2001well, there can be exceptions if they're "substantively essential" to the program
according to this policy.
abadger1999I'd love to see more information about the why's.
dwmw2abadger1999: because there are some flags we can't ship to certain places, and we don't want to get involved in the politics.
dwmw2we certainly don't want to drop _just_ those flags
nirikok, if it's legal I'm fine with it... I assume there are packages that will need to be updated to meet this policy already in...
jds2001let's defer this til next week when spot can educate us more.
nottingso we discriminate against everyone equally. or somesuch.
jds2001i assume this isn't a standing meeting spot's in, notting?
abadger1999dwmw2: Sure... but I want that on the page.
jds2001because then we'd defer forever :)
nottingjds2001: ... somewhat
dwmw2abadger1999: ok
abadger1999It would be useful for deciding things like: is freeciv's use of flags essential to the program?  Will we get in trouble even though it is essential?
jds2001OK, well maybe spot can provide more detail and context in the ticket.
* jds2001 feels fairly uninformed on this.
nottingjds2001: basically, leaving the fesco meeting in UTC runs into this meeting
* notting knows b/c he's in the same meeting ;)
jds2001notting: ouch
sorry bout that :(
jds2001anyhow, I don't feel comfortable voting on this without all the details.
all for deferring?
dgilmorei think its silly  but some govt's policies are silly.  rather than appeasing some we remove all flags.  I think its ok.  not ideal but ok.
j-rod+1 for deferring
nirik+1 to deferr, but we should note our questions in the ticket so spot can get back to us there.
ok, next
jds2001.fesco 115
zodbotjds2001: #115 (making fluid soundfont the default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/115
dwmw2why is FESCo being asked?
* j-rod doesn't know wtf a soundfont is
jds2001not enitrely sure
* jds2001 assumes someting similar to a theme?
jds2001oget: you around?
dwmw2the set of samples which gets used for midi playback?
mharriswave samples
ogetcan I explain what a soundfont is?
jds2001sure thing.
nirikhttp://en.wikipedia.org/wiki/SoundFont :)
ogetit is a collection of many banks of instruments, for use of midi applications
mharriswavetable synthesis IIRC
ogetGeneral Midi is one standard of these collections. Think of it like UTF8
j-rodhrm, okay. and why does FESCo care?
nirikoget: how do we switch the default here? I don't see it in comps... is the old one a dependency? is the old one going to be obsoleted?
j-rodseems like something the Audio SIG should sort out themselves
ogetIt needs modification of the existing soundfont (PCLite). That's why I asked FESCo. Also people on #devel told me to file a ticket here.
jds2001ok, but PCLite is nonfree if I read the ticket right
which means it needs to be blocked anyhow.
ogetyes, PCLite is nonfree
jds2001ok, seems like a no-brainer then.
dwmw2although it'd be nice if it wasn't so much larger.
* nirik is fine with it, +1
jds2001yeah, it's of higher quality if i understand correctly
+1 here
j-rodmeh. presumably its more complete and/or better quality.
notting+1, but "aaargh that's big"
j-rodand its not on the media.
j-rod+1, Just Do It
ogethmm, what about the stable branches?
jds2001I would think that if PCLite is non-free, it needs to be eliminated there as well.
j-rodprobably wouldn't bother with those
except, its already there
so you can't eliminate it w/o yanking it from the base repos
jds2001well, yeah, buyt you can update and obsolete.
nirikwould be a lot of download for stable releases...
j-rodI'd still say its not really worth worrying about at this point
* sharkcz agrees with j-rod
jds2001yeah, and I'm wondering about compatibility too.
OK, so let's do this in rawhide only until someone tells us differently :)
j-rod+1 to that
* nirik nods. Just devel for now.
ogetone last question: Should I submit it to stable as a regular non-default package anyways?
jds2001oget: then folks will get it when they yum update
j-rodnot if it doesn't carry Obsoletes
jds2001yeah, true
yeah, you can submit it without the obsoletes, if you want.
j-rodbut then I wouldn't see the point in adding 200M to the repos
jds2001that might be good.
ogetwell, I can rename the conflicting file (like timidity.cfg.fluid). Folks can use that one if they chose to
jds2001j-rod: people can switch if they want to.
they can upgrade if they want to switch. :)
oget: is it noarch?
ogetyes noarch
j-rodso f9 and f10 users who really want it could just grab the f11 version...
oh, wait.
haha. rpm fail for the f9 users.
jds2001yeah :)
j-rodbut then I'm somewhat of the mind that adding a new package to f9 at this stage in the game isn't the best idea to begin with
nirikwell, it's currently allowed until f11 release day...
jds2001maybe not, but is that our job to legislate?
i mean, it's allowed like nirik said :)
j-rodnot really, no.
* nirik thinks this is up to the maintainers best judgement in this case... keeping in mind the size of the packages for our users.
jds2001nirik: +1
j-rodup to oget, I'm just running my mouth
as a package maintainer myself though, I'd only put it in f11
jds2001j-rod: we have one more thing to get to that you can run your mouth on :)
nirikoget: so, do what you think is best. Do you think there are lots of users of this? perhaps let it sit in f11 for a while to make sure there are no issues?
j-rodyeah. I mean if only 5 people are really likely to install this for f9, I see no point in adding 200M to all mirrors
ogetmainly audio production people. I don't know the size of the user base.
nirikoget: you could also put it in f11 now, and wait and see if you get requests for it in stable releases.
j-rodthe case is easier to make for f10
* nirik wonders if we should move on.
dgilmore agrees
jds2001yeah, i'd like to :)
just one more thing
j-rodyeah, I'd put in f11, shake out bugs, then put into f10, hold off on f9 unless people actually say something
jds2001.fesco 116
ogetok, I'll work with hdegoede and see what packages might be affected. I'll keep it in devel for now
zodbotjds2001: #116 (figure out what to do about deactivated maintainers) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/116
nirikthanks oget!
jds2001so this is a tough one, but I think enough time has passed to say anyone deactivated is non-responsive :/
j-roddeactivated maintainers: shoot first, ask questions later?
jds2001I'd like to send them e-mail once again stating what's going to happen, though
nirikagain, could we update the query? abadger1999 ?
* nirik mailed a few of the top package holders who said they changed their password. The list should be shorter now.
abadger1999nirik: That query takes a good chunk of time to run.  I can update the ticket after the meeting.
nirikok, no worries.
* abadger1999 starts query running now
j-rodawjb seems quite prevalent in that list...
nirikj-rod: he should be ok now.
nirikhe was moving and didn't have good net access, but my email prompted him to at least reset his password.
j-rodI see a mildly alarming # of @redhat.com people...
jds2001do they no longer work for RHT?
or are they just busy with $DAYJOB?
j-rodso far as I know, they all still work here
nottingwe're handling the RH stuff
at least, we've already started contacting/poking/etc people
jwbheh, drepper
nirikso, perhaps we should wait a bit longer and then mail, and then orphan?
jds2001notting: cool.
nirik: yeah, say wait til next week, mail, wait 2 weeks, then orphan?
j-roddrepper, davidz, ssp, mpg, dmalcolm, jparsons ...
* nirik thinks having people who are unresponsive maintaining packages isn't all that good a thing.
nirikin any poking we should also mention that they might really want to consider co-maintainers.
jds2001maybe some already have them.....
niriksome do, many don't.
jds2001but i guess the query filters out those that do?
nirikno, they are at the end... listing the comaintainers.
abadger1999jds2001: The latest query lists the comaintainers on those that have them.
jds2001abadger1999: awesome.
nirik+1 to wait a week, mail, wait a week, mail again, orphan.
jds2001alrighty, that's the plan then.
jds2001that's all I had, anything else?
wwoodsoh fesco, I have a question for you
jds2001wwoods: what's that?
wwoodsit's kind of a thought experiment.
let's say we were going to lengthen the Fedora *development* cycle
while keeping the *release* cycle the same
i.e. we still branch rawhide every 6 months, but we don't release at the same time as we branch
we do a couple months' worth of stabilization and testing and bugfixing first.
to accomodate such a schedule shift, we have two choices:
a) skip a release to realign the schedules to may day / halloween,
b) do a bunch of short releases (with overlapping rawhides) to realign the schedules
nottingi think the result of that is just rawhide would get neglected a couple more months
nirikwell, its an interesting idea... has some pros and cons...
jds2001we're already looking at a compressed F12.
wwoods(this assumes that we want to keep the may day / halloween schedule, which is useful because it avoids collisions with xmas / summer holidays)
no, we'd still branch rawhide every 6 months - I'm not lengthening any rawhide freezes / feature freezes
jds2001F10 sort of killed that for us for a bit. I think F12 will get us back on track the way things are now iirc.
we agreed to give F11 more time and rob it from F12.
nirikso, essentially there would be a fN and then after a few months of stablizing a fN.1 ?
wwoodsyes, but that's irrelevent to the current discussion, where I'm talking about introducing an extra 1-3 month stabilization phase
wwoodshttp://wwoods.fedorapeople.org/images/fedora-ideal-schedules.png might help visualize it
* nirik moves that we all ponder on this and bring it up in another meeting were we are not already 5min over. ;)
jwbneed color key
what do the colors mean?
wwoodsred: merge window (pre-feature freeze). orange: post-feature freeze. blue: release.
green: new post-Beta stabilization period.
nottingso, essentially: fork rawhide at beta
jwbwwoods, put it in the png
wwoodsjwb: yeah, working on it
nottingi'm not sure that helps one way or another
we already allow early branching after beta, and no one (*) does it
j-rodmandatory branching
wwoodsnotting: I think it would - also we don't produce rawhide from the early branch
j-roder, make branching after beta mandatory
jds2001so in green we're branched and rawhide moves on?
wwoodsanyway, yeah, I don't want to make this a long, long discussion
jds2001: yes
in the green sections we'd be using bodhi etc. as normal to push updates
except they'd be getting pushed into the beta
rather than into the release
nottingoh, the pain
j-rodpeople can continue to throw crap at rawhide if we branch early, and have to think harder before they put stuff into the beta branch
wwoodsanyway, it's mostly a discussion topic, but the actual question is:
if we needed to realign schedules for a fairly large change like this, is it better to rush-rush-rush and have multiple rawhides going at once
or to, say, skip the spring '10 release
nottingi suspect you'd still have your two groups of maintainers - those busy developing & bugfixing, who won't have time to look at the earlier rawhide, and the "build everything for all branches", who will just end up building *more* stuff
wwoodsand have a long F13 cycle
jwbmaking bodhi do more update pushes will make me cry
wwoods(this also brings up the question: do we still want to target may day and halloween?)
mharrisThat'll be interesting..  F13 coming out on Halloween...   even better if it is a Friday the 13th
jds2001so we're over for the meeting, this is a really interesting discussion.
Let's table and put it on the agenda for next week?
wwoodsright - I'm trying to summarize most of the obvious questions and answers before I put together a full proposal
mharriswwoods: I like the May 1 release schedule... it's my birthday :)
wwoodsbut doing a proposed schedule required me to answer those two questions
abadger1999It looks like 9 month development scheduling overlapping with FedoraN+1's development.
j-rodpersonally, I'd say skip a release rather than rush the hell out of things
abadger1999With all of the benefits and drawbacks that entails.
jds2001I would rather skip a release than rush things to align the schedule.
wwoodsabadger1999: exactly so. it's essentially the same as the current schedule, except where we now do the release.. we call that "beta". and after N (cur=3) months of kicking it around and pushing fixes through bodhi, *then* we compose a release.
jds2001Might be a PR issue, though.
wwoodsdoing an extra-long devel cycle for Fedora N implies supporting Fedora (N-2) for an extra-long time
so that's something else to consider.. later
so, okay, avoid the trainwreck schedule
wwoodsbut we *do* think it's worthwhile to go so far as to skip a release to realign to may 1 / oct 31?
j-rodI do
nottingi'm still not convinced of the original proposal. which makes the rest of the discussion....
jds2001I think the community expects that alignment, and it was very deliberatly chosen, so yes.
dgilmorewwoods: right but current policys would cover that
wwoodsnotting: right - I'll try to address that stuff as best I can
(3 months might also be a little long - could be 2 months. I think 1 might be too short.)
f13I'd rather spend a release doing nothing but polish and very few invasive features than skip a release.
nottingwwoods: i don't understand you saying 'where we now do the release, we call that "beta"' with respect to your branching
jwbflow chart required
nottingas the point where rawhide is branched is *NOT* the release date
f13its well before it
jds2001notting: right, but when rawhide starts rolling again is release date.
wwoodsnotting: we retain some schedule features: 4 months from branch to feature freeze
then two months from feature freeze to a release
dgilmoref13: i think i agree
wwoodscurrently that's the final release
f13is this being discussed for vote today?
f13ok.  I'm not able to pay much attention
jds2001just food for thought.
wwoodsnope, this is just a post-meeting thought-experiment
nottingin fact, i think it was tabled 15 minutes ago, and people kept talking :)
wwoodsyeah. if there was a watercooler in here, we'd be standing around it
jwbwe need beer coolers
nottingjds2001: are we officially closing the meeting?
abadger1999f13: We could have a four month polish release for F13.5 (Eamon)  ;-)
notting(and who's our lucky summarizer today?)
jds2001notting: yeah, let's do that.  Great conversation we can take to #fedora-devel or whereever.
2.33 hours is enough for me :)

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!