17:00:24 <limburgher> #startmeeting FESCO (2012-10-24)
17:00:24 <zodbot> Meeting started Wed Oct 24 17:00:24 2012 UTC.  The chair is limburgher. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:25 <limburgher> #meetingname fesco
17:00:25 <limburgher> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:00:25 <limburgher> #topic init process
17:00:25 <zodbot> The meeting name has been set to 'fesco'
17:00:25 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:00:30 <limburgher> Roll:
17:00:33 * limburgher here
17:00:35 <mmaslano> hi
17:00:38 <nirik> Morning everyone.
17:00:39 <mjg59> Hi
17:00:40 * jwb is here
17:00:54 <limburgher> notting will be late.
17:00:56 * ianweller here
17:01:10 <ianweller> wait wrong meeting. i thought it was thursday.
17:01:11 * ianweller stops being here
17:01:16 <limburgher> :)
17:01:45 <limburgher> mitr, pjones, t8m?
17:02:11 <mitr> Hello
17:02:25 <mitr> I'm sorry I was late
17:02:27 <limburgher> np.
17:02:34 <limburgher> Ok. . .
17:02:39 <limburgher> #topic #946 Fedora 18 Beta freeze readiness: is major functionality in place?
17:02:47 <limburgher> .fesco 946
17:02:50 <zodbot> limburgher: #946 (Fedora 18 Beta freeze readiness: is major functionality in place?) – FESCo - https://fedorahosted.org/fesco/ticket/946
17:03:08 * notting is back now
17:03:09 <nirik> more work on fedup has taken place, but it's not yet available as a package/ready for testing that I know of.
17:03:25 <nirik> wwoods: if you are around, any eta on packaging/testable state on fedup?
17:03:33 <limburgher> But we're basically in "freeze when it drops" mode, corerct?
17:03:50 <nirik> yeah, thats my understanding.
17:04:24 <limburgher> So we should move on then, unless someone has something to add.
17:04:33 <notting> i'd like to make a counterproposal
17:04:42 <limburgher> ok
17:04:59 <notting> proposal: freeze now, with understanding that we take fedup when it drops
17:05:15 <notting> this provides clearer messaging to those working on everything else
17:05:39 <nirik> sure, but we are entering freeze without the updater being code complete. ;(
17:05:57 <mjg59> What's the purpose of freezing?
17:06:24 <nirik> stop non blocker changes.
17:06:26 <limburgher> notting: Does that do anything different other than firing the QA starting gun?
17:06:28 <pjones> limburgher: I'm here.
17:06:33 <nirik> so qa has a thing to test.
17:06:37 <limburgher> pjones: <waves>
17:06:48 <mjg59> nirik: QA can't test without the updater?
17:07:13 <notting> limburgher: right now, someone working on $random_thing knows to check fesco on weekly basis for 'are we frozen?', can plan work accordingly.
17:07:20 <limburgher> mj959 I suppose they could, knowing that the only bit to change is in f17 only.
17:07:23 <nirik> mjg59: sure they can and are.
17:07:31 <notting> limburgher: with 'freeze-upon-fedup-landing', they now can't really plan, and have to be ready for freeze-at-any-time
17:07:31 <limburgher> notting: Right.
17:07:51 <mjg59> nirik: So why do we need the updater before the freeze?
17:07:53 <nirik> the problem is if the updater is not ready next week. or the week after. that constrains the rest of the non blocking stuff behind the freeze
17:08:24 <nirik> so we could end up with: everything is done, but no updater, so we will sit here and wait for it without letting non blocking changes go thru
17:08:27 <mjg59> Ok so the concern is just that if we don't have a timeline, the freeze may drag on too long?
17:08:27 <jwb> notting, tbh, they should have already been ready for that
17:08:33 <notting> mjg59: the ability to upgrade is part of the beta criteria
17:08:33 <nirik> yes
17:08:45 <mjg59> notting: Right we obviously couldn't release the beta without the updater
17:08:54 <limburgher> nirik:  The idea being with your proposal that the others get bonus time to work.
17:09:11 <nirik> yeah, but in the end it's not probibly much time (hopefully)
17:09:14 <limburgher> It's a tradeoff either way.
17:09:18 <nirik> right.
17:09:19 <mitr> notting: it seems to me that people who are planning in detail, have been planning of a much freeze date that is already in the past, and they are in the area of unexpecte d in any case.
17:09:33 <limburgher> mitr: +1
17:09:55 * nirik wishes we had a better idea of current fedup status. :( Anyone have a way to summon wwoods ?
17:09:56 <mitr> Or is the goal of this to primarily slow down f18 already, for some assumed benefit? (perhaps to make the QA results more predictive?)
17:10:39 <pjones> nirik: /invite?  /msg?
17:11:45 * adamw stops in
17:12:17 <drago01> nirik: https://github.com/wgwoods/fedup/commits/master
17:12:30 <adamw> i'd say if we're committed to having the upgrader in the beta we shouldn't freeze till it's done; if we want to freeze we need a plan for releasing without the upgrader.
17:12:53 <nirik> drago01: yes, I know. :)
17:13:03 <limburgher> adamw:  Which we most certainly don't have now.
17:13:42 <nirik> those alternatives would be: a) sorry, no upgrade and b) use yum... both of which are... not very ideal.
17:13:42 <t8m> adamw, +1
17:14:06 * jreznik_ is here, sorry, another meeting... :(
17:14:09 <t8m> -1 to notting's counterproposal unless it somehow magically makes the fedup testable faster
17:15:37 <adamw> i don't think there's any qa objection to the idea of freezing on whatever day the upgrader gets finished, btw, rather than requiring it to be a certain day of the week.
17:15:39 <mmaslano> I guess we already agreed with nirik's proposal in ticket
17:16:14 <mitr> Well, delaying the freeze instead of just letting the release criteria prolong the freeze period is AFAICT a new concept this release. It was obviously the right thing to do for Alpha, for Beta I might be persuaded it's not the right thing - however I'm not sure anyone is actually advocating for prolonging the beta freeze instead of the pre-beta period
17:16:15 <drago01> why do we require it to be a certain day of the week anyway?
17:16:19 <limburgher> mmaslano:  And I don't see a ton of support for nottings proposal.
17:16:20 <drago01> that makes no sense to me
17:16:20 <nirik> one problem is that we don't say we slip yet... so...
17:16:46 <mitr> drago01: It's an automatic result of the readiness review meetings happening weekly
17:16:51 <notting> drago01: predictability. with 100+ developers, it helps if freezes are usually on the same day of the week
17:16:52 <nirik> drago01: because releases are on tuesdays, we need time to sync to mirrors
17:17:19 <adamw> nirik: we're talking about *freeze* here, not go/no-go.
17:17:32 <drago01> nirik: that makes sense for the releases but not for the freezes ... it is just the point of having non blocker bugs staying out
17:17:33 <jreznik_> mitr: it's definitely the new thing, it helped us a lot to avoid the two weeks freeze and let people work without disruption but now it seems like we released Genie from a bottle
17:17:35 <adamw> there's nothing to sync/stage after the freeze point.
17:17:39 <nirik> adamw: sure, but they are tied... if we freeze the day before release that... won't work
17:17:55 <drago01> notting: that does not help ... you'd have to look up the schedule anyway which mentions a date
17:18:09 <nirik> there has to be enough time to test, and decide go, and sync to mirrors
17:18:30 <adamw> jreznik_: really, if we'd frozen, we'd just be having this debate about go/no-go instead, so i don't think it makes much difference.
17:18:46 <adamw> jreznik_: we'd have had one or two go/no-gos where we argued about whether we should go or not go without the upgrader being ready.
17:18:50 <nirik> the only difference is that there's more time for non blocking stuff to flow thru...
17:18:54 <mitr> adamw: from a QA perspective, how problematic do you think the freeze postponement (and the associated increased amount of changes between alpha and beta) is?
17:19:00 <mjg59> nirik: Or for stuff to break
17:19:00 <limburgher> nirik: Which is helpful.
17:19:08 <tflink> jreznik_: why do we have to freeze for at least 2 weeks? Why not start the go/no-go earlier?
17:19:10 <nirik> mjg59: yep. that too.
17:19:13 <limburgher> mjg59: Or be fixed. :)
17:19:14 <adamw> mitr: hasn't been a problem at all. we actually proposed the whole 'don't freeze until the code is ready' thing in the first place and we would like it to be a permanent thing.
17:19:14 <wwoods> *thud*
17:19:23 <mjg59> wwoods: Would freezing make fedup development easier?
17:19:24 <mitr> Or, perhaps, let me step back.  Is there any disagreement about uprades being ABSOLUTELY REQUIRED a) by final, and b) by beta release?
17:19:29 <wwoods> mjg59: nope.
17:19:31 <nirik> hey wwoods. :)
17:19:34 <limburgher> wwoods:  Was that what I hope it was?
17:19:56 <nirik> mitr: not from me.
17:19:58 <wwoods> limburgher: were you hoping it was me falling face-first onto my desk?
17:20:08 <wwoods> and if so, WHY WOULD YOU HOPE FOR THAT D:
17:20:20 <jreznik_> ;-)
17:20:24 <limburgher> wwoods:  No.  I was hoping it was fedup dropping. :)
17:20:27 <wwoods> oh
17:20:29 <wwoods> well it's not that
17:20:32 <wwoods> I'm packaging it now
17:20:37 <limburgher> <facepalm>
17:20:39 <limburgher> :)
17:20:40 * nirik cheers.
17:20:49 <limburgher> <happydance>
17:20:53 <nirik> so, it's 'code complete' but not yet packaged?
17:21:00 <wwoods> finally did a fully successful upgrade. turns out you can't run upgrades with selinux enforcing because.. WHO KNOWS
17:21:06 <wwoods> it's not 'code complete'
17:21:12 <wwoods> it's 'something people can actually test'
17:21:22 <wwoods> it doesn't have a GUI, for example
17:21:28 * nirik nods. ok.
17:21:29 <wwoods> nor can you upgrade offline, from media
17:21:48 <wwoods> but I wanted to get *something* into peoples' hands so I can get help with the rest of the bugs
17:22:05 <nirik> yep.
17:22:05 <limburgher> Beautifl, thank you!
17:22:08 <limburgher> u
17:22:21 <nirik> ok, so, IMHO then, I say we freeze now. :)
17:22:31 <drago01> wwoods: any timeline for when the missing bits will land?
17:22:38 <jreznik_> well, the question is - if offline upgrade from media is the must for beta or some upgrade method (from running system) is needed
17:22:38 <wwoods> e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=869061
17:22:39 <limburgher> nirik: +sixtygreen
17:22:48 <wwoods> https://bugs.freedesktop.org/show_bug.cgi?id=55669
17:22:53 <nirik> jreznik_: it's not by the current critera
17:22:56 <tflink> jreznik_: the release criteria as currently written only require one method to work for beta
17:22:57 <adamw> jreznik_: the criterion is fairly generic, it just requires some upgrade method to be available.
17:23:32 <jreznik_> well, ok - so we should prioritize what we want deliver for beta - if it's just running system one, good
17:23:37 <wwoods> and a bunch of other stuff I'm filing now
17:23:39 <nirik> wwoods: I'd be happy to help review the package if you like, just cc me or drop me a ping when it's ready.
17:23:42 <mitr> jreznik_: whatever method we decide we want, beta should be a superset-or-equal of the method for final.
17:23:47 <wwoods> nirik: will do
17:24:02 <tflink> mitr: superset or subset?
17:24:02 <nirik> "For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:24:18 <mitr> tflink: 'everything we want to deliver in final should be already present in beta"
17:24:48 <drago01> mitr: that means we should slip again ....
17:25:01 <jreznik_> mitr: can we afford it in current state? means beta could slip for month...
17:25:31 <mitr> drago01, jreznik_: or decide to release F18 with a smaller set of "officially recommended" update mechanisms.
17:25:46 <tflink> if everything in final should be present in beta, why have separate final and beta release requirements?
17:25:49 <mitr> jreznik_: Alternatively, can we afford to release final with an upgrade method that didn't go through beta testing?
17:26:00 <abadger1999> since 0xf13 designed our betas to be a lot like other project's release candidates, mitr's view and the idea of slipping seems correct...
17:26:01 <limburgher> mitr:  Reasonable.  non-official means often are usable, i.e. yum
17:26:03 * nirik isn't following mitr
17:26:09 <mitr> tflink: present, not 100% bug-free
17:26:24 <nirik> mitr: you mean the fedup gui not being testable yet?
17:26:30 <adamw> okay, so on the criteria, remember the pre-18 situation
17:26:41 <drago01> mitr: the thing is we would be moving from a "notification + some clicks + reboot" to "open a terminal and type some commands"
17:26:41 <adamw> we had two 'supported' upgrade methods, preupgrade and direct anaconda
17:26:55 <adamw> the idea is that we didn't need to require both of those to work for beta; if one worked and the other didn't ,that was enough to release beta
17:26:56 <drago01> mitr: not really an imporvement from a user expirence pov
17:26:59 <mitr> nirik: I'm just stating my preferred criteria - every official mechanism is tested in beta.  The claim that this means slipping was added by someone else.
17:27:02 <adamw> it was more about whether they *worked* than whether they were present
17:27:15 <nirik> mitr: which will be... 'fedup'
17:27:23 <adamw> for F18, as things stand, there will be effectively no difference between the beta and final criteria
17:27:29 <limburgher> If the logic is done, the GUI's gravy.  Not totally, but in part.
17:27:30 <adamw> as we don't have two or more supported methods any more, we have one
17:27:39 <adamw> so both Beta and Final criteria effectively mean: fedup has to work.
17:27:41 * nirik nods.
17:28:19 <adamw> we could go down a side alley of whether the beta criteria should focus more on 'testability' than 'workingness', but that could get messy.
17:28:24 <jreznik_> adamw: but we still have two different methods just both methods has the same name
17:28:32 <adamw> jreznik_: what do you mean?
17:28:35 <nirik> proposal: freeze now for beta.
17:29:17 <jreznik_> adamw: same as before, preupgrade = fedup from running system, anaconda = fedup on offline image
17:29:34 <drago01> also semi releated question ... how do we got into this "mess" and how do we adjust the feature process to avoid getting into the same situation again?
17:29:39 <adamw> jreznik_: no, that's not quite it.
17:29:39 <t8m> as the gui/cmdline UI is not really in F18 but in F17, I don't think this should block beta freeze
17:29:45 <jwb> drago01, that's a different meeting
17:29:57 <adamw> jreznik_: in both cases you will run fedup from the running system. it's just that it can use either remote repos or a DVD / DVD image file as a package source, AIUI.
17:29:58 <drago01> jwb: fair enough
17:30:05 <jreznik_> the main problem is - the ongoing anaconda development does not fit any process we had before... it conflicts with the way how we release, with release criteria etc.
17:30:07 <adamw> jreznik_: the actual upgrade mechanism is the same in both cases, i believe. wwoods could say for sure.
17:30:10 <limburgher> For now, let's vote on nirik's proposal.
17:30:25 <jreznik_> adamw: yes, it is - ok, it's just about using different words :)
17:30:42 <jreznik_> but seems we can get some functionality now, but not all
17:31:04 <adamw> okay, but i don't really see them as 'different methods'.
17:31:23 <nirik> if those are different methods, then preupgrade was several different methods too. ;)
17:31:25 <adamw> anyway...if we can commit to having the fedup package in the repos very soon I guess qa is OK for freeze now, tflink, cmurf?
17:31:31 <mitr> t8m: I would be fine with a working-but-unpackaged fedup - it still can be tested for blockers, and there would be time to get the rpm to F17 by beta GA.  packaged-and-nonworking fedup wouldn't be that great
17:32:19 <jreznik_> mitr: seems we can get even packaged one, but not with all features in (gui, offline upgrades from media)
17:32:23 <nirik> mitr: well, it at least works somewhat... "...did a fully successful upgrade." from wwoods. ;)
17:32:33 <adamw> although it seems like we're maybe a little too enthusiastic in accepting that it's certain everything is hunky dory now
17:32:51 <limburgher> not hunky dory, but testable.
17:32:53 <adamw> there could still be some kind of problem in people-other-than-wwoods testing the code that he hasn't envisioned
17:32:58 <nirik> adamw: I don't think everything is hunky dory, but I think it's encouraging enough to freeze now.
17:33:13 <adamw> limburgher: well that's what i meant. in _theory_ it is, but still, right now, i don't think anyone but will has actually run the code with any success. he says that now they could, but.
17:33:15 <notting> the idea of having it testable is that it needs to be ready for the general beta-using population to use it as an upgrade method (with the understanding they'll file bugs if it fails)
17:33:16 <nirik> especially since more slips mean more and more and more pain
17:33:18 <notting> are we there?
17:33:25 <jreznik_> that was the main reason I didn't want to slip directly hoping to get something this week, nirik's proposal helped here (at least it seems like)
17:33:39 <limburgher> adamw:  That's why it's Beta-testing, not Beta-production-releasing. :)
17:33:50 <adamw> notting: that wasn't quite how i read it...as far as freezing goes, i think it only needs to be 'testable' by the fairly clued-up people who do validation testing. your wider sense of 'testable' makes sense for shipping the beta, i think, not for freeze.
17:33:52 <wwoods> there's plenty of bugs. that first one is basically 'no output during upgrade haha whee'
17:34:20 <jreznik_> wwoods: could you prepare a guide for us/qa how to test, what's supposed to be working?
17:34:26 <nirik> but for beta it simply needs to complete. ;)
17:34:27 <wwoods> jreznik_: I will once it's packaged
17:34:41 <limburgher> We're past 30 minutes.
17:34:45 <nirik> sorry "must be possible to successfully complete"
17:34:49 <adamw> but still, right now, as i said, no-one but will has seen the code do anything, is the bottom line.
17:35:20 <wwoods> adamw: the code's all public. feel free.
17:35:25 <nirik> anyhow... votes?
17:35:26 <jreznik_> adamw: I asked jskladan/kparal to test it but it was version that did not complete :) hope we can ask them to retest?
17:35:37 <jreznik_> wwoods: ^^^ ;-)
17:35:47 <nirik> +1 to freeze now, and follow the schedule as it is now.
17:35:50 <tflink> I'm thinking pretty much the same thing - I'd like to see a bit more testing before freeze. I'm setting up a system to test now
17:35:56 <tflink> but my vote doesn't count :)
17:36:03 <jreznik_> wwoods: btw. what's required to have offline media working? any releng task etc?
17:36:12 <limburgher> +1 freeze now.
17:36:16 <wwoods> jreznik_: nope, just code
17:36:28 <wwoods> well, we need to get the bits into media via lorax
17:36:38 <wwoods> so a little releng work there
17:37:04 <nirik> wwoods: when do you hope to have packaging done? today?
17:37:07 <wwoods> but that's not useful until the code can handle it, so..
17:37:10 <wwoods> nirik: that's the plan
17:38:10 <limburgher> Any other votes out there on freezing, or counter-proposals?
17:38:13 <adamw> if we freeze now, what's the go/no-go date?
17:38:51 <jreznik_> adamw: Thu 2012-11-01
17:38:53 <nirik> 2012-11-01
17:38:58 <adamw> okay, so one q for wwoods
17:39:18 <adamw> wwoods: being pessimistic - remembering you've been over-optimistic on these questions before - do you believe that you will have fedup in beta-ready state by that date?
17:40:15 <mjg59> Higher probability if anyone else is willing to actually look at the code
17:40:48 <wwoods> define beta-ready?
17:41:23 <nirik> "For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."
17:41:29 <nirik> which it already has for you no?
17:41:33 <adamw> hum, good question. let's say the most straightforward use case - upgrading from a clean F17 install, with remote repos? - should work, via GUI, without any hideous hackage required?
17:41:51 <adamw> well, maybe we don't require GUI, but just a sane interface.
17:42:12 <wwoods> GUI isn't gonna happen in a week.
17:42:16 * t8m has to go away
17:42:29 <adamw> and as notting says, it should be possible for an average tester, you know, we can give them straightforward instructions, 'yum install blahblah, run command, follow the prompts'
17:42:49 <wwoods> media probably won't either. unless I'm lucky. which I'm not.
17:43:07 <adamw> we probably don't absolutely need that done for beta, i guess, though it'd be nice.
17:43:29 <adamw> what do fesco think about the desirability of media upgrade / GUI?
17:43:49 <mjg59> I think it's desirable
17:43:54 <mjg59> Like world peace is desirable
17:43:56 <nirik> I think those are nice, but I would be willing to not have them for beta in exchange for a beta in 2012. ;)
17:44:04 <adamw> let's think - i guess GUI can be fixed with an update to f17, so we could add it in during the beta cycle
17:44:19 <adamw> but possibly we couldn't add media upgrade during beta cycle, right? as it would need to be baked into the release beta image?
17:44:21 <wwoods> in short - I don't expect anything more than what currently exists (it'll fetch packages from the network and upgrade from f17 to f18) to happen in a week.
17:44:27 <drago01> adamw: well it has to be there before GA
17:44:28 <adamw> so if we don't require media upgrade to be done, it wouldn't be testable until final TC1
17:44:29 <notting> i would think GUI is far far preferable to media, if you're asking me to prioritize
17:44:32 <drago01> adamw: with some time to be tested
17:44:37 <drago01> adamw: (it = gui)
17:44:40 * nirik agrees with notting
17:45:01 <wwoods> I do expect that progress will accelerate once it's out in the wild, though
17:45:05 <mitr> I would prefer media to GUI
17:45:10 <notting> the entire impetus behind media upgrades was more or less that the upgrader was already there on the media. now that that's no longer the case...
17:45:16 <mitr> But then perhaps we don't need media after all?
17:45:20 <adamw> wwoods: am i correct on the add-ability of those features?
17:46:11 <jreznik_> notting: if standalone fedup would be able to easily upgrade from media, no... it does not have to be on media, but we need some offline upgrades support
17:47:14 <notting> jreznik_: i'm willing to accept bodges of the sort where you take the media, copy stuff off the media to where fedup-would-have-put-it-anyway, and then do fedup, for this release
17:47:29 <limburgher> notting: nods
17:47:31 <wwoods> GUI can be added post-beta, yes. media upgrades.. I think so, if we get the existing framework bits into the Beta media
17:47:57 <jreznik_> wwoods: +1 for post beta gui
17:48:14 <drago01> notting: or just prepare bootloader etc ... and then mount the media?
17:48:23 <limburgher> 45 minute mark, FYI.
17:48:31 <adamw> wwoods: okay. so if you realistically believe we can have basic testability by an average tester for the proposed go/no-go date, i'm okay with freezing.
17:49:36 <nirik> limburgher: so we are at +2 now? any other votes?
17:49:43 <wwoods> notting: yeah, even putting the existing CLI stuff onto the media wouldn't give us offline upgrade from media.. at least not at the moment
17:49:48 <limburgher> nirik: yes, not so far.
17:51:00 <pjones> nirik: refresh my memory on what the current proposal is?
17:51:05 <jwb> freezing
17:51:35 <pjones> ... and just acknowledging that fedup will drop after freeze so upgrade testing isn't a thing just yet?
17:51:56 <limburgher> pjones: Basically.
17:51:58 <nirik> right.
17:52:09 <adamw> pjones: well i think the idea is that we can actually test it now if we do the necessary grabbing-it-from-git stuff.
17:52:14 <nirik> freeze now, stick to current schedule, hope fedup is testable very soon
17:52:19 <adamw> probably tflink or i will try it later today.
17:52:22 <pjones> (And also, though it hasn't been brought up, that legal hasn't said we can get things signed for uefi SB just yet...)
17:52:35 * tflink is getting started. will be testing x64 and i686 today
17:52:49 <jwb> nirik, and if not?
17:53:18 <drago01> pjones: isn't that a blocker as well?
17:53:21 <nirik> jwb: then we are frozen, and we stay that way until we can release beta.
17:53:25 <limburgher> no go, then.
17:53:46 <jwb> i am currently not thrilled with being frozen indefinitely
17:53:49 <drago01> pjones: without the signing it isn't testable
17:53:53 <pjones> drago01: the possibility that people would like to treat that as a blocker is why I brought that up just now, yes.
17:54:07 <jwb> it's possible to do the 'fedora signed' thing
17:54:11 <nirik> jwb: me either, but I like it better than a january release. ;)
17:54:33 <jwb> nirik, i don't believe freezing now will impact that either way
17:54:38 <jreznik_> jwb: for beta, fedora signed could be acceptable...
17:54:39 <nirik> (well, slip and january release, we may still have a january release with freezing... just hopefully less likely)
17:54:44 <jreznik_> jwb: I still hope so :)
17:55:24 <nirik> well, we could wait and freeze later today after fedup package is available?
17:55:24 <jwb> are things going into f18 that are breaking a bunch of stuff?  if not, i don't see the point in freezing at the moment
17:55:24 <drago01> pjones: also did legal give you any timeframe for when they know whether you are allowed to sign?
17:55:49 <nirik> jwb: problem is, if we wait and don't freeze until next tuesday, we slipped a week.
17:55:53 <mmaslano> nirik: I tend to agree, because we don't have better plan
17:55:54 <adamw> jwb: generally speaking, no, we've kind of outrun them all. gnome is stable atm, so is kernel, etc.
17:56:04 <jwb> nirik, why a week?
17:56:11 <pjones> drago01: I think that's what's called a known unknown.  I don't know what the hold-up is; honestly I expected it last week.
17:56:14 <adamw> jwb: the last few TCs have all been generally solid builds, no regressions caused by dumb changes.
17:56:18 <nirik> either we slip a week or have less than a week freeze.
17:56:24 <drago01> pjones: ok
17:56:33 <jwb> i mean, if the tree has been fairly solid for a while now, i don't see the point in freezing for a week
17:56:44 <jwb> we're well beyond "normal process" here anyway
17:57:12 <nirik> jwb: what, so no freeze at all? I don't think that works.
17:57:42 <nirik> according to our current schedule, we would have frozen yesterday.
17:57:47 <jwb> freeze for a day.  or two.  or none at all if the first beta tc actually works
17:58:19 <nirik> jwb: first beta tc? we are on 6 already. ;)
17:58:28 <adamw> i guess he meant RC.
17:58:33 <jwb> yes, rc
17:58:36 <mitr> So that would mean "get as much of the beta release critieria covered as possible, and freeze just enough to test the upgrade process"?  Does that make sense?
17:58:41 <nirik> the purpose of the freeze is to stop churn into update while qa is attempting to test.
17:58:51 <jwb> they're testing already
17:58:54 <nirik> I don't think they would be happy with no freeze.
17:59:13 <jwb> or if they aren't testing, i don't see how adamw can say the last few TCs have been solid
17:59:19 <nirik> there's 30-40 packages a day going into f18 right now.
17:59:21 <tflink> personally, I don't care a whole lot about the freeze length as long as we have enough time to run through the matrices
17:59:35 <pjones> tflink: ... well, obviously.
17:59:58 <adamw> we could build an RC without being frozen, there's no particular reason why not. but i think we'd want to freeze once we build the first RC at least.
18:00:03 <limburgher> 60 minute mark.
18:00:21 <jwb> adamw, nirik: so we build an RC, and we don't push updates for a while while qa runs
18:00:29 <limburgher> Still at +2 to freeze now.
18:00:33 <mjg59> +1
18:00:34 <adamw> which sounds rather like a freeze. =)
18:00:43 <adamw> 'don't push updates for a while' is basically what a freeze is.
18:00:46 <pjones> adamw: for that matter we could freeze and build a TC without calling it an RC or Beta.
18:00:58 <jwb> adamw, the intent is you run quickly
18:01:03 <nirik> so options: a) freeze now, stick to schedule. b) wait until fedup package is available, freeze then stick to schedule, c) something else with less freeze?
18:01:06 <nirik> pjones: nope.
18:01:09 <jwb> adamw, and it's not a week freeze
18:01:19 <pjones> nirik: nope?
18:01:53 <nirik> pjones: tc's are composed with "TCN" name in them and are not intended to be a RC... I don't think a TC could be moved out as a release.
18:02:13 <adamw> by policy a TC cannot be released, yeah.
18:02:13 <jwb> so stop composing TCs and just start composing RCs
18:02:19 <pjones> nirik: I'm not really seeing how that's inconsistent with my statement.
18:02:23 * nirik thinks we should move this to a 'redesign our release process' meeting.
18:02:27 <pjones> We know it can't be released.  There are release blockers not done yet.
18:02:40 <nirik> jwb: we can as soon as all release blockers are fixed.
18:02:42 <adamw> pjones: well your statement is fine, but i guess i don't understand quite what you were getting at
18:02:50 <adamw> i mean that's a thing that can happen and for that matter has happened before, so yeah.
18:02:51 <nirik> if they are not, it cant ever be a release...
18:03:04 <jwb> nirik, sure
18:03:30 <nirik> anyhow, I think we are drifting off topic here. Concrete proposals on what to do now? today?
18:03:43 <adamw> fwiw, the current blocker list isn't terrible. if we ignored the upgrade question, i would expect that based on the current blocker list, we would be able to be ready for go/no-go in a week.
18:03:44 <pjones> I mean if the point is to have a period of limited change for the benefit of testing, there's no reason we can't have that without marrying it to the idea that the thing we're producing must be "releasable", especially since it obviously won't be.
18:04:32 <limburgher> nirik: One does not drift on waterskis.
18:04:33 <nirik> I'd personally really prefer not to redesign the release process while in that process and behind... if folks want to work on changing it for f19, I'm all for it. ;)
18:05:13 <adamw> pjones: okay. well that's how things are already, so yes. in the past we have certainly produced TCs after freeze, when all blockers weren't fixed.
18:05:20 <notting> less semantics, more realistics. if we do not freeze, we take all approved changes into TCs and later RCs. if we do freeze, we take approved blockers, which are what are keeping us from doing RCs anyway. i'd prefer to just freeze and start playing blocker whack-a-mole and not worry about the rest
18:05:29 <limburgher> Anyone interested in voting on freezing?
18:05:46 <notting> so, i'm +1 to freeze now, stick to schedule
18:05:56 <nirik> so thats +4?
18:05:59 <limburgher> 3.
18:06:07 <nirik> mjg59: were you +1 to freeze now?
18:06:10 <pjones> notting: yeah, I'm just not sure there's a practical way that's different from what we're already doing.
18:06:11 <mitr> Overall I'm -1 to freezing now.  I'm fine with a text-only, running-F17-only fedup for F18 beta and also final, but freezing and waiting an undetermined time to get it working with SELinux and other expected unknown unknowns isn't terribly attractive.
18:06:11 <limburgher> unless I misunderstood mjg59
18:07:08 <jwb> the fact that we're holding release for one component that is being worked on by a single person for the majority of that person's waking hours is the problem.  freezing isn't going to help that, but sure.  if it makes everyone feel better, we can freeze now
18:07:08 <mmaslano> I would be for option b/wait until fedup package is available, freeze then stick to schedule
18:07:43 <mjg59> nirik: Yes
18:08:05 <limburgher> So +4 currently, not counting jwb or mmaslano numerically.
18:08:12 <jwb> i said sure
18:08:17 <jwb> +300
18:08:23 <limburgher> So that's +305
18:08:27 <mjg59> jwb: Freezing now doesn't help fedup, but potentially lets us get everything else stabalised in parallel
18:08:40 <mjg59> Rather than landing that and then finding that everything's broken again
18:08:49 <nirik> right
18:08:53 <mitr> I'd prefer freezing when fedup is "code complete", which may mean complete within the drastically reduced feature set, but with no known potentially-big todos.
18:09:27 <limburgher> Currently 5:+1, 1:-1, 0:0
18:09:32 <jwb> expect a kernel update post-freeze
18:09:37 <jwb> or 2
18:09:45 <adamw> then propose an NTH/blocker.
18:10:23 <nirik> ok, next topic? ;)
18:10:35 <limburgher> I think so.
18:10:39 <limburgher> #agreed Freeze now for Beta, stick to current schedule. (+:5,-:1,0:0)
18:10:48 <limburgher> #topic #932 F18 Features - progress at Features 100% Complete deadline
18:10:54 <limburgher> .fesco 932
18:10:56 <zodbot> limburgher: #932 (F18 Features - progress at Features 100% Complete deadline (was: Feature Freeze)) – FESCo - https://fedorahosted.org/fesco/ticket/932
18:11:53 <nirik> so, drop owncloud/ask them to rescope to just the client?
18:12:24 <limburgher> I'd say.
18:12:30 <nirik> and the 3 at 20%/20%/25% ?
18:13:04 <jwb> and openshift
18:13:23 <limburgher> What about rngd?
18:13:27 <mmaslano> jreznik_: did they respond to your questions?
18:13:37 <mitr> yeah, that is at 95% ever since the time it was approved
18:14:23 <limburgher> notting, where are package groups at?
18:14:44 <notting> limburgher: should be at 100%, is it not?
18:14:55 <jreznik_> limburgher: rngd - jeff was sick, he will take a look
18:14:56 <nirik> so, really everything thats not 100% needs to either: repoint to f19, or rescope on the part that is done...
18:15:08 <jreznik_> nirik: for owncloud, yes
18:15:11 <mitr> proposal: give feature owners time til next Tuesday to reduce scope of their features to get at 100% feature-completeness (AND to update the wiki accordingly, both in percentage status and textual description).  Drop anything that isn't updated.
18:15:24 <nirik> mitr: +1, works for me.
18:15:24 <notting> limburgher: oops, updated scope & percentage, didn't update 'last-updated-date'. doing now.
18:15:56 <notting> mitr: +1. is jreznik_ the nagger and enforcer in this scenario?
18:16:11 <mitr> I'm hoping so. jreznik_, are you willing?
18:16:11 <mmaslano> mitr: +1
18:16:34 <mjg59> +1
18:16:42 <limburgher> +1
18:16:42 <jreznik_> notting, mitr: of course I can, sorry for not having 100% complete list... but you know... I hope most features are covered
18:18:01 <limburgher> I count +6, anyone else?
18:18:29 <limburgher> #agreed Give feature owners time till next Tuesday to reduce scope of their features to get at 100% feature-completeness (AND to update the wiki accordingly, both in percentage status and textual description).  Drop anything that isn't updated. (+:6,-:0,0:0)
18:18:39 <limburgher> #topic #960 F18 schedule + the holidays
18:18:44 <limburgher> .fesco 960
18:18:46 <zodbot> limburgher: #960 (F18 schedule + the holidays) – FESCo - https://fedorahosted.org/fesco/ticket/960
18:18:52 <nirik> I'm really hoping for no more slipping... but yeah...
18:19:28 <adamw> like i said with the time we've had for TCs and the current blocker list i'm fairly hopeful we won't slip for beta if fedup is okay
18:19:31 <adamw> hard to predict final
18:19:47 <nirik> yeah
18:19:55 <jreznik_> for beta, yep - with fedup I think we are able to release
18:20:02 <pjones> I'm vaguely -1 to that proposal on #932, for the record.
18:20:04 <limburgher> I'd sort of like to hear some worst-case scenarios.
18:20:24 <nirik> pjones: oh? counterproposal?
18:20:31 <jwb> limburgher, we ship in feb.  or mar.  or next oct
18:20:54 <nirik> limburgher: we skip f18... go to f19. ;)
18:20:58 <pjones> nirik: I just think it lacks nuance - mostly because my feature will hit 100% when it hits 100% and there's not much I can do about it, and I don't think we're honestly going to drop it next tuesday if it hasn't hit that yet.
18:21:07 <limburgher> I guess I meant ways to avoid those things.
18:21:33 <notting> limburgher: cancel christmas.
18:21:37 <jreznik_> limburgher: worst case, if we miss 2012 then it's hard to predict - but jan 15 as it will take some time to get people from christmas, then fudcon, jan 29?
18:21:44 <nirik> pjones: IMHO, your feature should be 100% now... it's fully testable right? the details about implementation don't matter to that %
18:22:00 <pjones> nirik: fully?  no, if you have windows 8 hardware it won't install by default.
18:22:20 <jwb> i don't see why fudcon week isn't a ship week
18:22:23 <notting> jreznik_: i don't see why jan 15 is the first available date in january. 8th should be practical if we have RCs 1/1
18:22:24 <jwb> someone help me there?
18:22:25 <nirik> pjones: true, but the implementation is all done...
18:22:28 <jreznik_> nirik: actually I agree % are not a good mark to say what state feature is in
18:22:29 <mitr> pjones: The proposal is based on the assumption that we don't discuss the features individually otherwise.  If there is a feature we need to slip for, that should be known to FESCo; if somebody notices that a supposedly 100% feature doesn't actually work, that should be brought up $somewhere as well.
18:22:34 <pjones> the implementation is... *mostly* done.
18:23:14 <jreznik_> notting: if we have rc before, then yes, this is more - we will skip chrismas before
18:23:17 <notting> jwb: it's trickier if people needed to push a button or run a g/ng meeting are mid-air
18:23:35 <notting> jwb: doesn't make it impossible, imo
18:23:55 <jwb> hell, fudcon hackfest: SHIP THE DAMN RELEASE
18:24:04 <limburgher> jwb:  I like that. :)
18:24:07 <jreznik_> notting: yep, it's not impossible, would be logistic problem - in case we would be forced to do it, it would be possible but better not count with it
18:24:17 <jreznik_> jwb: everyone to say GOOOO
18:24:17 <nirik> proposal on this ticket: continue to hope for no slips, if we do, then then reevaluate then. keep ticket open for ideas/etc.
18:24:18 <jwb> i don't think we should just discount it because we'll all be sitting in a room somewhere trying to make fedora better
18:24:55 <nirik> I'm fine with release around fudcon.... not a big deal imho either, but I hope it doesn't come to that
18:25:18 <smooge> jwb, fudcon week is usually not a release week because it means that infrastructure can't go to fudcon.
18:25:49 <jwb> smooge, i don't see why not.  you aren't all sitting in PHX2 during release week.  you work remotely.
18:26:17 <notting> they'll all be congregated during week of final change deadline on current schedule anyway
18:26:31 <nirik> release is on tuesday anyhow, so it's not going to be during fudcon in any case. ;)
18:27:51 <limburgher> So voters on nirik's proposal?
18:28:12 <mmaslano> yeah +1
18:28:18 <jwb> the current proposal is to do nothing at the moment, right?
18:28:38 <limburgher> Basically.  Except hope.
18:28:42 <limburgher> And test.
18:28:44 <nirik> jwb: yeah
18:28:52 <jwb> i'm all for that.  +1
18:28:53 <pjones> nirik: sure, +1
18:28:56 <limburgher> +1
18:28:58 <mitr> Do we actually need a third permanetly-open ticket?
18:29:12 <jwb> moar is bettar
18:29:29 <limburgher> No, combine them into one sentient ticket.
18:29:32 * nirik doesn't much care.
18:29:37 <limburgher> Then assign to itself.
18:29:37 <mitr> +1 if it helps everybody save time, whatever.
18:29:38 <nirik> we could close the beta one?
18:29:50 <nirik> since we agreed to freeze and thats what it was about.
18:29:54 <limburgher> Sure.
18:29:58 <limburgher> Any objections?
18:30:28 <limburgher> OK.
18:30:34 <limburgher> Any more votes.
18:30:36 <limburgher> ?
18:31:12 <nirik> that was +5 I think?
18:31:15 <notting> i guess, with the knowledge there's a good chance we'll need to discuss this anyway soon. important just to make everyone aware.
18:31:16 <limburgher> YEs
18:31:22 <limburgher> #agreed Continue to hope for no slips, if we do, then then reevaluate then. Keep ticket open for ideas/etc. (+:5,-:0,0:0)
18:31:35 <limburgher> #topic Next week's chair
18:31:39 <limburgher> Any takers?
18:31:51 <jreznik_> btw. Board meeting should take a place here now, is this last topic?
18:31:57 * nirik could do it if no one else can...
18:32:07 <limburgher> #info nirik will chair next week
18:32:09 <nirik> but remember to dress up, since it's halloween.
18:32:13 <limburgher> #topic Open Floor
18:32:18 <pjones> jreznik_: we generally have open floor after discussing who's chairing next week.
18:32:22 <limburgher> nirik:  I always dress up.
18:32:37 * nirik has nothing for open floor.
18:32:38 <jreznik_> pjones: we can wait a moment
18:32:44 <limburgher> I'll close in 2 minutes if nothing.
18:34:01 <limburgher> #endmeeting