18:00:48 #startmeeting FESCO (2013-03-13) 18:00:48 Meeting started Wed Mar 13 18:00:48 2013 UTC. The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:55 #meetingname fesco 18:00:55 The meeting name has been set to 'fesco' 18:00:55 #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:00:55 Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:00:55 #topic init process 18:01:06 here 18:01:07 * nirik waves. morning everyone. 18:01:36 hello. 18:01:43 Hello 18:02:30 Hi 18:02:45 I'm here, but I have a hard stop in 45 minutes 18:03:16 hello 18:03:40 that's 7. mmaslano said she wasn't making it. abadger1999? 18:04:11 notting: I'm not really here either 18:04:51 ok then 18:05:12 #topic #1095 Fedora 20 schedule proposal 18:05:29 .fesco 1095 18:05:33 notting: #1095 (Fedora 20 schedule proposal) – FESCo - https://fedorahosted.org/fesco/ticket/1095 18:05:35 * jreznik is around and given the timeframe... 18:05:37 * nirik re-reads the last comment there. 18:06:51 * nirik would be ok with the 2013-11-12 release. 18:07:02 sure 18:07:11 i know end of nov is problematic, but i'm not too keen about pulling it too much further in 18:07:45 well if you factor in slips beginning of nov means end of novv 18:07:49 for a 19.1, or 20.1 I think we need more groundwork... because things like rawhide is building fc20 rpms... would those be confusing in a 19.1 release? 18:07:52 while end means mid dec 18:07:53 notting: I'm also more inclined for the end of november, 11-12 is really the earliest 18:07:55 drago01: yeah 18:08:09 wait, what? 18:08:12 Factoring in slips, end of November probably means early January... 18:08:14 I prefer to have 2 weeks at least in case we slip. (no, we would never do that) 18:08:21 are we seriously discussing .1 releases somehow? 18:08:27 sgallagh, not necessarily 18:08:29 jwb: it was an aside in the ticket. 18:08:29 nirik: x.y is not only about the next releases but about the whole model of stable releases and what we support etc. 18:08:39 nirik, which abadger1999 said wasn't serious 18:08:43 sorry to have dragged it in. 18:09:03 anyhow, I think 11-12 makes sense, as it gives us some room before holidays. 18:09:08 i wouldn't expect us to start discussing .1 until we're well into 20 18:09:17 er, sorry. planning 20 18:09:33 sure 18:10:25 I agree with 11-12, I think we can't go earlier and have enough dev/testing time, but I don't think we can go much later and avoid slipping into the major holidays 18:10:48 * nirik nods 18:10:54 sgallagh: really, earlier is suicide, later is really too close to holidays 18:11:49 so in case of the GA on 11-12 - all other dates are adjusted the same way? 18:12:07 or except the Feature Submission deadline? 18:12:37 sorry Changes proposals deadline now :) 18:12:57 I am, of course, completely against going back to approving a schedule before feature submission. 18:13:04 * jreznik can prepare detailed schedule 18:13:11 t8m: yes 18:13:21 It was a terrible idea before, and it hasn't gotten magically better because we're one release past where it completely broke down. 18:13:28 t8m: or at least that's how I read comment #7 18:13:37 pjones: well, that's even something I did not ask for - but we definitely need something more than "end of the world" 18:14:18 pjones: well, this just means we need to be more strict about saying "sorry, your feature doesn't look like it will fit in f20, use f21' 18:14:19 mitr, t8m: I pushed submission deadline a little bit to try to avoid conflict with F19 GA 18:14:23 I'm open to the option of revisiting the schedule if a change owner asks for it; I'd be very surprised if that happened 18:14:23 pjones: well features can be rejected on the basis "this does not fit the schedule" 18:14:32 pjones: does not have to be the other way around 18:14:39 pjones: At the same time, I'm not really sure that we made much in the way of adjustment this time around based on the features 18:14:40 The main problem with waiting to decide after feature freeze is that all the other teams have no idea what they can schedule 18:14:53 nirik: that was the main problem 18:14:54 mitr, +1 18:14:56 It seems to me that making an exception for "this feature looks like it's going to break our schedule" might be the less-invasive approach 18:14:56 drago01: FESCo is rarely qualified to overrule the change owner's opnion about that 18:15:06 sgallagh, +1 18:15:20 so, can QA know they can work on frameworks? or releng work on tooling? or do they have to go right into the cycle... 18:15:39 would we consider moving it if f19 moves? 18:15:52 notting: we have to consider that 18:16:08 but I hope for less than two months slips... 18:16:13 drago01: no, that's idiotic. 18:16:25 drago01: that's exactly how we got into the problem with f18. we can't continue doing that. 18:16:51 that's literally the most irresponsible thing fesco can do. 18:17:03 pjones: we didn't otherwise fesco would have told the anaconda folks "no way this can be done in 6 months" 18:17:10 we really need some compromise between - to be flexible based on the scope but also provide details to other teams 18:17:17 drago01: no, that's *what the anaconda team told fesco* 18:17:31 drago01: and it didn't get done in six months. It got done in 2 *years*. 18:17:39 uh ok 18:17:47 drago01: if we do what you're saying, features like that one can simply never be done. at all. 18:18:13 sounds good. maybe it will lead to less crap on the devel list because we'll have no users and nobody to email 18:18:24 so we can set this schedule as a draft for now and set also a milestones where we can adjust it based on the feedback... but for nov/dec we don't have much flexibility neither :( 18:18:49 jwb: usr move 2.0 - final one 18:19:05 move all users away, benefit for fedora - no users, no complaints 18:19:10 not usr move 2.0. use re-move 18:19:11 pjones: I still don't understand what would have been your desired alternative - release F16 (or what it was) 2 years after F15? 18:19:15 usr even 18:19:38 (i am not being serious in the slightest) 18:19:40 mitr, +1 18:19:44 mitr: my alternative would be to have figured out how much time it'd take to merge a feature that fedora *desperately wanted* and make a schedule where that would actually have been possible. 18:19:48 jreznik, +1 18:19:57 mitr: instead we approved a schedule that we knew *at the time* the features would not fit in. 18:20:34 and now we're repeating that mistake, except even more so, because we're talking about the freeze dates for F20 without even knowing *at all* what we want in it. 18:20:41 pjones, maybe somebody knew somebody did not 18:20:46 pjones: I'm suggesting we explicitly agree to be open to changing the schedule based on proposed changes and their timelines. Why isn't that good enough? 18:20:56 pjones: the thing is - it does not have to be final schedule - and I'm not asking for, I liked F19 flexibility but also we need a better overview how it will look like 18:21:08 mitr, because it's worse than what we did in f19 18:21:27 jwb: why? 18:21:33 the problem with f19 is the idea of a vague schedule that would be finalized once content was decided broke too many people's brains 18:21:43 in f19 we said "we'll set the schedule after this date XXX". now you want us to say "this is the schedule, but we'll change it later. maybe." 18:21:46 it's not clear 18:21:52 it leads to more confusion 18:21:53 notting: ... and had no benefit because nobody came to us to ask for changing the schedule 18:22:01 and people won't look back to see if it's adjusted 18:22:06 mitr: actually we asked 18:22:20 jwb: Well, I think it's more: "We're setting this schedule, but it may extend longer if features demand it" 18:22:30 mitr: it's fair that we need to provide guidance to people on what we're thinking, so they don't propose things that are completely unreasonable, but that's not the same thing as setting provisional dates and saying "they're flexible". 18:22:31 sgallagh, which is exactly what i said 18:22:45 So this at least allows people to plan for the short term. If they get extra time, how does that hurt anyone? 18:22:56 jwb: and that's exactly what we need - to be flexible 18:23:06 what is inflexible about how we did it in f19? 18:23:12 nothing. it's flexible 18:23:19 mitr: for one thing, in the past all of our dates have been flexible. calling this a "flexible" schedule is doing *exactly* what we've done in the past. 18:23:33 jwb: f19 was flexible, for devels and features, not for other teams 18:23:34 that's exactly the same as the process that completely failed. 18:23:38 jwb: We waited too long to give people any idea of what the end goal would look like. 18:24:00 Up until Feature Submission Freeze and our schedule, most people were still expecting a final release in March/April. 18:24:09 Which pretty much everyone agreed was too short 18:24:24 please, let's not use "goal" for "date" 18:24:33 this is a schedule 18:24:43 sgallagh: so if that's the problem, we should set up a model like F19 and figure out what we need to do to tweak it to help with that. Not revert entirely to the thing that hasn't ever really worked before and completely failed for F18. 18:24:53 pjones: It seems to me that this is just arguing about words that don't matter much - this can be reliably settled in 1-2 release cycles by actual practice. Will change owners ask for schedule changes, and will FESCo take them into account? We'll know whether that happens or not, and by the time the naminng won't matter. 18:24:57 jwb: We can argue semantics if you want, but my point was that QE and rel-eng were completely unprepared 18:25:10 sgallagh: it's not semantics. 18:25:15 if other teams need an end date to work towards, why can't they set that date at 6mo and work towards it? 18:25:17 pjones: we are not reverting 18:25:22 jreznik: bullshit. 18:25:27 jreznik: that's *exactly* what we're doing. 18:25:34 pjones: I thought that's what I was doing. "Here's the schedule we want, but it may go later (NOT EARLIER) if the Features look like they won't fit" 18:25:37 pjones: no, that's not what I'm asking for 18:25:43 and these bullshit words help how? 18:25:44 I fail to see how that's anything but a compromise. 18:25:55 jwb: Doesn't that effecitvely make the other teams the decision makers on the schedule? 18:25:57 mitr: I don't agree at all. If we say "this is the schedule, but it's flexible and it may change", that's the same process we had for e.g. F17, except now we're using the word flexible to mean "we decided something with no merit." 18:26:01 sgallagh: exactly 18:26:06 mitr, no it gives them a date to work towards 18:26:26 * jreznik is even ok with setting submission deadline and call the rest of schedule draft, even provide less detailed one after it 18:26:33 jwb: yes, a date that is either incorrect or constrains FESCo 18:26:52 mitr, i fail to see how it being incorrect is a problem. they're early if we slip it out 18:27:08 because honestly, we aren't going to come up with a schedule that ships before 6mo 18:27:46 * nirik can't see a shorter schedule either. 18:28:24 so would people prefer a proposal that cribs these dates with a fixed feature submisson deadline and the rest dates are phrased as "no earlier than..."? 18:28:44 notting: Since that's basically the exact thing I've been saying: +1 18:28:59 notting, +1 18:29:03 i'd rather it just say TBD 18:29:05 notting: that would be /better/, but I don't see it as avoiding the fundamental fallacy. 18:29:11 as I said - let's do compromise - set all dates pre-submission deadline with submission deadline, the rest lest detailed overview but with a goal we'd like to go (because of holidays etc.) 18:29:12 and that gets removed after feature submission deadline? 18:29:39 jwb: but then that doesn't help QA much. 18:29:45 pjones: well, it's nearly the same we did for F19... 18:29:49 just with more details 18:29:52 notting: I wouldn't mind a stronger wording ("aiming for" or something) but it's a compromise I can live with 18:29:55 nirik: then QA needs to be involved in deciding which features get approved. 18:29:59 nirik, why not? 18:30:11 nirik: the problem you're describing is that QA's role is after-the-fact. 18:30:25 I don't think they want to. They want to know if they can work on infrastructure/framework work, or should immediately setup test plans and get ready to test. 18:30:32 pjones: No, the problem he's trying to describe is that QA scoping is dependent on a schedule. 18:30:36 nirik: exactly 18:30:38 they want to know how soon the later milestones are. 18:30:41 HOW? 18:30:41 and not only QA 18:30:51 Plus, if you give adamw the final say on the schedule, he'll add five months after beta :) 18:30:52 people keep saying this impacts QA and other teams. please explain how 18:30:53 sgallagh: no, that's a completely broken model 18:31:04 QA's scoping is dependent on what we put in the release. full stop. 18:31:05 tflink: you around? or adamw ? 18:31:10 sure it is. 18:31:15 yo 18:31:23 what's the debate? 18:31:37 adamw, if we don't give you any dates for a release schedule except feature submission deadline, how much does that impact QA? 18:31:39 adamw: Please describe how our F19 scheduling affected Fedora QA 18:31:49 with the premise that the schedule is set after the content is know 18:31:50 n 18:31:50 jwb: rather a lot. 18:31:53 HOW 18:31:55 jwb: not how much. how. 18:32:00 we need to know details 18:32:09 pjones, yes, sorry. HOW 18:32:09 sheesh. calm down. 18:32:19 give him a second. sheesh 18:32:28 pjones: jwb: my understanding is that QA takes the pre-beta time to determine how much work can be put into infrastructure. rel-eng, too. 18:32:39 well tflink might have an opinion too, but the way I see it is that QA kinda splits things into two phases 18:32:41 right, as notting say 18:32:41 s 18:32:49 we have the Quiet, Between Releases Phase 18:32:55 and the Crazy Release Validation Phase 18:33:03 i don't think that quiet phase actually exists 18:33:06 during the quiet time before we start the blocker treadmill, we work on our tools and processes and so on 18:33:07 but keep going 18:33:11 jwb: sure it does, we've been in it for two months. 18:33:29 no, development has been going on for 2 months. you just aren't testing it 18:33:31 notting: and that's fine, but I don't see how there's any way that a QA schedule that doesn't have what we're putting into the distro as an input can yield a result where we've set them up to do a good job. 18:33:31 writing the blocker submission page, revising the FreezeException process, revising the criteria, all that stuff. 18:33:51 we need to know ahead of time how long we have to do that stuff because we have to schedule _that_ stuff. if we don't know when Alpha is going to come, it's a problem. 18:34:06 notting: it's fine that they need to know how long they've got, but it's a false economy to think that's more important than having /correct/ dates for them. 18:34:12 jwb: that seems needlessly confrontational, and I'm not going to rise to it. 18:34:35 pjones: wouldn't you agree that "not before X" is better than "TBA" for that purpose? 18:34:35 adamw, i'm not saying you should be, or even can be. i'm just saying quiet time in the distro does not exist 18:34:42 pjones: sure, a date is useless if it's notional. 18:34:44 nirik: I don't see how, no. 18:34:56 jwb: it's not quiet time but more get ready time 18:34:57 pjones: I still think that knowing their "minimum" available time is more important than their exact time. 18:34:58 jwb: i said that's how it looks to QA, not necessarily how it looks to anyone else. 18:35:11 pjones: QA coverage in general is fairly limited. The attention anaconda got for F18 is completely disproportional to how other features were or can be covered. 18:35:11 sgallagh: yep 18:35:14 jwb: it's 'quiet' in the sense that we do not need to build and test a candidate build every two days. 18:35:18 well, "not before X" to me means "I can plan on X, and if I get more, great", but "TBD" means... I have no idea what I can do 18:35:46 nirik: That's the point I have been attempting to make, yes. 18:35:55 jwb: hm. i'd argue that quiet time does exist for things like rel-eng composition tools. how much we use that time... 18:36:18 nirik, +1 18:36:29 notting, rel-eng isn't tasked with testing the content going into fedora. 18:36:59 jwb: but the tooling has to be ready for alpha 18:37:00 jwb, and QA currently either during their "quiet" or better said "preparational" phase 18:37:14 nirik: but fundamentally it doesn't answer the question of "can we do QA for X features in Y time" (or its solve-for-Y variety) 18:37:23 jwb: yes, but i can see a future where they may need more or less time to finish 'rewrite the entirety of pungi, mash, createrepo, and yum'. of course, that would be a Feature 18:37:25 pjones: sure, thats a completely different question. 18:37:39 pjones, but we don't do QA for features (not all of them) 18:37:49 adamw, so basically, QA is impacted because they don't have the human resources to both test the content going into fedora continuously, and do infrastructure and process improvements. is that a summary of the problem? 18:37:53 pjones: as mitr said, in practice QA coverage is very limited. we probably don't look at 80% of features for a release in any kind of planned way. 18:38:06 pjones: The "QA" for features is usually sponsored by the Feature in the form of the Test Days 18:38:25 notting, feature. goes in with feature planning process. 18:38:25 adamw: right, but the determination of which ones you look at must depend on what the features are, yes? 18:38:38 I believe QA's goal is only to verify release criteria. 18:38:47 jwb: Well pre-"features testable" there isn't even much point in testing unless something special is agreed on between QA and the change owner 18:38:58 and some features may impact those critera a lot, others not so much. yes. 18:39:01 jwb: it's...kinda not really a good one, no. I'd rather say "QA doesn't have the human resources to both do ongoing release validation and do infrastructure and process improvements". insofar as we do ongoing testing of 'content going into the distribution', that happens in quiet time too. the difference between the two is whether we're doing release validation testing or not. 18:39:14 pjones: yes. 18:39:22 sgallagh: right. some features factor in to release criteria more than others. 18:39:35 adamw, ok, fair. 18:39:37 pjones: Certainly, I'm not arguing that at all. 18:39:58 mitr, i disagree. you can always test to make sure things are breaking other things. 18:39:59 sgallagh: the result is that if we don't know what the features are, they can't know which features they need to test, and thus predictions of how much testing is needed are of very limited utility. 18:40:13 jwb: to answer the 'is it a problem' question - well, yeah, but no more so than all kinds of other problems. everyone deals with human resource issues in some way. we could use 10,000 full time testers, if we had them. 18:40:14 pjones: I'm saying that we should define a schedule assuming that QA has "this much" time to do release validation, and if at Submission Freeze we discover a potentially world-breaking Feature, we give them more time. 18:40:21 jwb, you can if you have resources to do that 18:40:37 t8m, hence my statement of the problem. which is lack of people. 18:40:43 sgallagh: right. That's the F14, F15, F16, F17, and F18 model. that's it *exactly*. 18:41:06 sgallagh, i'm also not seeing how that differs from f18 18:41:18 pjones: and also F19 one 18:41:18 pjones: No, it's not. The F18 model was "we'll slip at the end". 18:41:23 sgallagh, +1 18:41:26 (not meant to be an exclusive list) 18:41:28 jwb: and it's not just a human resource issue - there's a strong feeling that we shouldn't poke the release validation process too much while we're using it. it wouldn't make sense to do, say, the NTH -> FE change halfway between Alpha and Beta. 18:41:31 sgallagh, slips always happen at the end 18:41:33 This is "We'll adjust the schedule near the beginning if we can see that it might need it" 18:41:41 jreznik: in F19 we at least tried to figure out how much was going in and what it was before we decided how long it should take. 18:41:54 adamw, it wouldn't make sense to change it, but you could certainly work on it 18:41:59 pjones: and we can do the same for F20, I don't see a problem with that 18:42:07 well, additionally this is also "we will only expand/increase after feature submission deadline" 18:42:07 (and I expect we would have to do it) 18:42:07 If someone comes in and says F19 will have Wayland, for example, I'd recommend adding a week or two to the schedule, for example. 18:42:11 exactly, F18 was gradually slipping instead of saying at one long slippage after discovering that anaconda will need "that" much time to be finalized 18:42:12 I'd recommend that right up front. 18:42:25 jreznik: I'm not saying it was perfect, I'm saying I strongly object to going back to a model where we don't even try to factor in the biggest single contributor to the schedule. 18:42:32 * sgallagh checks to make sure that's not currently proposed... 18:42:49 * notting dings the ~45 minute bell 18:42:59 pjones: That's why I'm saying we can STILL move the schedule out at Submission Freeze. 18:43:03 Instead of slow-slipping. 18:43:16 jwb: true. the system we use is not inevitable, if that's what you're driving at. 18:43:23 sgallagh: I find telling people "the schedule is this", even with caveats that it might change, when we don't know what we want in the release, o be incredibly irresponsible. 18:43:26 And now I have to leave to collect my daughter. I'll read the scrollback later. 18:43:31 pjones: this is not doing that. This is setting up a 'minimal' schedule for teams to use in early planning... which we man only _increase_ later. 18:43:35 sgallagh: just abjectly refusing to do our job, really. 18:43:43 adamw, i'm just trying to understand the problem. 18:43:46 nirik: +1 18:44:07 nirik: I know that's what you're trying to do, but I don't think that's the message it sends. 18:44:38 is there a way we could send the right message and still allow other teams early planning dates? 18:44:42 pjones: So can we talk separately about the technical content of the decision, and about the messaging? (I'll be quite happy to leave the second part to you if you are interested) 18:45:00 nirik: I don't think so - the early planning dates you're talking about are a fiction we've made up from whole cloth. 18:45:14 pjones: well even saying "the end May" everyone understood as it's the release day and without it, we would be even more screwer (as you can't plan feature if you don't know how much time do you get) 18:45:31 so we always need a timeframe (the minimum) we expect to give devels 18:45:32 why is there a "start planning" date? 18:45:35 Well, not completely made up... they are based on us wanted to broadly head back to 6months and avoid work in the holidays. 18:45:39 jreznik: yes, but there's real utility in *not* giving dates. 18:45:57 jwb: tool limitations? 18:45:59 jreznik: the point of not giving dates is to ensure the appearance of not having decisions made. 18:46:00 pjones, to confuse people? 18:46:05 notting, what? 18:46:06 jwb: I suppose "change process is stable/redefined and we are now able to accept proposals" 18:46:07 jwb: yeah, that should be removed. ;) 18:46:10 jwb: TaskJuggle, I need a task to start with 18:46:19 jreznik, that doesn't mean you tell people about it 18:46:21 jwb: why there's a start date. limitation of the tools. 18:46:21 t8m: you could phrase it that way, but you run the danger of me thinking you're trying to sabotage legitimate discussion. 18:46:27 no 18:46:34 if your tool needs a date, put it as today 18:46:47 pjones, I am willing to take that thinking of yours as I get the same of yours 18:47:01 there is 0 excuse for people to look at a schedule and say "oh, i start planning for f20 in may" 18:47:12 especially if it's because of a damn tooling limitation 18:47:20 so don't even list that 18:47:31 pjones: it's all about communication... and it's hard to communicate internal dates in open project... we have to live with that 18:47:49 so, where are we here? 47min and no decision... punt to next week and discuss on list/ticket? vote on something? 18:47:55 jreznik: that's certainly true. but the question is: why do we want internal dates that we don't think mean anything? 18:48:19 pjones: I think they do mean something. They mean "at least this date, no earlier" 18:48:20 pjones: not mean anything but gives us at least some overview... I don't want more 18:48:27 nirik: yep 18:48:36 pjones: They do mean something to me, even if tentative 18:48:59 nirik: yeah, I still think vague guidance is actually more useful. 18:49:12 for our purposes, 'not before' dates work absolutely fine (someone mentioned this above) 18:49:25 jwb: that's another discussion and I can get rid of that, especially when we agreed to start next releases as early as possible and to start planning and sharing ideas asap... I'm not happy with that milestone neither 18:50:01 jreznik, good. and we've now made a small amount of progress. 18:50:11 adamw: would "not less than X weeks" be more or less useful (or the same)? 18:50:34 pjones: vague as in? feature submission is X, after that, well... 18:51:27 so the improvement will be that people will have to look up the earliest dates in calendar as we will give them just not less than x weeks after ... values? 18:51:39 nirik: as in "when we set the schedule, we're not going to allocate less than 5 weeks between proposal submissions and change freeze" 18:51:57 jwb: if you have more input, I'll be more than happy - doing schedule clean up, I've removed a lot of stuff, to make it usable tool for everyone 18:52:06 t8m: no, the improvement will be that we're not giving them a way to think "oh we're slipping this" when we actually haven't made a decision 18:52:24 t8m: when we tell people precise dates, we're making decisions and communicating them, whether we're trying to do that or not 18:52:26 jreznik, i just realized it was there a few min ago. glad we could get it resolved so quickly 18:52:29 pjones: that seems more anoying to me than providing approx dates for the milestones. 18:52:35 nirik, +1 18:52:44 pjones: would 'release mid 2012-11' be better? 18:52:53 or I guess not. 18:52:54 nirik: yeah, that'd be better. 18:52:55 * nirik ponders 18:53:01 er. 18:53:12 Actually now I'm not sure what you've said. 18:53:16 2012-11? 18:53:19 heh. :) sorry. 18:53:25 2013-11 18:53:28 Oh, you're saying november. 18:53:34 eh, somewhat better. 18:54:00 but somewhat worse for people wanting to plan time before say the alpha release. 18:54:05 so is there a proposal on the table? 18:54:21 mid 2013-11, so I can create a draft with mid Nov - so for example that Nov 12, or Nov 19 and say it's draft... I can't do mid something in TaskJuggler and provide it to teams... sorry 18:54:23 proposal: punt this week, discuss more and see if we can come up with a consensus 18:54:32 nirik: being honest to people about how much we actually know about f20 at this point will seem worse to them than being dishonest, yes. 18:54:33 pjones: sorry, went to the kitchen. I guess it'd be about as useful. 18:54:34 * mitr is tired with this... 18:54:42 and manually doing fuzzy schedules, sorry... 18:55:19 Proposal: approve schedule aiming as 2013011-12, with explicit dates, and start the announcement with "will be adjusted based on changes submitted by deadline". 18:55:28 pjones: well, really all I would be telling them is: "I want to try and get back to 6 mo cycles, and I want to avoid the holidays", but it's hard to do that and make them figure out milestones based on that themselves. 18:55:33 so for me the date is important only for the reason my tool is not a fuzzy tool... but I can easily say - after this milestone, it's a draft 18:55:35 IMHO that's Good Enough(tm) and I'm not looking forward to another 60 minutes next week 18:55:35 s/adjusted/adjusted out/? 18:56:06 mitr: thanks 18:56:08 notting: sure, yes 18:56:25 mitr, +1 18:56:25 Proposal: approve schedule aiming as 2013011-12, with explicit dates, and start the announcement with "will be adjusted out based on changes submitted by deadline". 18:56:25 mitr: obviously I'm -1 to staying with the status quo. 18:56:39 mitr, +1 18:56:44 I would support that I guess, but I would prefer any schedule pages to say "no earlier than" to note that it's not yet set. 18:57:10 nirik, and +1 to that 18:57:44 pjones: well, returning to the old way I'd say... since we didn't do that for f19... ;) 18:57:45 nirik: I can do that on wiki, not sure about TJ, but will try 18:58:25 nirik: sure. that's nomenclature - I think F19 can be different without changing what the status quo really is. either way, I find this proposal to be incredibly disappointing. 18:58:51 sorry to hear it. :( 18:59:02 I'm not okay with doing what we did in F17 and F18 simply because we haven't anticipated any features like those in F18. That's why I voted against the F17 and F18 schedules as well, and why I said so at the time. 19:00:05 we definitely do not want to repeat F17, F19 19:00:08 sorry F18 19:00:21 well, we may not want to repeat f19. we'll see about that . 19:00:39 I see your point, but not having a schedule at all until after feature submission deadline does negatively impact some folks. ;( 19:01:14 nirik: but making it before then is just creating a fiction for their "benefit" - without providing the benefit they think they're getting. 19:01:19 More votes - on the proposal, or votes to defer? 19:01:34 Let's not do another round of the same arguments please 19:01:35 I think the benift is that they can plan for that minimal worst case... 19:01:47 nirik: well, we had some sort of shedule even for F19 - end of Feb, end of May... I just can't use the tool to create it this way 19:01:48 s/worst/best/ whatever 19:01:50 nirik: that's best, not worst. 19:02:05 pjones: the number of pepole who cannot schedule or propose without target dates is very high. and for *large* features, they'd ideally want targets out multiple releases in advance so they can apportion their work appropriately.(in an ideal world) 19:02:11 and I'm not saying I have to share a detailed schedule for every task, just it makes my life happier 19:02:11 the result is that they will plan for it, which means if it isn't the best case, we've put them in a pinch. 19:02:12 * nirik stops. I was +1 as long as we could make it clear that it's not earlier than 19:02:32 pjones: by allowing them more time? 19:02:55 nirik: I wouldn't call what we did in f18 "allowing QA more time", really... 19:03:12 so we're at +2 -1 19:03:25 jreznik: I'm sorry you're stuck with tools that make this difficult, but that really shouldn't be our deciding factor. 19:03:34 pjones: in that case we didn't finalize/adjust the schedule after feature freeze. 19:03:56 notting: I'm +1 to my proposal for the record 19:03:58 pjones: problem with F18 was - even we knew there's an ongoing problem, we tried to pretend it's not there... I don't think anyone wants to repeat it 19:04:17 jreznik: no, that was the *result* of the bad decision. 19:04:23 (well, of 2 bad decisions) 19:04:47 jreznik: the problem was that we knew we had features coming that did not fit on the schedule, and we approved the schedule anyway. 19:05:02 jreznik: At the same time, IIRC we never had enough information to make a better decision. Slipping into January was just inconcievable in October with what we knew then. 19:05:31 we are not making progress any longer. 19:05:32 mitr: we didn't know the anaconda rewrite was going to land in F18? We certainly did know that. 19:05:35 pjones: as mitr says, nobody knew but once we knew, we said - we don't care 19:05:54 jreznik: and that's pure fiction. we discussed it many times, not least when the plan was to merge it in F17. 19:05:56 i can be +1 because i don't think there is a good alternative for now, and messaging it as 'no earlier than, to be finalzed later' is a good first compromise 19:05:56 pjones: we knew it, we did not have details ala fedup 19:06:07 so that's +4, -1, 3 not here. jwb? 19:06:18 0 19:06:38 pjones: if we knew about fedup not being ready, even not started, we could react... same for live images for alpha 19:06:52 pjones: I was always told that the 2 months necessary to merge back into mainline and get rawhide working were unplanned for. 19:06:55 well then. i guess that's an implicit tabling for next week with more quorum 19:07:11 jreznik: everybody who looked at the plan, including everybody who voted for allowing it as a feature, had a chance to say "hey, I don't think the plan for upgrades has been thought through or explained well enough". 19:07:27 #info motion to ratify proto-schedule did not pass 19:07:27 notting: yep. 19:07:30 jreznik: I'm sorry that FESCo did a bad job, but I'd prefer we not pretend that was some other body's fault. 19:07:32 moving on... 19:08:01 #topic #1096 Rawhide Rebase to Fedora 19 in Bugzilla 19:08:04 .fesco 1096 19:08:07 notting: #1096 (Rawhide Rebase to Fedora 19 in Bugzilla) – FESCo - https://fedorahosted.org/fesco/ticket/1096 19:08:17 +1 19:08:17 notting, how did it not pass? 19:08:18 pjones: I took a place in that too 19:08:47 jwb: +4, -1, 1 not voting, 2 absent. 19:08:56 jwb: needs 5 to pass. 19:09:01 who were the 4? 19:09:10 notting, nirik, t8m, mitr? 19:09:12 notting, t8m, mitr, nirik. 19:09:30 oh, sgallagh wasn't actually here to vote. ok. pretty sure he would have been +1, but sure 19:09:41 anyway, moving on. 19:09:43 so, we haven't done this rebase, but I think it makes sense, so I am +1 to doing it now and ongoing. 19:09:53 nirik: likewise. 19:09:57 yes, +1 19:10:12 i'm not against it. although it's just more bugspam noise 19:10:15 nirik, perhaps with the exception of something marked FutureFeature in the keyword? 19:10:21 jwb: shouldn't we ask marcela and sgallagh to vote in the ticket? otherwise we are blocked 19:10:27 of course since we haven't done it we have a bunch of old f17/f18 whatever ones... do we want to do anything with them? or just ignore them until maintainers deal with them? 19:10:30 jreznik, yes 19:10:34 jreznik: it defaults to punt to next week 19:10:44 jreznik: although if you want to do that, plz update with the final proposal 19:10:47 jwb: it does exclude that I think. 19:10:48 jreznik: we shouldn't ask people to vote on this without being part of the discussion 19:10:50 nirik, great 19:10:51 * nirik checks the query 19:11:00 so, i'm +1 19:11:08 query contains FutureFeature 19:11:10 pjones, i don't honestly think we're going to make any further progress next week. they can read the log and vote in the ticket. 19:11:19 yeah, https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19#Bug_Selection_Criteria 19:11:20 that's 5... 19:11:50 jreznik: are you going to do this rebase? or is it something we ask bugzilla people to do ? 19:12:07 nirik: I don't think we can now distinguish rawhide bugs that should be f17/f18 easily enough, so just let them be assigned to f19 19:12:14 #agreed rebasing of rawhide bugs to f19 (and later releases for each subsequent release) is approved (+:5, -:0, 0:0) 19:12:18 nirik: I can take a look if I can do it with my EOL script, otherwise I'd have to ask BZ guys 19:13:06 #topic #1094 tomcat6 deprecation (fasttrack) 19:13:09 .fesco 1094 19:13:12 notting: #1094 (tomcat6 deprecation (fasttrack)) – FESCo - https://fedorahosted.org/fesco/ticket/1094 19:13:14 jreznik: ok, happy to help out if you like. I'd like to know more about that process so we don't have no one doing it. ;) 19:13:43 nirik: I'm trying to document it, scripts are now in public git... 19:13:45 so, on this one last comment suggests we wait a week. I'm +1 on that. 19:14:23 +1 to wait a week 19:14:28 AFAICS this is actually only 1 week into the "unresponsive maintainer" process 19:15:20 I'm not too enthusiastic about bypassing it (if we wanted to change it to account for security fixes, that would be fine) 19:15:21 mitr: yeah, they suggested this was security sensitive and more urgent. 19:15:35 Anyway, +1 to wait a week and revisit 19:15:56 yeah, +1 to that. 19:15:59 i can go with that +1 19:16:04 +1 19:16:29 #agreed wait one week and revisit (+:6, -:0, 0:0) 19:16:45 #topic #1098 F19 Features - Progress on Feature Freeze 19:16:47 .fesco 1098 19:16:49 notting: #1098 (F19 Features - Progress on Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1098 19:18:09 I think gnome is further along... just hasn't updated. 19:18:36 nirik: needs update, so I should put it to the second cat 19:18:55 for QXL/Spice Alon was sick, he's going to provide update soon 19:19:22 usermode migration is still stalled due to lack of manpower 19:20:05 I'm "concerned" about GNOME and GCC - but both seem to be unlikely to be a risk at this time (GNOME schedule has enough slack for us, and GCC mass rebuild has happened). 19:20:07 Is QA concerned about any of the features not being testable? 19:21:32 * nirik has asked mclasen to update the gnome one. 19:22:38 adamw: ? 19:22:52 i'm fine with the proposal to drop the features at the bottom in 1 week 19:23:02 not % wise, but I am a bit concerned about mariadb/mysql... hopefully its getting sorted, but it seems not fully set right yet. 19:23:41 I'm fine too revisiting next week and dropping any that don't update by then in the bottom list. 19:24:01 nirik, some of them were updated yesterday 19:24:05 like the anaconda ones 19:24:09 nirik: yes. I'm kind of thinking that we might just want to bite the bullet and /Requires/s/mysql/mariadb/ everywhere instead of playing with Provides 19:24:22 jwb: oh indeed so. 19:24:22 jwb: it's today's list 19:24:43 the last one are with recent updates 19:24:44 I'm also fine with dropping the non-updated ones; jreznik: please make this consequence clear when asking for updates 19:24:52 jreznik, what do you mean it's today's list? 19:25:13 jwb: the list was generated today 19:25:19 proposal: keep asking for updates, revisit next week which ones we wish to drop ? 19:25:27 nirik: +1 19:25:42 jreznik, right. and you suggest dropping the features at the bottom in one week if they aren't updated 19:25:43 some of the ones in the bottom list I think we should keep actually... 19:25:46 nirik: well I'd limit to the "no recent updates" category only 19:25:52 the % is not a very good indicator 19:25:56 jwb: no, the top category 19:26:02 ah 19:26:06 i misunderstood 19:26:19 yeah, I got confused too. sorry. 19:26:21 nirik: that's why I asked for "status" update and best effort estimate in % 19:26:30 nirik, jwb: sorry 19:26:34 for confusion 19:26:45 so the list on the bottom is just "FYI, this is where they are"? 19:26:57 jwb: yep 19:27:09 well... freeze was yesterday, right? 19:27:39 yes 19:28:10 so anything in the bottom list that is of a low percentage technically isn't complete by feature freeze, right? 19:28:31 it needs to be 'testable' right? 19:28:42 nirik, +1 19:28:46 to my understanding, yes 19:28:48 nirik: yes, some are for some reason not in testable state 19:28:58 then i think those go in the top list 19:29:10 for example Anaconda Realm Integration depends on Anaconda being testable 19:29:37 ok. let's make this easier 19:29:53 https://fedoraproject.org/wiki/Feature_Freeze_Policy 19:29:57 and for the self contained features I'd take it more as "soft deadline" with provided info how to proceed to make 100% deadline 19:29:57 jreznik: I assume you noticed that I took https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall out (because the pre-requisites listed aren't going to be fulfilled soon enough and I *also* haven't spent enough time working on it.) 19:30:03 proposal: send an email to all the features on this page saying that have 1 week to get their feature testable and their page updated. vote next week on what to drop 19:30:09 substantially complete and in a testable state - enabled by default -- if so specified by the feature 19:30:13 jreznik: ... to be resurrected at a later release when I've got more confidence I can follow through 19:30:16 pjones: yes, I saw it 19:30:35 jwb: +1 19:30:53 jwb: +1 19:31:17 * jreznik is not sure it makes sense for all features - the result will be bumping percentage to 80% and we don't have a way how to assure it's true 19:31:21 jwb: +1, though that's a bit more scary than it needs to be for many features 19:31:34 why? 19:32:02 we just argued for 45 mintues about how dates are important for planning, and now we're saying the dates taht have been set aren't important? 19:32:05 jwb: +1 19:32:09 jwb, +1 19:32:13 * nirik nods. 19:33:09 jwb: well I'm definitely in favour of that for non-responsible maintainers, for the rest, I'd say - case by case... system wide feature not really testable - problem, self contained one? with a plan? that's question 19:33:11 jwb: There is a class of self-contained features where we don't care that much whether they are tested in Alpha (testing in Beta would be fine); I don't think anybody benefits setting the system up to motivate owners of such features to misrepresent status 19:33:25 but I'm ok with any decision and I'll proceed with it 19:33:43 mitr: that's my concern... 19:33:51 jwb: But I can go with "the schedule is strict and works for everyone" as well 19:33:57 no no no no. we have dates for calling things Features. if they aren't ready by that date, they aren't features. they can still go into the distro 19:34:38 btw. we were arguing not about dates but about being flexible... but I'm ok with any FESCo decision and I'll communicate it to Feature owners 19:34:50 they are mostly ok with that 19:35:07 they can repropose it later as an exception 19:35:18 i cannot wait until we stop calling these things features 19:35:23 jwb: OK. In the new process this should be different anyway, because marketing features will be decided independently from the list of coordinated Changes. 19:35:30 yes 19:35:44 but we aren't using the new process, so i'm content to go out with a bang and be a hardass 19:36:03 mitr: actually we decided we don't want to do it in the new process 19:36:03 * mitr counts 6? +1s 19:36:22 jreznik, er.. do what? 19:36:23 it was in proposal but we did not agreed on that, we can still tweak it 19:36:25 mitr: counting you, yes 19:36:33 jwb: fair enough, for old process, old rules 19:37:00 #agreed send e-mail to all the feature owners on this ticket saying that they have 1 week to get their feature testable and their page updated. vote next week on what to drop (+:6, -:0, 0:0) 19:37:08 jreznik: you're on the hook for sending said mail? 19:37:11 jwb: it was in proposal that for self contained changes we would like to use different deadlines and at fudcon we agreed not to do that 19:37:21 oh, that. ok, sure 19:37:21 notting: yes 19:38:10 jreznik: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process still contains it, and was accepted per 2013-02-13 19:38:11 for making the process working, I'm trying to get docs/marketing on board, docs guys seems to be ok with the change 19:38:50 mooooving on... 19:38:50 mitr: Self contained changes follows the same schedule for the Change Submission deadline as complex changes 19:39:00 #topic Next Week's Chair 19:39:01 jreznik: Oh, that part. right. 19:39:15 jreznik: and either way, it still isn't the process we're actually using. 19:39:18 mitr: it was changed... 19:39:27 pjones: I agree 19:41:44 I guess I could do chair next week if no one else can. 19:42:33 are we doing 2pm EDT again next week? 19:42:44 hi 19:43:00 #info nirik will chair next week 19:43:14 do people want to move to 1PM EDT and be an hour earlier in .cz for 2 more weeks? 19:43:48 * nirik would prefer just sticking with utc year round. 19:44:26 nirik, either that or move after the next 2 weeks 19:44:58 I hate timezones. 19:45:16 notting: 1 hour earlier would be a little more convenient, but not worth the extra confusion when this is 2 weeks only 19:46:11 notting: actually I'd rather 2pm EDT next week anyway, which is why I'm asking. 19:46:33 because I've got another meeting at 12:30 that's supposed to go to 1, but experience tells me will start at one and go to 2. 19:47:44 I suppose, if we agree to move it in 2 weeks to keep the local time same as it used to be in winter (do we?), it's up to the US members for the 2 weeks. 19:47:56 ok, i'm fine with not changing 19:48:58 #topic Open Floor 19:49:00 talking about time in any other timezone than UTC makes no sense in an international collaboration 19:49:40 If anyone cares, I put my revamped Rawhide page in place on the wiki, feedback welcome. 19:50:58 nirik: url? 19:51:12 https://fedoraproject.org/wiki/Releases/Rawhide 19:51:27 I'm going to revamp the Branched one too the same way, it's also dire. 19:51:49 oh, revamped rawhide page, not page for revamping rawhide 19:52:05 notting: sorry, I went on to other stuff. belated reply, um, we don't have any specific concerns atm, but I really need to take a look at the latest anaconda builds. GNOME doesn't look like a problem to me, I'm running it here and progress seems like any GNOME release. 19:52:36 adamw: cool, thx 19:53:04 #info rawhide pages on the wiki at https://fedoraproject.org/wiki/Releases/Rawhide have been updated - please send feedback to nirik 19:53:16 anything else for open floor? if not, will close in 2 minutesd 19:55:30 thanks all 19:55:33 #endmeeting