===================================
#fedora-meeting: FESCO (2013-03-13)
===================================
Meeting started by notting at 18:00:48 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-03-13/fesco.2013-03-13-18.00.log.html
.
Meeting summary
---------------
* init process (notting, 18:00:55)
* #1095 Fedora 20 schedule proposal (notting, 18:05:12)
* motion to ratify proto-schedule did not pass (notting, 19:07:27)
* #1096 Rawhide Rebase to Fedora 19 in Bugzilla (notting, 19:08:01)
* AGREED: rebasing of rawhide bugs to f19 (and later releases for each
subsequent release) is approved (+:5, -:0, 0:0) (notting, 19:12:14)
* #1094 tomcat6 deprecation (fasttrack) (notting, 19:13:06)
* AGREED: wait one week and revisit (+:6, -:0, 0:0) (notting,
19:16:29)
* #1098 F19 Features - Progress on Feature Freeze (notting,
19:16:45)
* LINK: https://fedoraproject.org/wiki/Feature_Freeze_Policy (nirik,
19:29:53)
* 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) (notting,
19:37:00)
* Next Week's Chair (notting, 19:39:00)
* nirik will chair next week (notting, 19:43:00)
* Open Floor (notting, 19:48:58)
* LINK: https://fedoraproject.org/wiki/Releases/Rawhide (nirik,
19:51:12)
* rawhide pages on the wiki at
https://fedoraproject.org/wiki/Releases/Rawhide have been updated -
please send feedback to nirik (notting, 19:53:04)
Meeting ended at 19:55:33 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jwb (93)
* jreznik (92)
* pjones (87)
* nirik (82)
* notting (62)
* mitr (45)
* sgallagh (32)
* t8m (29)
* adamw (26)
* zodbot (8)
* drago01 (6)
* netSys (1)
* abadger1999 (1)
* NeatBasis (1)
* mmaslano (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
18:00:48 <notting> #startmeeting FESCO (2013-03-13)
18:00:48 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:55 <notting> #meetingname fesco
18:00:55 <zodbot> The meeting name has been set to 'fesco'
18:00:55 <notting> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
18:00:55 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:00:55 <notting> #topic init process
18:01:06 <jwb> here
18:01:07 * nirik waves. morning everyone.
18:01:36 <pjones> hello.
18:01:43 <mitr> Hello
18:02:30 <sgallagh> Hi
18:02:45 <sgallagh> I'm here, but I have a hard stop in 45 minutes
18:03:16 <t8m> hello
18:03:40 <notting> that's 7. mmaslano said she wasn't making it. abadger1999?
18:04:11 <abadger1999> notting: I'm not really here either
18:04:51 <notting> ok then
18:05:12 <notting> #topic #1095 Fedora 20 schedule proposal
18:05:29 <notting> .fesco 1095
18:05:33 <zodbot> 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 <jwb> sure
18:07:11 <notting> i know end of nov is problematic, but i'm not too keen about pulling it too much further in
18:07:45 <drago01> well if you factor in slips beginning of nov means end of novv
18:07:49 <nirik> 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 <drago01> while end means mid dec
18:07:53 <jreznik> notting: I'm also more inclined for the end of november, 11-12 is really the earliest
18:07:55 <nirik> drago01: yeah
18:08:09 <jwb> wait, what?
18:08:12 <sgallagh> Factoring in slips, end of November probably means early January...
18:08:14 <nirik> I prefer to have 2 weeks at least in case we slip. (no, we would never do that)
18:08:21 <jwb> are we seriously discussing .1 releases somehow?
18:08:27 <t8m> sgallagh, not necessarily
18:08:29 <nirik> jwb: it was an aside in the ticket.
18:08:29 <jreznik> 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 <jwb> nirik, which abadger1999 said wasn't serious
18:08:43 <nirik> sorry to have dragged it in.
18:09:03 <nirik> anyhow, I think 11-12 makes sense, as it gives us some room before holidays.
18:09:08 <jwb> i wouldn't expect us to start discussing .1 until we're well into 20
18:09:17 <jwb> er, sorry. planning 20
18:09:33 <nirik> sure
18:10:25 <sgallagh> 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 <jreznik> sgallagh: really, earlier is suicide, later is really too close to holidays
18:11:49 <t8m> so in case of the GA on 11-12 - all other dates are adjusted the same way?
18:12:07 <t8m> or except the Feature Submission deadline?
18:12:37 <t8m> sorry Changes proposals deadline now :)
18:12:57 <pjones> 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 <mitr> t8m: yes
18:13:21 <pjones> 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 <mitr> t8m: or at least that's how I read comment #7
18:13:37 <jreznik> 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 <nirik> 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 <jreznik> mitr, t8m: I pushed submission deadline a little bit to try to avoid conflict with F19 GA
18:14:23 <mitr> 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 <drago01> pjones: well features can be rejected on the basis "this does not fit the schedule"
18:14:32 <drago01> pjones: does not have to be the other way around
18:14:39 <sgallagh> 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 <nirik> 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 <jreznik> nirik: that was the main problem
18:14:54 <t8m> mitr, +1
18:14:56 <sgallagh> 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 <mitr> drago01: FESCo is rarely qualified to overrule the change owner's opnion about that
18:15:06 <t8m> sgallagh, +1
18:15:20 <nirik> 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 <notting> would we consider moving it if f19 moves?
18:15:52 <jreznik> notting: we have to consider that
18:16:08 <jreznik> but I hope for less than two months slips...
18:16:13 <pjones> drago01: no, that's idiotic.
18:16:25 <pjones> drago01: that's exactly how we got into the problem with f18. we can't continue doing that.
18:16:51 <pjones> that's literally the most irresponsible thing fesco can do.
18:17:03 <drago01> pjones: we didn't otherwise fesco would have told the anaconda folks "no way this can be done in 6 months"
18:17:10 <jreznik> we really need some compromise between - to be flexible based on the scope but also provide details to other teams
18:17:17 <pjones> drago01: no, that's *what the anaconda team told fesco*
18:17:31 <pjones> drago01: and it didn't get done in six months. It got done in 2 *years*.
18:17:39 <drago01> uh ok
18:17:47 <pjones> drago01: if we do what you're saying, features like that one can simply never be done. at all.
18:18:13 <jwb> 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 <jreznik> 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 <jreznik> jwb: usr move 2.0 - final one
18:19:05 <jreznik> move all users away, benefit for fedora - no users, no complaints
18:19:10 <jwb> not usr move 2.0. use re-move
18:19:11 <mitr> 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 <jwb> usr even
18:19:38 <jwb> (i am not being serious in the slightest)
18:19:40 <t8m> mitr, +1
18:19:44 <pjones> 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 <t8m> jreznik, +1
18:19:57 <pjones> mitr: instead we approved a schedule that we knew *at the time* the features would not fit in.
18:20:34 <pjones> 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 <t8m> pjones, maybe somebody knew somebody did not
18:20:46 <mitr> 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 <jreznik> 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 <jwb> mitr, because it's worse than what we did in f19
18:21:27 <jreznik> jwb: why?
18:21:33 <notting> 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 <jwb> 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 <jwb> it's not clear
18:21:52 <jwb> it leads to more confusion
18:21:53 <mitr> notting: ... and had no benefit because nobody came to us to ask for changing the schedule
18:22:01 <jwb> and people won't look back to see if it's adjusted
18:22:06 <jreznik> mitr: actually we asked
18:22:20 <sgallagh> jwb: Well, I think it's more: "We're setting this schedule, but it may extend longer if features demand it"
18:22:30 <pjones> 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 <jwb> sgallagh, which is exactly what i said
18:22:45 <sgallagh> 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 <jreznik> jwb: and that's exactly what we need - to be flexible
18:23:06 <jwb> what is inflexible about how we did it in f19?
18:23:12 <jwb> nothing. it's flexible
18:23:19 <pjones> 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 <jreznik> jwb: f19 was flexible, for devels and features, not for other teams
18:23:34 <pjones> that's exactly the same as the process that completely failed.
18:23:38 <sgallagh> jwb: We waited too long to give people any idea of what the end goal would look like.
18:24:00 <sgallagh> Up until Feature Submission Freeze and our schedule, most people were still expecting a final release in March/April.
18:24:09 <sgallagh> Which pretty much everyone agreed was too short
18:24:24 <jwb> please, let's not use "goal" for "date"
18:24:33 <jwb> this is a schedule
18:24:43 <pjones> 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 <mitr> 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 <sgallagh> jwb: We can argue semantics if you want, but my point was that QE and rel-eng were completely unprepared
18:25:10 <pjones> sgallagh: it's not semantics.
18:25:15 <jwb> 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 <jreznik> pjones: we are not reverting
18:25:22 <pjones> jreznik: bullshit.
18:25:27 <pjones> jreznik: that's *exactly* what we're doing.
18:25:34 <sgallagh> 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 <jreznik> pjones: no, that's not what I'm asking for
18:25:43 <t8m> and these bullshit words help how?
18:25:44 <sgallagh> I fail to see how that's anything but a compromise.
18:25:55 <mitr> jwb: Doesn't that effecitvely make the other teams the decision makers on the schedule?
18:25:57 <pjones> 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 <jreznik> sgallagh: exactly
18:26:06 <jwb> 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 <mitr> jwb: yes, a date that is either incorrect or constrains FESCo
18:26:52 <jwb> mitr, i fail to see how it being incorrect is a problem. they're early if we slip it out
18:27:08 <jwb> 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 <notting> 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 <sgallagh> notting: Since that's basically the exact thing I've been saying: +1
18:28:59 <t8m> notting, +1
18:29:03 <jwb> i'd rather it just say TBD
18:29:05 <pjones> notting: that would be /better/, but I don't see it as avoiding the fundamental fallacy.
18:29:11 <jreznik> 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 <nirik> and that gets removed after feature submission deadline?
18:29:39 <nirik> jwb: but then that doesn't help QA much.
18:29:45 <jreznik> pjones: well, it's nearly the same we did for F19...
18:29:49 <jreznik> just with more details
18:29:52 <mitr> notting: I wouldn't mind a stronger wording ("aiming for" or something) but it's a compromise I can live with
18:29:55 <pjones> nirik: then QA needs to be involved in deciding which features get approved.
18:29:59 <jwb> nirik, why not?
18:30:11 <pjones> nirik: the problem you're describing is that QA's role is after-the-fact.
18:30:25 <nirik> 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 <sgallagh> pjones: No, the problem he's trying to describe is that QA scoping is dependent on a schedule.
18:30:36 <jreznik> nirik: exactly
18:30:38 <nirik> they want to know how soon the later milestones are.
18:30:41 <jwb> HOW?
18:30:41 <jreznik> and not only QA
18:30:51 <sgallagh> Plus, if you give adamw the final say on the schedule, he'll add five months after beta :)
18:30:52 <jwb> people keep saying this impacts QA and other teams. please explain how
18:30:53 <pjones> sgallagh: no, that's a completely broken model
18:31:04 <pjones> QA's scoping is dependent on what we put in the release. full stop.
18:31:05 <nirik> tflink: you around? or adamw ?
18:31:10 <nirik> sure it is.
18:31:15 <adamw> yo
18:31:23 <adamw> what's the debate?
18:31:37 <jwb> 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 <sgallagh> adamw: Please describe how our F19 scheduling affected Fedora QA
18:31:49 <jwb> with the premise that the schedule is set after the content is know
18:31:50 <jwb> n
18:31:50 <adamw> jwb: rather a lot.
18:31:53 <jwb> HOW
18:31:55 <pjones> jwb: not how much. how.
18:32:00 <pjones> we need to know details
18:32:09 <jwb> pjones, yes, sorry. HOW
18:32:09 <adamw> sheesh. calm down.
18:32:19 <nirik> give him a second. sheesh
18:32:28 <notting> 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 <adamw> 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 <adamw> right, as notting say
18:32:41 <adamw> s
18:32:49 <adamw> we have the Quiet, Between Releases Phase
18:32:55 <adamw> and the Crazy Release Validation Phase
18:33:03 <jwb> i don't think that quiet phase actually exists
18:33:06 <adamw> during the quiet time before we start the blocker treadmill, we work on our tools and processes and so on
18:33:07 <jwb> but keep going
18:33:11 <adamw> jwb: sure it does, we've been in it for two months.
18:33:29 <jwb> no, development has been going on for 2 months. you just aren't testing it
18:33:31 <pjones> 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 <adamw> writing the blocker submission page, revising the FreezeException process, revising the criteria, all that stuff.
18:33:51 <adamw> 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 <pjones> 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 <adamw> jwb: that seems needlessly confrontational, and I'm not going to rise to it.
18:34:35 <nirik> pjones: wouldn't you agree that "not before X" is better than "TBA" for that purpose?
18:34:35 <jwb> 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 <adamw> pjones: sure, a date is useless if it's notional.
18:34:44 <pjones> nirik: I don't see how, no.
18:34:56 <jreznik> jwb: it's not quiet time but more get ready time
18:34:57 <sgallagh> pjones: I still think that knowing their "minimum" available time is more important than their exact time.
18:34:58 <adamw> jwb: i said that's how it looks to QA, not necessarily how it looks to anyone else.
18:35:11 <mitr> 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 <jreznik> sgallagh: yep
18:35:14 <adamw> 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 <nirik> 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 <sgallagh> nirik: That's the point I have been attempting to make, yes.
18:35:55 <notting> 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 <t8m> nirik, +1
18:36:29 <jwb> notting, rel-eng isn't tasked with testing the content going into fedora.
18:36:59 <jreznik> jwb: but the tooling has to be ready for alpha
18:37:00 <t8m> jwb, and QA currently either during their "quiet" or better said "preparational" phase
18:37:14 <pjones> 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 <notting> 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 <nirik> pjones: sure, thats a completely different question.
18:37:39 <t8m> pjones, but we don't do QA for features (not all of them)
18:37:49 <jwb> 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 <adamw> 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 <sgallagh> pjones: The "QA" for features is usually sponsored by the Feature in the form of the Test Days
18:38:25 <jwb> notting, feature. goes in with feature planning process.
18:38:25 <pjones> adamw: right, but the determination of which ones you look at must depend on what the features are, yes?
18:38:38 <sgallagh> I believe QA's goal is only to verify release criteria.
18:38:47 <mitr> 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 <nirik> and some features may impact those critera a lot, others not so much. yes.
18:39:01 <adamw> 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 <adamw> pjones: yes.
18:39:22 <pjones> sgallagh: right. some features factor in to release criteria more than others.
18:39:35 <jwb> adamw, ok, fair.
18:39:37 <sgallagh> pjones: Certainly, I'm not arguing that at all.
18:39:58 <jwb> mitr, i disagree. you can always test to make sure things are breaking other things.
18:39:59 <pjones> 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 <adamw> 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 <sgallagh> 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 <t8m> jwb, you can if you have resources to do that
18:40:37 <jwb> t8m, hence my statement of the problem. which is lack of people.
18:40:43 <pjones> sgallagh: right. That's the F14, F15, F16, F17, and F18 model. that's it *exactly*.
18:41:06 <jwb> sgallagh, i'm also not seeing how that differs from f18
18:41:18 <jreznik> pjones: and also F19 one
18:41:18 <sgallagh> pjones: No, it's not. The F18 model was "we'll slip at the end".
18:41:23 <t8m> sgallagh, +1
18:41:26 <pjones> (not meant to be an exclusive list)
18:41:28 <adamw> 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 <jwb> sgallagh, slips always happen at the end
18:41:33 <sgallagh> This is "We'll adjust the schedule near the beginning if we can see that it might need it"
18:41:41 <pjones> 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 <jwb> adamw, it wouldn't make sense to change it, but you could certainly work on it
18:41:59 <jreznik> pjones: and we can do the same for F20, I don't see a problem with that
18:42:07 <nirik> well, additionally this is also "we will only expand/increase after feature submission deadline"
18:42:07 <jreznik> (and I expect we would have to do it)
18:42:07 <sgallagh> 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 <t8m> 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 <sgallagh> I'd recommend that right up front.
18:42:25 <pjones> 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 <sgallagh> pjones: That's why I'm saying we can STILL move the schedule out at Submission Freeze.
18:43:03 <sgallagh> Instead of slow-slipping.
18:43:16 <adamw> jwb: true. the system we use is not inevitable, if that's what you're driving at.
18:43:23 <pjones> 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 <sgallagh> And now I have to leave to collect my daughter. I'll read the scrollback later.
18:43:31 <nirik> 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 <pjones> sgallagh: just abjectly refusing to do our job, really.
18:43:43 <jwb> adamw, i'm just trying to understand the problem.
18:43:46 <jreznik> nirik: +1
18:44:07 <pjones> 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 <nirik> is there a way we could send the right message and still allow other teams early planning dates?
18:44:42 <mitr> 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 <pjones> 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 <jreznik> 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 <jreznik> so we always need a timeframe (the minimum) we expect to give devels
18:45:32 <jwb> why is there a "start planning" date?
18:45:35 <nirik> 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 <pjones> jreznik: yes, but there's real utility in *not* giving dates.
18:45:57 <notting> jwb: tool limitations?
18:45:59 <pjones> jreznik: the point of not giving dates is to ensure the appearance of not having decisions made.
18:46:00 <t8m> pjones, to confuse people?
18:46:05 <jwb> notting, what?
18:46:06 <mitr> jwb: I suppose "change process is stable/redefined and we are now able to accept proposals"
18:46:07 <nirik> jwb: yeah, that should be removed. ;)
18:46:10 <jreznik> jwb: TaskJuggle, I need a task to start with
18:46:19 <jwb> jreznik, that doesn't mean you tell people about it
18:46:21 <notting> jwb: why there's a start date. limitation of the tools.
18:46:21 <pjones> 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 <jwb> no
18:46:34 <jwb> if your tool needs a date, put it as today
18:46:47 <t8m> pjones, I am willing to take that thinking of yours as I get the same of yours
18:47:01 <jwb> there is 0 excuse for people to look at a schedule and say "oh, i start planning for f20 in may"
18:47:12 <jwb> especially if it's because of a damn tooling limitation
18:47:20 <jwb> so don't even list that
18:47:31 <jreznik> 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 <nirik> so, where are we here? 47min and no decision... punt to next week and discuss on list/ticket? vote on something?
18:47:55 <pjones> 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 <nirik> pjones: I think they do mean something. They mean "at least this date, no earlier"
18:48:20 <jreznik> pjones: not mean anything but gives us at least some overview... I don't want more
18:48:27 <jreznik> nirik: yep
18:48:36 <mitr> pjones: They do mean something to me, even if tentative
18:48:59 <pjones> nirik: yeah, I still think vague guidance is actually more useful.
18:49:12 <adamw> for our purposes, 'not before' dates work absolutely fine (someone mentioned this above)
18:49:25 <jreznik> 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 <jwb> jreznik, good. and we've now made a small amount of progress.
18:50:11 <pjones> adamw: would "not less than X weeks" be more or less useful (or the same)?
18:50:34 <nirik> pjones: vague as in? feature submission is X, after that, well...
18:51:27 <t8m> 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 <pjones> 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 <jreznik> 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 <pjones> 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 <pjones> 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 <jwb> jreznik, i just realized it was there a few min ago. glad we could get it resolved so quickly
18:52:29 <nirik> pjones: that seems more anoying to me than providing approx dates for the milestones.
18:52:35 <t8m> nirik, +1
18:52:44 <nirik> pjones: would 'release mid 2012-11' be better?
18:52:53 <nirik> or I guess not.
18:52:54 <pjones> nirik: yeah, that'd be better.
18:52:55 * nirik ponders
18:53:01 <pjones> er.
18:53:12 <pjones> Actually now I'm not sure what you've said.
18:53:16 <pjones> 2012-11?
18:53:19 <nirik> heh. :) sorry.
18:53:25 <nirik> 2013-11
18:53:28 <pjones> Oh, you're saying november.
18:53:34 <pjones> eh, somewhat better.
18:54:00 <nirik> but somewhat worse for people wanting to plan time before say the alpha release.
18:54:05 <notting> so is there a proposal on the table?
18:54:21 <jreznik> 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 <nirik> proposal: punt this week, discuss more and see if we can come up with a consensus
18:54:32 <pjones> 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 <adamw> 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 <jreznik> and manually doing fuzzy schedules, sorry...
18:55:19 <mitr> 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 <nirik> 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 <jreznik> 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 <mitr> IMHO that's Good Enough(tm) and I'm not looking forward to another 60 minutes next week
18:55:35 <notting> s/adjusted/adjusted out/?
18:56:06 <jreznik> mitr: thanks
18:56:08 <mitr> notting: sure, yes
18:56:25 <t8m> mitr, +1
18:56:25 <mitr> 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 <pjones> mitr: obviously I'm -1 to staying with the status quo.
18:56:39 <t8m> mitr, +1
18:56:44 <nirik> 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 <t8m> nirik, and +1 to that
18:57:44 <nirik> pjones: well, returning to the old way I'd say... since we didn't do that for f19... ;)
18:57:45 <jreznik> nirik: I can do that on wiki, not sure about TJ, but will try
18:58:25 <pjones> 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 <nirik> sorry to hear it. :(
18:59:02 <pjones> 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 <jreznik> we definitely do not want to repeat F17, F19
19:00:08 <jreznik> sorry F18
19:00:21 <notting> well, we may not want to repeat f19. we'll see about that .
19:00:39 <nirik> I see your point, but not having a schedule at all until after feature submission deadline does negatively impact some folks. ;(
19:01:14 <pjones> 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 <mitr> More votes - on the proposal, or votes to defer?
19:01:34 <mitr> Let's not do another round of the same arguments please
19:01:35 <nirik> I think the benift is that they can plan for that minimal worst case...
19:01:47 <jreznik> 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 <nirik> s/worst/best/ whatever
19:01:50 <pjones> nirik: that's best, not worst.
19:02:05 <notting> 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 <jreznik> and I'm not saying I have to share a detailed schedule for every task, just it makes my life happier
19:02:11 <pjones> 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 <nirik> pjones: by allowing them more time?
19:02:55 <pjones> nirik: I wouldn't call what we did in f18 "allowing QA more time", really...
19:03:12 <notting> so we're at +2 -1
19:03:25 <pjones> 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 <nirik> pjones: in that case we didn't finalize/adjust the schedule after feature freeze.
19:03:56 <mitr> notting: I'm +1 to my proposal for the record
19:03:58 <jreznik> 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 <pjones> jreznik: no, that was the *result* of the bad decision.
19:04:23 <pjones> (well, of 2 bad decisions)
19:04:47 <pjones> 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 <mitr> 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 <jwb> we are not making progress any longer.
19:05:32 <pjones> mitr: we didn't know the anaconda rewrite was going to land in F18? We certainly did know that.
19:05:35 <jreznik> pjones: as mitr says, nobody knew but once we knew, we said - we don't care
19:05:54 <pjones> 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 <notting> 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 <jreznik> pjones: we knew it, we did not have details ala fedup
19:06:07 <notting> so that's +4, -1, 3 not here. jwb?
19:06:18 <jwb> 0
19:06:38 <jreznik> pjones: if we knew about fedup not being ready, even not started, we could react... same for live images for alpha
19:06:52 <mitr> 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 <notting> well then. i guess that's an implicit tabling for next week with more quorum
19:07:11 <pjones> 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 <notting> #info motion to ratify proto-schedule did not pass
19:07:27 <nirik> notting: yep.
19:07:30 <pjones> 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 <notting> moving on...
19:08:01 <notting> #topic #1096 Rawhide Rebase to Fedora 19 in Bugzilla
19:08:04 <notting> .fesco 1096
19:08:07 <zodbot> notting: #1096 (Rawhide Rebase to Fedora 19 in Bugzilla) – FESCo - https://fedorahosted.org/fesco/ticket/1096
19:08:17 <mitr> +1
19:08:17 <jwb> notting, how did it not pass?
19:08:18 <jreznik> pjones: I took a place in that too
19:08:47 <pjones> jwb: +4, -1, 1 not voting, 2 absent.
19:08:56 <pjones> jwb: needs 5 to pass.
19:09:01 <jwb> who were the 4?
19:09:10 <jwb> notting, nirik, t8m, mitr?
19:09:12 <pjones> notting, t8m, mitr, nirik.
19:09:30 <jwb> oh, sgallagh wasn't actually here to vote. ok. pretty sure he would have been +1, but sure
19:09:41 <pjones> anyway, moving on.
19:09:43 <nirik> 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 <pjones> nirik: likewise.
19:09:57 <jwb> yes, +1
19:10:12 <notting> i'm not against it. although it's just more bugspam noise
19:10:15 <jwb> nirik, perhaps with the exception of something marked FutureFeature in the keyword?
19:10:21 <jreznik> jwb: shouldn't we ask marcela and sgallagh to vote in the ticket? otherwise we are blocked
19:10:27 <nirik> 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 <jwb> jreznik, yes
19:10:34 <notting> jreznik: it defaults to punt to next week
19:10:44 <notting> jreznik: although if you want to do that, plz update with the final proposal
19:10:47 <nirik> jwb: it does exclude that I think.
19:10:48 <pjones> jreznik: we shouldn't ask people to vote on this without being part of the discussion
19:10:50 <jwb> nirik, great
19:10:51 * nirik checks the query
19:11:00 <notting> so, i'm +1
19:11:08 <jreznik> query contains FutureFeature
19:11:10 <jwb> 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 <nirik> yeah, https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19#Bug_Selection_Criteria
19:11:20 <notting> that's 5...
19:11:50 <nirik> jreznik: are you going to do this rebase? or is it something we ask bugzilla people to do ?
19:12:07 <mitr> 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 <notting> #agreed rebasing of rawhide bugs to f19 (and later releases for each subsequent release) is approved (+:5, -:0, 0:0)
19:12:18 <jreznik> 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 <notting> #topic #1094 tomcat6 deprecation (fasttrack)
19:13:09 <notting> .fesco 1094
19:13:12 <zodbot> notting: #1094 (tomcat6 deprecation (fasttrack)) – FESCo - https://fedorahosted.org/fesco/ticket/1094
19:13:14 <nirik> 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 <jreznik> nirik: I'm trying to document it, scripts are now in public git...
19:13:45 <nirik> so, on this one last comment suggests we wait a week. I'm +1 on that.
19:14:23 <t8m> +1 to wait a week
19:14:28 <mitr> AFAICS this is actually only 1 week into the "unresponsive maintainer" process
19:15:20 <mitr> 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 <nirik> mitr: yeah, they suggested this was security sensitive and more urgent.
19:15:35 <mitr> Anyway, +1 to wait a week and revisit
19:15:56 <pjones> yeah, +1 to that.
19:15:59 <notting> i can go with that +1
19:16:04 <jwb> +1
19:16:29 <notting> #agreed wait one week and revisit (+:6, -:0, 0:0)
19:16:45 <notting> #topic #1098 F19 Features - Progress on Feature Freeze
19:16:47 <notting> .fesco 1098
19:16:49 <zodbot> notting: #1098 (F19 Features - Progress on Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1098
19:18:09 <nirik> I think gnome is further along... just hasn't updated.
19:18:36 <jreznik> nirik: needs update, so I should put it to the second cat
19:18:55 <jreznik> for QXL/Spice Alon was sick, he's going to provide update soon
19:19:22 <notting> usermode migration is still stalled due to lack of manpower
19:20:05 <mitr> 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 <mitr> 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 <notting> adamw: ?
19:22:52 <jwb> i'm fine with the proposal to drop the features at the bottom in 1 week
19:23:02 <nirik> 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 <nirik> I'm fine too revisiting next week and dropping any that don't update by then in the bottom list.
19:24:01 <jwb> nirik, some of them were updated yesterday
19:24:05 <jwb> like the anaconda ones
19:24:09 <mitr> 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 <nirik> jwb: oh indeed so.
19:24:22 <jreznik> jwb: it's today's list
19:24:43 <jreznik> the last one are with recent updates
19:24:44 <mitr> I'm also fine with dropping the non-updated ones; jreznik: please make this consequence clear when asking for updates
19:24:52 <jwb> jreznik, what do you mean it's today's list?
19:25:13 <jreznik> jwb: the list was generated today
19:25:19 <nirik> proposal: keep asking for updates, revisit next week which ones we wish to drop ?
19:25:27 <notting> nirik: +1
19:25:42 <jwb> jreznik, right. and you suggest dropping the features at the bottom in one week if they aren't updated
19:25:43 <nirik> some of the ones in the bottom list I think we should keep actually...
19:25:46 <jreznik> nirik: well I'd limit to the "no recent updates" category only
19:25:52 <nirik> the % is not a very good indicator
19:25:56 <jreznik> jwb: no, the top category
19:26:02 <jwb> ah
19:26:06 <jwb> i misunderstood
19:26:19 <nirik> yeah, I got confused too. sorry.
19:26:21 <jreznik> nirik: that's why I asked for "status" update and best effort estimate in %
19:26:30 <jreznik> nirik, jwb: sorry
19:26:34 <jreznik> for confusion
19:26:45 <jwb> so the list on the bottom is just "FYI, this is where they are"?
19:26:57 <jreznik> jwb: yep
19:27:09 <jwb> well... freeze was yesterday, right?
19:27:39 <jreznik> yes
19:28:10 <jwb> so anything in the bottom list that is of a low percentage technically isn't complete by feature freeze, right?
19:28:31 <nirik> it needs to be 'testable' right?
19:28:42 <t8m> nirik, +1
19:28:46 <jwb> to my understanding, yes
19:28:48 <jreznik> nirik: yes, some are for some reason not in testable state
19:28:58 <jwb> then i think those go in the top list
19:29:10 <jreznik> for example Anaconda Realm Integration depends on Anaconda being testable
19:29:37 <jwb> ok. let's make this easier
19:29:53 <nirik> https://fedoraproject.org/wiki/Feature_Freeze_Policy
19:29:57 <jreznik> 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 <pjones> 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 <jwb> 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 <nirik> substantially complete and in a testable state - enabled by default -- if so specified by the feature
19:30:13 <pjones> jreznik: ... to be resurrected at a later release when I've got more confidence I can follow through
19:30:16 <jreznik> pjones: yes, I saw it
19:30:35 <nirik> jwb: +1
19:30:53 <notting> 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 <mitr> jwb: +1, though that's a bit more scary than it needs to be for many features
19:31:34 <jwb> why?
19:32:02 <jwb> 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 <pjones> jwb: +1
19:32:09 <t8m> jwb, +1
19:32:13 * nirik nods.
19:33:09 <jreznik> 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 <mitr> 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 <jreznik> but I'm ok with any decision and I'll proceed with it
19:33:43 <jreznik> mitr: that's my concern...
19:33:51 <mitr> jwb: But I can go with "the schedule is strict and works for everyone" as well
19:33:57 <jwb> 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 <jreznik> 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 <jreznik> they are mostly ok with that
19:35:07 <jwb> they can repropose it later as an exception
19:35:18 <jwb> i cannot wait until we stop calling these things features
19:35:23 <mitr> 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 <jwb> yes
19:35:44 <jwb> 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 <jreznik> 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 <jwb> jreznik, er.. do what?
19:36:23 <jreznik> it was in proposal but we did not agreed on that, we can still tweak it
19:36:25 <notting> mitr: counting you, yes
19:36:33 <jreznik> jwb: fair enough, for old process, old rules
19:37:00 <notting> #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 <notting> jreznik: you're on the hook for sending said mail?
19:37:11 <jreznik> 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 <jwb> oh, that. ok, sure
19:37:21 <jreznik> notting: yes
19:38:10 <mitr> jreznik: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process still contains it, and was accepted per 2013-02-13
19:38:11 <jreznik> 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 <notting> mooooving on...
19:38:50 <jreznik> mitr: Self contained changes follows the same schedule for the Change Submission deadline as complex changes
19:39:00 <notting> #topic Next Week's Chair
19:39:01 <mitr> jreznik: Oh, that part. right.
19:39:15 <pjones> jreznik: and either way, it still isn't the process we're actually using.
19:39:18 <jreznik> mitr: it was changed...
19:39:27 <jreznik> pjones: I agree
19:41:44 <nirik> I guess I could do chair next week if no one else can.
19:42:33 <pjones> are we doing 2pm EDT again next week?
19:42:44 <netSys> hi
19:43:00 <notting> #info nirik will chair next week
19:43:14 <notting> 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 <t8m> nirik, either that or move after the next 2 weeks
19:44:58 <nirik> I hate timezones.
19:45:16 <mitr> 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 <pjones> notting: actually I'd rather 2pm EDT next week anyway, which is why I'm asking.
19:46:33 <pjones> 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 <mitr> 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 <notting> ok, i'm fine with not changing
19:48:58 <notting> #topic Open Floor
19:49:00 <NeatBasis> talking about time in any other timezone than UTC makes no sense in an international collaboration
19:49:40 <nirik> If anyone cares, I put my revamped Rawhide page in place on the wiki, feedback welcome.
19:50:58 <notting> nirik: url?
19:51:12 <nirik> https://fedoraproject.org/wiki/Releases/Rawhide
19:51:27 <nirik> I'm going to revamp the Branched one too the same way, it's also dire.
19:51:49 <notting> oh, revamped rawhide page, not page for revamping rawhide
19:52:05 <adamw> 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 <notting> adamw: cool, thx
19:53:04 <notting> #info rawhide pages on the wiki at https://fedoraproject.org/wiki/Releases/Rawhide have been updated - please send feedback to nirik
19:53:16 <notting> anything else for open floor? if not, will close in 2 minutesd
19:55:30 <notting> thanks all
19:55:33 <notting> #endmeeting--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
