Summary/Minutes from today's FESCo Meeting (2012-11-28)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



===================================
#fedora-meeting: FESCO (2012-11-28)
===================================


Meeting started by mitr at 18:00:19 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2012-11-28/fesco.2012-11-28-18.00.log.html
.



Meeting summary
---------------
* init process  (mitr, 18:00:26)

* #966 Fedora 19 Schedule proposal (DRAFT!)  (mitr, 18:04:00)
  * LINK: https://fedorahosted.org/fesco/ticket/966   (mitr, 18:04:04)
  * AGREED: : Feature sumission deadline pushed back to 1/29, we'll
    figure out the rest of the schedule based on submitted features
    (mitr, 18:32:49)
  * AGREED: FESCo agrees to initially target a end-of-May release with
    an end-of-February branch date, but may adjust outwards depending on
    submitted features. Schedule will be made  at or shortly after the
    feature submission deadline. (+8)  (mitr, 18:47:52)
  * ACTION: jreznik will announce F19 features and timing  (mitr,
    18:51:58)

* #896 Refine Feature process  (mitr, 18:52:13)
  * LINK: https://fedorahosted.org/fesco/ticket/896   (mitr, 18:52:17)
  * LINK: https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
    that is  (mitr, 18:53:55)

* #974 Allow releases on Wed and Thu as well  (mitr, 19:24:06)
  * LINK: https://fedorahosted.org/fesco/ticket/974   (mitr, 19:24:10)
  * AGREED: Releases must be on Tuesday, Wednesday, or Thursday, but
    always pick Tuesday by default unless there's a specific reason not
    to."  (mitr, 19:43:02)

* Next week's chair  (mitr, 19:43:08)
  * ACTION: notting will chair next wee's meeting  (mitr, 19:44:49)

* Open Floor  (mitr, 19:44:55)

Meeting ended at 19:47:04 UTC.




Action Items
------------
* jreznik will announce F19 features and timing
* notting will chair next wee's meeting




Action Items, by person
-----------------------
* jreznik
  * jreznik will announce F19 features and timing
* notting
  * notting will chair next wee's meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* pjones (105)
* mitr (102)
* jwb (72)
* jreznik (70)
* mjg59 (61)
* nirik (52)
* notting (48)
* limburgher (30)
* mmaslano (27)
* tflink (12)
* drago01 (8)
* zodbot (7)
* pingou (3)
* Southern_Gentlem (1)
* t8m (0)






18:00:19 <mitr> #startmeeting FESCO (2012-11-28)
18:00:19 <zodbot> Meeting started Wed Nov 28 18:00:19 2012 UTC.  The
chair is mitr. Information about MeetBot at
http://wiki.debian.org/MeetBot.
18:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea
#link #topic.
18:00:22 <mitr> #meetingname fesco
18:00:22 <zodbot> The meeting name has been set to 'fesco'
18:00:24 <mitr> #chair notting nirik mjg59 mmaslano t8m pjones mitr
limburgher jwb
18:00:24 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano
nirik notting pjones t8m
18:00:26 <mitr> #topic init process
18:00:28 <mitr> Hello all
18:00:39 <jwb> hi.  i'm 2/3 here today
18:00:42 * notting is here
18:00:43 * nirik is sort of here.
18:00:58 <mjg59> Hi
18:01:05 <mmaslano> evening
18:01:35 * jreznik is around to serve fesco (and yeah, final blocker
bug meeting happening...)
18:02:01 <jwb> maybe we should rephrase that as "block bug meeting for final"
18:02:08 <jwb> because i doubt it's the last blocker bug meeting
18:02:36 <jreznik> jwb: sure and the list is huge :(
18:03:09 * pjones is here
18:03:12 * limburgher here but busy
18:03:39 <mitr> t8m seems to be offline, let's start
18:04:00 <mitr> #topic #966 Fedora 19 Schedule proposal (DRAFT!)
18:04:02 <mitr> .fesco 966
18:04:04 <mitr> https://fedorahosted.org/fesco/ticket/966
18:04:04 <zodbot> mitr: #966 (Fedora 19 Schedule proposal (DRAFT!)) –
FESCo - https://fedorahosted.org/fesco/ticket/966
18:05:08 <pjones> this schedule proposal is basically just copying the
(completely terrible) f18 schedule, except actually worse, because it
puts the feature submission deadline on the day after development
begins.
18:05:17 <jreznik> well - what I need is from FESCo to a) set the
timeframe and target date for F19 release and propose the changes as a
few members were not ok with current release process (and yeah, I see
that problems too)
18:05:25 <jreznik> pjones: yes, it is
18:05:41 <jreznik> but a start point and I got your point
18:06:09 <jreznik> so what I want now is discuss it
18:06:12 <mjg59> Where do we expect people to do feature development?
18:06:27 <mitr> Does the "development begins" date have any real function?
18:06:33 <limburgher> In my eyes, immediately post branching.
18:06:39 <pjones> mitr: it's just the date the branch happens
18:06:49 <pjones> it's the earliest date you can feasibly commit a change on
18:07:09 <mitr> pjones: no, branch is scheduled on 2012-02-26 in the proposal
18:07:15 <jreznik> mitr: it's the time when schedule starts - you need it for tj
18:07:26 <jwb> tj?
18:07:33 <mitr> jreznik: OK, so we can ignore it
18:07:35 <notting> mitr: no, development for f19 can begin as soon as
*f18* branches
18:07:38 <jreznik> taskjuggler or any other scheduling tool
18:07:39 <notting> jwb: taskjuggler
18:07:44 <jwb> oh
18:08:02 <jwb> notting, right.  development basically already began
18:08:05 <mjg59> notting: How?
18:08:06 <jwb> or should have
18:08:08 <jreznik> but as notting pointed out - the real development
can start when f18 branches
18:08:12 <jwb> mjg59, you develop in rawhide?
18:08:13 <nirik> rawhide?
18:08:18 <mjg59> jwb: Rawhide's unusable
18:08:24 * nirik disagrees.
18:08:25 <mjg59> We explicitly tell people not to use it
18:08:32 <jwb> mjg59, then we should stop producing it
18:08:37 <mitr> mjg59: that doesn't make the F19 branch usable just
because we branched
18:08:48 <nirik> we should not do that.
18:08:54 <mjg59> How long was systemd broken in rawhide?
18:08:56 <pjones> mitr: oh actually, you're right - this diverges from
past schedules in that previously it was the prior branch date
18:09:03 <notting> mjg59: usability of rawhide depends on what you're
developing for that release, yes. but it offers you a place to put and
build code
18:09:07 <nirik> mjg59: a week or two...
18:09:19 <pjones> mitr: whereas on this one it's compressed forward in
time because we'd look stupid putting dates in the past
18:09:33 <mjg59> If we're going to predicate our development schedule
on it being possible to do development in rawhide, we should ensure
that rawhide is somewhere where people can actually do development
18:09:37 <mjg59> And that includes being able to use rawhide
18:09:42 <pjones> (well, far in the past - I note that this schedule
began on monday)
18:09:44 * nirik agrees.
18:09:46 <mitr> I'm all for making rawhide more usable, but does it
really affect the F19 schedule?
18:09:53 <jwb> ... yes
18:10:08 <mjg59> mitr: It does if the entire development window for
F19 is basically "Rawhide, now"
18:10:12 * nirik has some ideas around that... but not sure how well
any of it will work.
18:10:12 <jreznik> pjones: we did it several times - looking on slips
and dates when the point "here the schedule starts" in the past
18:10:15 <mitr> What would be different in the schedule under the
assumption that rawhide should not be used?
18:10:28 <jwb> mitr, because otherwise development doesn't start until
f19 is branched, and when it's branched it'll be utterly broken if
rawhide is
18:10:43 <jwb> branching doesn't magically make stuff work
18:11:05 <mitr> jwb: In practice development happens all the time,
AFAICT the "development start" date doesn't mean much.
18:11:06 <notting> branching doesn't magically make stuff work, nor
does rawhide magically break things.
18:11:11 <jreznik> jwb: and there's the problem we hit - the time
between branch and alpha freeze is quite short...
18:11:13 <mjg59> People aren't going to be working on making rawhide
work until after F18 is frozen for final
18:11:31 <jwb> then we push out the f19 schedule to reflect that
18:11:32 <mjg59> Which gives us, what, a month?
18:11:40 <limburgher> Ok, wild idea, why does f19 branch have to wait
for f18 to be GA?
18:11:51 <jwb> mjg59, or push the schedule out to reflect reality
18:12:04 <notting> limburgher: the factor in the instability of
rawhide is developer attention, not the presence or absence of a
branch
18:12:05 <mitr> mjg59: 2 months between F18 release and alpha change deadline
18:12:12 <mjg59> limburgher: It doesn't, but I suspect that that just
results in us having a broken F19 branch as well as broken rawhide
18:12:24 <limburgher> notting mjg59, good points.
18:12:30 <mitr> limburgher: That would make the problem of people
working on the branch first and ignoring rawhide completely even worse
18:12:32 <mjg59> mitr: Yes, but nobody will be able to do any
development in F19 at that point because the branch will still be
broken
18:12:42 <jreznik> mjg59: yep, making rawhide from f19 branch is not
option neither
18:12:44 <nirik> and it will be more work for everyone.
18:12:45 <limburgher> mitr:  Ick, didn't think of that.
18:13:17 <mitr> mjg59: So what's your proposal?  N months between
final and alpha, where N >> 2?
18:13:29 <mjg59> So, basically, I'm fine with this schedule as long as
rawhide is usable right now
18:13:31 * mitr would prefer dicussing specific schedule changes
18:13:37 <notting> and we also cannot *solve* that developer
inattention/behavior with a schedule - although the suggestion appears
to be to schedule around it?
18:13:45 <nirik> mjg59: I could try and work on rawhide sooner rather
than later...
18:13:56 <pjones> notting: well, we haven't been able to solve it any
other way, either.
18:14:04 <mjg59> And as long as developers are actually working on
rawhide right now
18:14:14 <mjg59> Which is pretty much another way of saying that I'm
not ok with this schedule at present
18:14:19 <jwb> notting, well, if we don't schedule around reality, we
wind up slipping later anyway
18:14:33 <mjg59> So, eh, just move everything out a month
18:14:44 <jwb> when is the final f18 freeze?
18:14:54 <pjones> TBH I'm not sure rawhide is the issue - there's
really just not enough time to do major features.
18:14:57 <nirik> well, some folks are using/building against rawhide,
it's just unclear how many or if it's usable for big feature owners,
since we don't know yet who all those are.
18:14:59 <jreznik> jwb: 2012-12-18
18:15:00 <mitr> jwb: 2012-12-18
18:15:07 <pjones> which is why they always land in chunks, and if they
can't land in chunks we wind up pushing the schedule out
18:15:14 <pjones> as F18 so terribly exemplified.
18:15:24 <mjg59> pjones: Given the F18 slips, in theory most
developers should already have landed their F18 work and could be
doing F19 development in rawhide now
18:15:37 <jreznik> mjg59: yep
18:15:50 <notting> mjg59: except the ones tied to fixing f18 blockers.
which also happens to be a group with a lot on the plate for f19
18:15:50 <mjg59> pjones: But obviously reality
18:16:03 <mjg59> notting: Well sure.
18:16:10 <jreznik> notting: it hits anaconda - definitely
18:16:11 <pjones> mjg59: right, and most developers don't do big
features anyway, so they're not the ones that get hurt by the schedule
simple not making big features possible
18:16:26 <mjg59> If we're planning more significant Anaconda work for
F19 then this doesn't work at all
18:16:34 * nirik nods
18:16:37 <jwb> so...  maybe we should actually look at the f19 features first
18:16:45 <jwb> because i have no fscking idea what you're talkinga bout
18:17:06 <limburgher> So far I can only think of RPM off the top of my head.
18:17:09 <mitr> ... and to complicate it even more: Do we want to
change the feature process before accepting F19 features or not?
18:17:11 <jwb> but if there is BIG SCARY THINGS, then i'd rather
understand what those are and how long (estimation) they'll take
before we just up and set a schedule
18:17:17 <mjg59> Well, feature submission deadline isn't for 2.5 months
18:17:29 <notting> jwb:
https://fedoraproject.org/wiki/Anaconda/Work_List lists some stuff
18:17:48 <limburgher> jwb:  We could also set the schedule and
approve, modify or deny features accordingly.
18:17:50 <mitr> jwb:
https://fedoraproject.org/wiki/Category:FeatureReadyForWrangler is
what we seem to have
18:17:51 <nirik> proposal: tenatively accept this schedule, adjust as
we need to as soon as we see a compelling need to
18:17:58 <pjones> mitr: no, that just plain doesn't actually work
18:17:58 <mjg59> nirik: -1
18:18:05 <pjones> that mentality is why F18 is such a disaster.
18:18:47 <mmaslano> so what's your proposal?
18:18:59 <jreznik> pjones: well - anaconda/fedup made the mess - and
yeah, there's space to make it better to fit anaconda development into
schedule but
18:19:01 <notting> do people have issues with the intervals and
milestones that start at 02-12 through the release, or merely *that*
they start at 02-12?
18:19:07 <pjones> jreznik: bullshit
18:19:13 <mitr> pjones: what do you mean exactly?  F18 didn't have a
feature submission deadline blocked on feature process changes IIRC
18:19:17 <pjones> jreznik: the schedule made this mess, and I said so
before it was approved.
18:19:25 <mjg59> proposal: Schedule a feature submission deadline, set
the rest of the schedule after we know what we're actually planning on
incorporating
18:19:32 <jwb> mjg59, +1
18:19:44 <pjones> the reason anaconda didn't fit in to the schedule is
that we made a schedule where it could not be fit in.
18:19:44 * nirik notes it's very difficult to plan without knowing
anything about what people are going to try and do at this point,
aside from 'new rpm'
18:19:48 <jwb> and i'd suggest setting it earlier than 2/12
18:19:56 <jwb> nirik, right.
18:20:02 <mjg59> jreznik: It's impossible to develop against rawhide
and the feature development time after branch is tiny
18:20:06 <jreznik> jwb: I'm ok with setting it eariler
18:20:18 <jreznik> mjg59: that's said - I agree with this point
18:20:20 <mjg59> jreznik: So we either fix rawhide or we change the
schedule such that there's an acceptable amount of development time
post branch
18:20:29 * nirik thinks there's some value to at least tenative
milestones after that, we can always change them...
18:20:32 <jwb> basically, i think we're saying a time based release
isn't working.  let's try and be smarter
18:20:33 <notting> mjg59: i am -1 to that merely because if we're
doing that we are essentially changing to be fully feature-based
instead of time-based, and i'm not comfortable with that decision made
in this (relative) vacuum
18:20:40 <mjg59> jreznik: It's not the fault of individual projects
within the distribution
18:21:02 <mjg59> notting: Well, what are our options here?
18:21:11 <jwb> notting, time-based hasn't worked well at all.  name
the last release we didn't have significant slips?
18:21:17 <mitr> -1 as well, I think given the size of the distribution
we simply have to be time-based
18:21:18 <mjg59> notting: If the people working on Anaconda are going
to need more time, it's not like we can ship without them
18:21:57 <notting> jwb: there was a spreadsheet. hrm. think there were
a few that were in the ~2 week range
18:22:02 <pjones> mitr: I think that's a bit of a logic failure.  Most
features are small - they'll fit in a schedule that's effectively time
based, but the timeframe can be determined by ticket items landing.
18:22:16 <mitr> mjg59: For big changes, it means either doing them in
smaller steps, or doing them in a separate branch and integrating when
ready.  We have quite a few upstreams with longer release cycles than
6 months.
18:22:33 <mjg59> mitr: Fedora is Anaconda's upstream
18:22:58 <notting> mjg59: i think if we want to move to feature-based,
then we should *plan* actual features and roadmaps. doing feature
based, but basing it off of whatever people happen to file a ticket
for seems a insufficient/misguided
18:23:09 <pjones> mitr: which means we have to decide which ones of
them we want to land in each release.
18:23:11 <mitr> pjones: Yes, to some extent - but we should set an
expectation of how long the release cycle is supposed to be.
Adjusting a few weeks is not a big deal, of course
18:23:19 <jwb> i still think blindly setting a schedule now is
irresponsible.  set a feature submission deadline, STICK TO IT, and
then flesh out the rest of the schedule
18:23:28 <pjones> jwb: I absolutely agree with that.
18:23:29 <mitr> (20 minutes, continue disscussion?)
18:23:34 * nirik thinks we shouldn't decide to switch from timebased
here with no community/board input.
18:23:34 <limburgher> jwb: +1
18:23:50 <jreznik> nirik: +1
18:23:53 <mjg59> The aim should still be to release approximately on time
18:23:54 <limburgher> nirik: +1
18:23:58 <pjones> for clarity: +1
18:24:09 <mjg59> But does anyone believe that we will meet the
proposed schedule?
18:24:18 <pjones> no, not even a little.
18:24:23 * nirik has no idea since it's unknown whats going to be in it.
18:24:26 <jwb> i have utterly no idea.
18:24:33 <jwb> which is why i think it's irresponsible
18:24:49 <pjones> nirik: you don't need to know that to know it'll
slip.  it's somewhat compressed from even f17 and f16, which both
slipped.
18:24:55 <nirik> but if we say this is what we want to try and do,
feature owners might adjust to that too... ie, too short, I'll shoot
for f20
18:25:06 <pjones> nirik: how's that not better?
18:25:06 <jwb> nirik, that is a good thing...
18:25:07 <mitr> mjg59: I'd expect respective package maintainers to
take the schedule into account.  If they don't, we have a governance
problem.
18:25:11 <limburgher> nirik: Yes.
18:25:25 <nirik> pjones: sure, but if it was 6 months longer you think
it would not slip?
18:25:34 <mjg59> mitr: Again, how should people be doing development
if a feature will take longer than 6 months?
18:25:36 <notting> i think time-based is a reasonable thing , if we
are able to make good estimates as to what we can do in that time, and
the feature owners can hit the estimates they make. in a shocking
development, software estimation is a really hard problem
18:25:55 <pjones> nirik: I think if we decided upon a realistic
timeframe for features we /expect/ to be in it, we can do a better
time based release.
18:26:03 <pjones> I think mechanically sticking with six months is idiotic.
18:26:12 <mitr> nirik: I'm fine with not having a _fixed_ schedule
now, but setting at least a rough expectation for the scale of
features is important I think.
18:26:28 <jwb> notting, if we're going to stick to time-based without
regard to _what_ is being put into the release, then FESCo needs big
sticks to reject/revert things that went in and aren't going to make
it
18:26:29 <nirik> pjones: we can't do that at this point... can we?
18:26:51 <notting> pjones: but if you set the release time after the
feature submission, you then limit yourself to the greatest length of
all features submitted
18:26:58 <jreznik> jwb: definitely - fesco needs that sticks and it's
probably for what fesco is here...
18:27:00 <mjg59> Proposal: Fesco writes a description of the Fedora
development model
18:27:03 <nirik> mitr: right, as it will help people determine if
something should try for f19 or f20... or whatever
18:27:16 <jwb> notting, no, not really.  you evaluate the features and
any that seem overly long-toothed you reject
18:27:16 <mjg59> And then we work out which bits of reality need to
change to match it
18:27:39 <mjg59> And then, based on that, we figure out how features
can be developed and design a schedule that fits them
18:27:52 <jwb> notting, basically, you actually pick features for the
release instead of saying SURE SOUNDS GOOD ALL THE FEATURES
18:28:17 <mmaslano> -1 I do not want change development model, just to
be more strict on unfinished features
18:28:22 <pjones> notting: no, that's only true if we set it after
feature approval
18:28:36 <mitr> jwb: OTOH, most features are small and limited-impact
enough that any one of them not making it is not a problem
18:28:45 <mjg59> mmaslano: We don't have a development model
18:28:48 <jwb> how is that OTOH?
18:28:49 <mjg59> mmaslano: We have at least three
18:28:56 <mitr> pjones: Hence my wish for at least a tentative schedule
18:28:56 <pjones> mmaslano: by that model we'd never be able to do the
anaconda UI rewrite under any circumstances.
18:29:15 <jwb> pjones, sure we would.  we'd just have f18
18:29:21 <mmaslano> I gues we do not have new anaconda in every FEdora release
18:29:24 * jreznik is ok with tentative schedule and possible
reschedule after feature submission deadline
18:29:43 <mitr> pjones, mjg59: I'm _really_ unwilling to design Fedora
schedules and processes in a way that is primarily driven by current
anaconda development model.
18:29:52 <pjones> mmaslano: you're missing the point, though.  it's
not the only big change we've ever done, just the only one we couldn't
completely half-ass for one release and fix in the next.
18:29:54 <mmaslano> jwb: pulling in only some features might be really
tricky, you would need mass rebuild after pulling all accepted
features
18:30:07 <jwb> mmaslano, there is nothing guaranteeing that
18:30:15 <jwb> it is certainly possible, but so what?
18:30:40 <pjones> mitr: And I'm not asking you to.  I am asking for a
model that makes it possible for /some/ anaconda development model to
work without causing massive problems for fedora releases.
18:30:46 <mitr> BTW,
18:30:47 <nirik> mjg59: I'd be happy to hear/see/approve/etc a
development model... do we have time to do that before deciding any
schedule? do we have people interested in drafting proposals for it?
18:30:49 <mitr> jwb: i still think blindly setting a schedule now is
irresponsible.  set a feature submission deadline, STICK TO IT, and
then flesh out the rest of the schedule
18:30:51 <mitr> had +5, sorry about missing that.
18:31:13 <mitr> Given that is agreed, can we set the feature
submission deadline now?
18:31:15 <notting> proposal: move feature submission deadline back to
1/29 (fudcon + 1 week)
18:31:21 <mjg59> +1
18:31:22 <pjones> notting: +1
18:31:24 <jwb> notting, +1
18:31:30 * nirik shrugs. ok.
18:31:37 <jreznik> mitr: +1
18:31:38 <jreznik> proposal - set tentative schedule for May and
reschedule after feature submission deadline if needed - put feature
submission earlier
18:31:39 <jreznik> + adjust the branch/alpha deadline gap
18:31:46 <mjg59> jreznik: -1
18:31:47 <pjones> jreznik: -1
18:31:54 <pjones> in fact I think we already agreed not to do that
18:31:59 <notting> (yes, not everyone will be at fudcon, but i
wouldn't want it before then)
18:32:07 <limburgher> notting: +1
18:32:26 <mmaslano> notting: why?
18:32:29 <pjones> that's +5
18:32:38 <pjones> six if we include notting
18:32:49 <mitr> #agreed: Feature sumission deadline pushed back to
1/29, we'll figure out the rest of the schedule based on submitted
features
18:32:50 <nirik> fudcon lets folks discuss and get ideas/energy for
things that they might not have wanted to push in before that.
18:32:58 <notting> mmaslano: gives people at least *some*
getting-together place to discuss things. next possible large-scale
one is devconf, and i think that's too late
18:33:08 <notting> so, i understand the 'don't set the full schedule'
18:33:18 <notting> but i think we need a 'not before' date, so we can
give feature submitters a guideline
18:33:23 <mmaslano> well great for those who will be there...
18:33:34 <nirik> notting: for final release? or ?
18:33:48 <mitr> notting: yes, we need a guideline
18:33:51 <jreznik> well, it means we are going to break the
May/October tradition - it should be communicated to the community +
probably Board/Fedora QA should be involved too...
18:33:56 <mitr> For alpha branching, I think
18:34:13 <mjg59> jreznik: Uh. I think we've already broken that tradition.
18:34:16 <mitr> s/branching/freeze/
18:34:46 <jreznik> mjg59: no - f18 is exceptional - previously we were
able to make it (+/- weeks)
18:34:46 <mjg59> notting: I've no problem with saying that final
release will not be before 05-21
18:35:11 <mjg59> And I think we should do everything we can to make a
release on that date
18:35:11 <notting> mjg59: and the branch date will not be before 02-26, etc?
18:35:17 <mjg59> notting: Sure
18:35:31 <pjones> jreznik: only because we pushed major features that
clearly couldn't land within one release, or split them in half and
made them crappy in the first of two releases.
18:35:35 <jreznik> mjg59: that is tentative schedule and we are back
to the discussion
18:35:45 <mjg59> jreznik: Not really?
18:35:50 <pjones> jreznik: no, it isn't.
18:35:55 <pjones> it's intentionally not.
18:36:21 <jreznik> how it isn't? if you say branch will be not before
date, ga not before (but we try to make it?)
18:36:30 <pjones> jreznik: it's saying that's the minimum time they
should plan for, but we may decide, before freeze, to make it longer.
18:36:32 <mitr> pjones: Hm, so which variables are left, and which are
important?
18:36:32 <mjg59> jreznik: Because changing it isn't a slip
18:36:47 <jreznik> mjg59: yes, it's tentative schedule then
18:37:01 <pjones> that's not what those words mean.
18:37:05 <mjg59> jreznik: No. We'll have a tentative schedule after
feature submission.
18:37:22 <pjones> mitr: I'm not sure what you're asking
18:37:28 <jreznik> mjg59: after? you just agreed to have that guidance dates...
18:37:50 <mitr> proposal: Announce that a) Alpha branching, when
features are expected to be testable, is tentatively scheduled for
2/26; b) it will not be earlier; c) it may be later, but we ask
feature submitters to plan features of a scale that corresponds to the
tentatively scheduled date
18:37:53 <mjg59> jreznik: Yes, guidance dates that aren't a tentative schedule
18:38:47 <pjones> mitr: -1.  "tentatively scheduled for 2/26" and
"won't be scheduled for a date earlier than 2/26" are not the same
thing, as we've *just* been saying.
18:39:23 <notting> this seems like a quibble over wording and the
importance thereof, and we're crossing native-language speaker
boundaries
18:39:32 <jwb> notting, yes
18:39:34 * nirik nods, agrees with notting
18:39:39 <mitr> pjones: If we say "you have at least 2 months to work
on your feature, but feel free to propose features that need 2 years
of work", that's not terribly useful
18:39:49 <pjones> if we say it's tentatively scheduled, it discourages
people from checking back with what the real schedule is when we
actually decide on it.
18:39:55 <mitr> AFAICS the only difference between "tentative
schedule" and "no later than" is that we don't call a slip a slip
18:40:02 <jreznik> mitr: +1
18:40:25 * notting looks for better wording
18:41:03 <pjones> mitr: that's not the only difference.  the
difference is actually that we *actually* haven't decided upon a time
frame yet, and so it /wouldn't be a slip/.
18:41:07 <pjones> It's not merely semantics.
18:41:27 <mitr> pjones: I have close to zero trust in FESCo being able
to estimate the time needed better than the feature owners.
18:41:39 <notting> proposal: fesco agrees to initially target a
end-of-may release with end-of-february  branch date, but may adjust
outwards depending on submitted features.
18:41:43 <jreznik> we really need better wording
18:42:00 <jwb> mitr, nobody has suggested otherwise
18:42:07 <pjones> mitr: that's ironic, because how time estimates are
one of the things we basically don't ask feature owners.
18:42:10 <limburgher> notting: +1
18:42:15 <pjones> s/how //
18:42:21 <drago01> pjones: maybe we should
18:42:26 <pjones> drago01: indeed.
18:42:28 <drago01> s/maybe//
18:42:32 <mitr> pjones: I alwasys interpreted that as "We ask them
implicitly by setting a schedule"
18:42:35 <limburgher> pjones: I think they're supposed to be implied.
18:42:43 <jwb> clearly hasn't worked
18:42:47 <pjones> limburgher: that's sort of the opposite of asking, isn't it?
18:42:48 <limburgher> jwb: <nods>
18:42:58 <limburgher> pjones:  Exactly. :)
18:43:12 <nirik> notting: +1 I guess. Perhaps we could/should add that
we will decide the schedule at some date? after feature submission
deadline?
18:43:24 <mmaslano> well yes we believe they plan features doable in
the time frame
18:43:35 <jreznik> nirik: +1 as I proposed - after feature submission deadline
18:43:43 <notting> nirik: sure, tack 'after the feature submission
deadline' at the end of the statement
18:43:48 <pjones> mmaslano: except when they tell us that the features
aren't doable in that time frame we callously refuse to listen at all.
18:44:26 <mmaslano> hm when developer said with feature page proposal,
he can't do it
18:44:46 <jreznik> notting: could you repropose it with that added
after feature submission deadline?
18:44:52 <mitr> pjones: If you are talking about anaconda, I haven't
seen anything like that -
http://fedoraproject.org/wiki/Features/NewInstallerUI certainly
doesn't suggest anything like it
18:45:14 <jreznik> and also - we should set how we decide if we make
it given guidance dates or not...
18:45:18 <pjones> mmaslano: mitr: no, we discussed it *in the
meeting*.  And then we put it off for 2 releases, and finally just
forced it in regardless of the schedule.
18:45:25 <pjones> you can't be serious that you didn't notice any of that?
18:45:56 <mitr> pjones: 2 releases before F18 would be before I was in FESCo
18:46:09 <notting> Proposal: FESCo agrees to initially target a
end-of-May release with an end-of-February branch date, but may adjust
outwards depending on submitted features. Schedule will be made  at or
shortly after the feature submission deadline.
18:46:19 <jwb> notting, +1
18:46:25 <mmaslano> notting: +1
18:46:33 <limburgher> notting: +1
18:46:38 <mjg59> +1
18:46:42 <pjones> +1
18:46:46 <nirik> +1
18:46:58 <drago01> notting: what's the difference between that and
just use that schedule and then slip if needed?
18:47:09 <drago01> notting: seems like the same thing worded differently
18:47:25 <mitr> notting: +1 - would be happier with "feature owners
are asked to scope features with the feature submission deadline in
mind", considering that we apparently don't explicitly ask for that.
18:47:28 <mitr> Or do we want a different mechanism?
18:47:32 <jreznik> so two questions - we should set how we decide if
we make it given guidance dates or not and how do we want to
communicate this?
18:47:52 <mitr> #agreed FESCo agrees to initially target a end-of-May
release with an end-of-February branch date, but may adjust outwards
depending on submitted features. Schedule will be made  at or shortly
after the feature submission deadline. (+8)
18:48:10 <nirik> jreznik: well, what do you mean... we will set a
schedule after features are submitted?
18:48:13 <pjones> jreznik: We decide by having a discussion and coming
up with proposals and voting on them.
18:48:32 <jreznik> pjones: I can take care of it
18:48:57 <pjones> o_O
18:49:25 <mitr> pjones: So that means that for features submitted
early, can we or can't we -1 them based on excessive scope?
18:49:51 <pjones> of course we can.  we can -1 them for whatever reason we want.
18:49:52 <jreznik> pjones: to make it happen :)
18:50:10 <pjones> it would be best if it's not capricious, mind you.
18:50:33 <mitr> Anything more on F19 non-schedule?
18:50:53 <jreznik> mitr: yep - how do we want to communicate it externally?
18:51:07 <jwb> we... just voted on taht
18:51:09 <pjones> jreznik: ... we just approved fairly specific language.
18:51:12 <pjones> I recommend using it.
18:51:12 <jwb> with notting's proposal
18:51:13 <nirik> devel-announce... ?
18:51:30 <mitr> jreznik: I can send the announcement, or do you want to?
18:51:32 <jreznik> jwb, pjones: people would understand it as Fedora
19 has to be released in May...
18:51:43 <jreznik> mitr: I can do it...
18:51:46 <mitr> Thanks
18:51:55 <jreznik> just the concept is really ver different to "set final date"
18:51:57 <jreznik> very
18:51:58 <mitr> #action jreznik will announce F19 features and timing
18:52:10 <mitr> Moving on...
18:52:13 <mitr> #topic #896 Refine Feature process
18:52:15 <mitr> .fesco 896
18:52:16 <notting> or un-timing, as the case may be.
18:52:17 <mitr> https://fedorahosted.org/fesco/ticket/896
18:52:17 <zodbot> mitr: #896 (Refine Feature process) – FESCo -
https://fedorahosted.org/fesco/ticket/896
18:52:22 <pjones> jreznik: if you feel that way, that would have been
a good thing to say back when we were discussing the language to
use...
18:52:24 <drago01> jreznik: well "the final schedule will be decided on xxx"
18:53:24 <nirik> mmaslano: you have some concrete proposals here for
us to act on?
18:53:40 <mmaslano> we'd like to discuss the proposal
18:53:55 <mitr>
https://fedoraproject.org/wiki/User:Mmaslano/Feature_process that is
18:54:17 <mmaslano> does anyone have a comment on anything from the
proposal? https://fedoraproject.org/wiki/User:Mmaslano/Feature_process
18:54:41 <jreznik> pjones: I like the language now - but still it
needs more care - but... I'm ok with it
18:54:51 <mmaslano> I don't think weneed to vote on it now, but I
would be glad if you read it and comment it
18:55:02 <nirik> a few things: a) standalone features that have
objections should just go to fesco not get delayed to the next
release... imho...
18:55:05 <jwb> i didn't have time to read it yet
18:55:36 <mitr> nirik: I think that's covered: "Every team on Fedora
devel can share their views and escalate feature to FESCo to go
through the regular Feature process. "
18:55:42 <mmaslano> nirik: it's about features proposed after feature
submission deadline
18:55:58 <nirik> ok, then it doesn't read right to me... but ok.
18:55:58 <pjones> "The feature will be assigned to one of FESCo
members, who will help with process in Fedora (technical help like
where to ask for different koji buildroot, it can also point out that
buildroot will be neccessary). "
18:56:04 <pjones> this seems like it's delegating rel-eng tasks to fesco.
18:56:43 <mmaslano> not really, the fesco member can help with various
task (provenpackager commits, discussion with other teams, point wher
to ask, how to mass file bugs, etc)
18:57:20 <mmaslano> for example filing bugs by script in past weren't
without problem
18:57:36 <jreznik> pjones: it's just example
18:58:05 <pjones> yes, but I'm having trouble coming up with other
examples that aren't also simply miss-delegation to fesco
18:58:39 <nirik> well, it's not that they do those tasks, its' that
they help coordinate and help the feature folks talk to the right
people, etc.
18:59:03 <pjones> I guess what I'm asking is - has that been a giant
problem that people are having?
18:59:08 <nirik> ie, 'you should file a ticket there to get this done'
'you shouldn't mass file bugs until you talk to the FPC' etc
18:59:10 <mmaslano> the thing is at least one fesco member will be
watching development of the feature closely, (s)he can help, but do
not have to. No questions about status will be needed, because the
fesco member will know
18:59:31 <mitr> pjones: Visiblity into feature status?  It's been a
major issue recently.
18:59:32 <mmaslano> nirik: yes
18:59:37 <pjones> mmaslano: that seems unrealisticlly optimistic
18:59:39 <limburgher> mmaslano: Yes.
18:59:39 <mmaslano> nirik: if you can word it better...
18:59:51 <pjones> mitr: that's a completely different thing
19:00:02 <nirik> well, if a feature doesn't need much, feature owners
may not communicate with a fesco shepard either.
19:00:07 <jreznik> and actually it fits what we agreed before for f19
schedule - there would be an overview of the scope, what has to be
done - not based on percentage in the list
19:00:32 <limburgher> nirik: Then the shepherd initiates
communication.  No response, drop the feature.
19:00:46 <pjones> and I don't see how it'll change the fact that if we
ask for percentages, people will make them up out of whole cloth.
19:01:07 <pjones> oh, actually, I misread on that.
19:01:10 <limburgher> pjones:  They've always been, and will always
be, somewhat soft.
19:01:19 <pjones> still - it's a separate thing.
19:01:21 <nirik> I guess the idea is that the fesco shepard will be
able to spend some time gathering more detailed status info on
features... not sure it will work out in practice, but meh
19:01:29 <limburgher> the shepherd will be able to estimate that as well.
19:01:52 <pjones> I don't particularly like the implicit idea that
people serving on fesco have a lot of spare time to spend on other
peoples' features.
19:02:16 * Southern_Gentlem hopes for maybe 1-2 features for f19 so it
wont take so long to get out the door
19:02:25 <limburgher> pjones: It isn't necessarily a large time
commitment.  That it is for a feature is itself a possible warning of
trouble with that feature.
19:02:27 <drago01> nirik: and how would that work for a feature like
lets say SB?
19:02:27 <mitr> Bridging the communication gap when FESCo and feature
owners start with different assumptions would be the primary benefit
19:02:41 <drago01> nirik: where even the owners cannot give a timescale
19:02:43 <pjones> limburgher: that isn't really how it reads
19:02:43 <jwb> nirik, if it isn't going to work out in practice, then
it would be silly to agree to do it
19:02:43 <nirik> drago01: as well as with anything else?
19:02:44 <limburgher> mitr: Yes.
19:02:55 <mitr> pjones: We expect most of the current features to fall
in the "self-contained" category, so there should be 1-2 feature per
member at most
19:03:08 <pjones> mitr: yes, that's why I'm discussing the other category.
19:03:40 <nirik> jwb: well, it might be worth trying was my point...
19:03:40 <pjones> Isn't this what the feature-wrangler is for?
19:04:20 <limburgher> shepherd=sub-wrangler
19:04:23 <mitr> pjones: Yes, this does add ask for workload beyond the
daily meeting.  OTOH I've been spending 4-8 hours a week reviewing
features in the "feature crunch" time currently, and that would go
away.
19:04:51 <mmaslano> no, wrangler is looking only on feature page and
status. He doesn't care about details, what would be broken. At least
it was the practice
19:05:43 * jreznik is willing to do more work than what feature
wrangler did before - just it would be probably insane for one person
to take care of all features... but yeah, I already did a lot of these
communication...
19:06:34 <mitr> Proposal: Announce process proposal changes on
fedora-devel, revisit next week.
19:06:52 <pjones> mitr: *blink*.  That sounds like you're saying it
gets you out of having to be prepared for the meeting.
19:06:59 <pjones> I hope that's not what you're saying.
19:07:06 <notting> mitr: proposed process changes?
19:07:06 <nirik> mitr: +1
19:07:26 <mitr> notting: right, thanks
19:07:28 <mmaslano> pjones: did you read all features before meeting,
check scope etc?
19:07:34 <pjones> mmaslano: yes.
19:07:37 <mmaslano> wow
19:07:42 <pjones> That's how I spent this morning.
19:08:05 <notting> if the problem is unclear feature-owner/fesco
communication, i'm not sure adding a fesco monitor *solves* it as much
as works around it. we'd want to *solve* it in the long term by
properly incenting that it happen, etc.
19:08:07 <pjones> (well, some of it - we have a fairly short agenda today.)
19:08:08 <mitr> pjones: For self-contained features, this means I
check the assumed scope and leave the other parts to the respective
maintainer, yes.
19:08:54 <limburgher> notting:  By being more willing to axes features, perhaps?
19:09:22 <mitr> notting: I'm not sure what can offer a feature owner
that wants to get a feature into a release to be more
realistic/pessimistic about time estimates; the urge to call it
"almost done" is fairly strong.
19:09:39 <notting> limburgher: if people think punishment is the only
way, that's kind of sad
19:10:17 <pjones> notting: and changing the process so that it's clear
that you'll actually be doing so
19:10:17 <limburgher> notting:  Agreed, I don't want it to be.
19:10:20 <mitr> limburgher: For all but the very major features,
"axing features" is mostly removing it from the relnotes and
announcements
19:10:36 <mitr> That's still something, but not really a huge stick
19:10:37 <mmaslano> imho we should tell people what to do to have the
feature ready
19:10:46 <limburgher> mitr:  True, and for things like ananconda, it's
even less. :)
19:10:49 <pjones> right now when you change percentages and whatnot,
that's absolutely *not* what you're doing, and nobody, I hope, is
operating under the assumption that they are.
19:12:32 <mitr> 15 minutes on this topic, continue?
19:13:01 <notting> for the two parts of the proposal, the first ('self
contained features') the goal is... reduce perceived fesco busywork?
19:13:09 <notting> perceived and/or actual
19:13:28 <jreznik> notting: to reduce fesco work but also to lower the
barrier to propose feature
19:13:35 <jwb> ugh
19:13:35 <mitr> notting: {fesco, feature owner}, and at the same time,
make every feature significantly more visible to fedora-devel
19:13:58 <jreznik> and visibility as mitr said
19:14:16 <notting> jreznik: if it's still a properly-filled out
feature page, barrier is the same
19:14:47 <jreznik> notting: I know many people who do not want to
propose feature because "fesco is going to nack it" - not a good
attitude, indeed :(
19:15:09 <jreznik> the same can happen with review on f-d but...
19:15:10 <jwb> i don't think this proposal really addresses the major
problems with the feature process
19:15:25 <notting> the second part of the proposal is to
increase/force better communication?
19:15:54 <jwb> jreznik, then in those situations, it's probably very
clearly NOT a feature to begin with
19:16:05 <pjones> I don't think the barrier to propose features is
very high - it's all the work after you propose them that's a pain
19:16:09 <jreznik> jwb: the major problems are features we are not
aware of... as fedup for example
19:16:15 <pjones> (where I use the term "work" quite loosely.)
19:16:24 <jwb> jreznik, this proposal doesn't do anything to address that
19:16:40 <mmaslano> jwb: how do you want to fix that?
19:16:51 <jreznik> jwb: no - it's really refinement - and not the
whole overhaul of feature process
19:17:34 <jwb> mmaslano, the ticket is open still.  i haven't gotten
time to really write down anything concrete
19:17:39 <mitr> jwb: "Feature" process started as "we need to collect
marketing items", now we see it more as "we need to coordinate
technical changes" - which sense do you use in "not a feature to begin
with"?
19:18:05 <jwb> neither?
19:18:09 <jwb> look, our feature list is bullshit
19:18:16 <jwb> there are too many damn features
19:18:23 <jwb> some of them are clearly features
19:18:30 <jwb> others are simple "UPDATE PACAKGE BOO"
19:18:37 <jwb> they're all on the list with the same weight
19:18:43 <pjones> many of those are managers telling engineers "you
need to get things on the feature list to improve visibility"
19:18:43 <jwb> most of them aren't features
19:18:44 <jreznik> btw. Board would like to make a call for FUDCon to
work on Feature process
19:18:57 <pjones> jreznik: shocking.
19:19:03 <pjones> just what does the board actually do?
19:19:36 <pjones> (not a serious question, of course.)
19:20:02 <jreznik> jwb: it depends - not the same weight from different povs too
19:20:04 <drago01> jwb: exactly
19:20:34 <jreznik> is "python 3.x" feature? it's just update - but
could lead to a massive change...
19:20:45 <mitr> jwb: This proposal would make the different weight more visible
19:20:45 <notting> jwb: well, that's what the first part of the
proposal was, was to split out... "items of note"... into a separate
category
19:20:56 <pjones> yes, clearly it is.  It's both a major technical
change and something that might cause people to use (or not use)
Fedora.
19:20:58 <notting> if we want to change more around what "items of
note" have to do, we could
19:21:05 <jwb> "Update D programming environment"  "Boost 1.50"
"Fontconfig 2.10"  none of those a features in a distribution that
FOCUSES on updating stuff every release
19:21:21 <mjg59> I don't want less review of those features by fesco.
I want *no* review of those features by fesco.
19:21:33 <jreznik> jwb: for people using D programming env - it could
be useful feature to know the changes...
19:21:34 <jwb> mjg59, yes
19:21:41 <jwb> jreznik, that doesn't make it a Feature
19:21:46 <mitr> That's 25 minutes on this topic, and I think another
group wants to use the channel in 9 minutes.
19:21:49 <jwb> it makes it something to put in the rel-notes
19:21:51 <mitr> Defer to next week?
19:21:53 <jwb> yes
19:21:56 <jwb> or fudcon
19:21:58 <pingou> mjg59: I would see, one, but just one at first
19:21:59 <jreznik> jwb: it's definitely feature for D users...
19:22:08 <jwb> jreznik, they can read it in the release notes
19:22:10 <mmaslano> I'd rather discuss it next week
19:22:11 <limburgher> next week
19:22:17 <mmaslano> not all of us will be in US
19:22:27 <mjg59> pingou: I'm sorry, I don't understand
19:22:33 <jreznik> the question is - could we delegate it? to SIGs? to devels?
19:22:46 <pjones> mjg59: I ... think he's suggesting a test run?
19:22:55 <pingou> mjg59: all features should go through fesco at least
once, other should more than one (imo of course)
19:22:55 <pjones> not sure how you'd orchestrate that.
19:23:05 * jreznik is completely ok with that too (actually it's part
of self contained features - if SIG thinks it's ok, it's ok for FESCo)
19:23:17 <mjg59> pingou: Currently all features go through fesco once.
I don't think that's desirable.
19:23:33 <jreznik> just please add comments to the ticket :)
19:24:00 <pingou> mjg59: since time is running out, let's agree to
disagree for now :)
19:24:04 <mitr> Moving on...
19:24:06 <mitr> #topic #974 Allow releases on Wed and Thu as well
19:24:08 <mitr> .fesco 974
19:24:10 <mitr> https://fedorahosted.org/fesco/ticket/974
19:24:10 <zodbot> mitr: #974 (Allow releases on Wed and Thu as well) –
FESCo - https://fedorahosted.org/fesco/ticket/974
19:24:18 <jreznik> mjg59: as I said - I'm not against delegation, it's
part of the proposal - and fesco gets just list to ack... so not even
once...
19:25:01 <mitr> I'm -1 - I think a weekly meeting overhead is about
the maximum acceptable
19:25:23 <pjones> So... the only comment was on an orthogonal issue.
19:25:25 <limburgher> I want more time to think it over.
19:25:38 <tflink> pjones: maybe I'm misunderstanding, then
19:26:04 <notting> i am... ok with the idea of shipping on days other
than tuesday in general, but against the idea of a floating release
day in the release week that's not known until 5 days before
19:26:23 <pjones> the problem is of when we can reschedule things like
the go/no-go to when we do decide to reschedule.  It has nothing to do
with the time frame and everything to do with overly constraining
ourselves on the /results/.
19:26:28 <jwb> notting, i'm sick at the moment and having trouble
parsing that sentence
19:26:42 <mitr> pjones: If there is a weekly go/no-go meeting, under
what circumstances would you use a different day than the earliest
available?
19:27:14 <mitr> And if the go/no-go meeting is not weekly, what is the
frequency?
19:27:19 <jwb> has anyone asked the mirrors?
19:27:33 <jwb> because if they don't support this, it's moot to discuss it
19:27:40 <pjones> mitr: situations like (but not exactly like) last
week where we postponed it to a holiday and could have benefit from
postponing it one more day instead, but we couldn't, because we're
married to tuesdays.
19:27:42 <jreznik> jwb: yep, mirrors are first to ask
19:27:51 <jwb> but has anyone actually asked?
19:27:59 <nirik> not that I know of.
19:28:07 <mitr> Can anyone take that action item?
19:28:09 <jwb> then i propose we revisit when someone has
19:28:16 <nirik> I think they are fine as long as we have long enouhg
to mirror stuff to them.
19:28:22 <jreznik> jwb: someone commented it in the thread why Tue was selected
19:28:27 <nirik> I can't see why they would care what day of the week.
19:28:30 <tflink> I think that final go/no-go #1 is currently
scheduled for 2013-01-01
19:28:46 <notting> jwb: i don't like the idea of deciding around
go/nogo the week before whether you're releasing the next tuesday,
wednesday, or thursday
19:28:48 <jreznik> nirik: so it's more about - time to mirror stuff
that just day of week?
19:29:10 <jreznik> nirik: you are probably closest to mirrors - could
you ask the most important ones?
19:29:11 <pjones> notting: no, but we wind up having to do that anyway
19:29:24 <pjones> because of our terminal slippage problem
19:29:25 <nirik> jreznik: I can ask on the mirror list, but I don't
know that they would care...
19:29:51 <jreznik> nirik: if they would not care - then it's ok to not
to stick with Tue
19:30:02 <notting> pjones: surely we're slipping because we *aren't*
terminating the schedule ok i'll stop myself now
19:30:18 * nirik is with tflink on the 'constant status meetings crap
because we are slipping less than a week'
19:30:28 <jwb> i've completely lost wtf we're talking about
19:30:34 <tflink> I don't really care which day of the week release or
go/no-go is, as long as we don't end up doing a perpetual "we'll
release tomorrow if all these tests pass"
19:30:41 <pjones> nirik: also agreed - but this ticket has nothing to
do with that.
19:30:43 <nirik> anyhow, proposals seem to be 'more time' or -1 on this?
19:31:40 <jreznik> tflink: it could help in that times - we have one
final blocker bug, do we want to push release by one week for this one
or not?
19:31:45 <tflink> pjones: then I'm still not following you 100%. I
understand the intent but I don't see how this isn't opening the door
to the chaos I'm concerned about
19:32:02 <notting> so, perhaps i'm misunderstanding
19:32:04 <tflink> jreznik: what about 2 blocker bugs?
19:32:06 <notting> is it:
19:32:07 <tflink> or 3
19:32:28 <pjones> tflink: it's not saying somehow that less time is
okay.  If we keep the time window the same, right now we can't move a
g/ng to friday because we can't ship on wednesday, and for no other
reason than having decided that we ship on tuesday.
19:32:36 <notting> Proposal: when scheduling a G/NG and release date
one week or more in advance, allow shifting it so that release is on
any of tuesday, wednesday, or thursday?
19:33:12 <pjones> notting: that's... pretty much exactly the proposal
in the ticket.
19:33:30 <tflink> pjones: I'm fine with that as long as there is
wording that doesn't allow for last-minute changing of dates for
release in the hope that a blocker will be fixed
19:33:31 <mjg59> tflink: This is about avoiding the case where we have
to have a G/NG on a national holiday because otherwise we have to slip
by another week because we can only release on Tuesday
19:34:13 <mitr> pjones: I don't think that notting's wording would
have solved the "we can't slip only 1 day" problem that motivates the
proposal.
19:34:31 <mitr> Or perhaps I'm confused
19:34:42 <tflink> like I said, I don't care which day of the week we
release on. I just don't want to open the door to the added chaos of
"we only need one more day, lets' move go/no-go to tomorrow and panic
while getting through all the test cases"
19:34:48 <mjg59> tflink: Given that QA are still going to be the ones
deciding when there's a G/NG meeting, I think you're free to impose
additional constraints
19:34:51 <notting> mitr: i *think* what the 1-day problem motivated
was 'if we had moved the G/NG and release date forward when we slipped
earlier, we could have avoided this', or something.
19:35:05 <notting> not necessarily 'we want to slip 1 day now'. or
perhaps i'm confused
19:35:06 <tflink> I thought that go/no-go was PM, not QA
19:35:35 <mjg59> Wait, how many definitions of PM are we up to now
19:35:45 <nirik> it's fesco/rel-eng/qa votes I thought?
19:35:59 <tflink> for go/no-go, sure but I thought he was talking
about the date of the meeting
19:36:00 <notting> QA feeds heavily into the go/nogo decision, as the
item most likely to cause a nogo
19:36:09 <mjg59> Whatever. From a *technical* perspective, which is
what fesco should be determining, I don't see any problem with this as
long as it's fine with the mirrors
19:36:29 <mjg59> If other teams want to impose additional constraints
on the timing of meetings then I think those teams should do so
19:37:02 <mjg59> Basically: Is there an engineering reason why the
release has to be on Tuesday?
19:37:10 <mjg59> If not, we should approve this
19:37:57 <tflink> depends on if you consider tester sanity an
engineering issue, I suppose
19:38:12 <jwb> i have no idea why it's even under our responsibility
to approve or reject it
19:38:28 <pjones> jwb: apparently we're the people who decided it has
to be on tuesday?
19:38:39 <pjones> and if we don't decide otherwise, who will?
19:38:48 <nirik> so, 'go/no-go can be on thursday or friday, for a
tuesday or wed release the following week'?
19:38:58 <mjg59> tflink: No, I think that's an issue that QA should handle
19:39:01 <jwb> pjones, the people responsible for releasing things?  i
think they're called rel-eng
19:39:03 <pjones> nirik: right
19:39:19 <nirik> thats much more clear to me, if thats what is being
proposed. ;)
19:39:33 <mitr> mjg59: "Development, QA, and Release Engineering meet"
from https://fedoraproject.org/wiki/Go_No_Go_Meeting?rd=Engineering_Readiness_Meetings
19:39:40 <pjones> nirik: or if it is somehow better, even saturday for
a thursday release.  I don't see when that would be better, but I'd
prefer we not limit ourselves.
19:39:57 <notting> well, inasmuch as fesco approves schedules, we
implicitly picked the tuesday dates as the ones we approve
19:39:57 <jreznik> nirik: it's one part - if we want to skip holidays
etc... other part is - do we want to do it for example if we are out
of time etc?
19:40:19 <nirik> pjones: I suppose.
19:40:19 <pjones> notting: right, but last week we thought that we
were constrained by that.  So I'd like to officially say that we're
not.
19:40:28 <nirik> jreznik: out of time?
19:40:31 <tflink> mjg59: becasuse we have so much control over what's
thown our way. I see your point, though even if I think that solution
is a tad impractical
19:40:58 <pjones> tflink: it would have been more practical than what
we actually did last week.
19:41:00 <jreznik> nirik: like we want to avoid release on Christmas
day? as we were talking about it? etc.
19:41:03 <notting> pjones: *shrug* fine with me +1
19:41:12 * pjones is also +1
19:41:27 <nirik> ok, fine +1... lets pass it and move on.
19:41:39 <limburgher> +1 as well.
19:41:43 <mjg59> +1
19:41:50 <jwb> +1
19:41:53 <mitr> +1
19:41:56 <mmaslano> +1
19:42:38 <mitr> "Releases must be on Tuesday, Wednesday, or Thursday,
but always pick Tuesday by default unless there's a specific reason
not to."
19:42:44 <mitr> Is that what we agreed upon? :)
19:42:56 <pjones> yes :)
19:43:02 <mitr> #agreed Releases must be on Tuesday, Wednesday, or
Thursday, but always pick Tuesday by default unless there's a specific
reason not to."
19:43:08 <mitr> #topic Next week's chair
19:44:28 <mitr> Would anyone like to volunteer?
19:44:33 <notting> sure, why not.
19:44:36 <mitr> Thanks
19:44:49 <mitr> #action notting will chair next wee's meeting
19:44:55 <mitr> #topic Open Floor
19:45:00 <mitr> Anything for open floor?
19:45:19 <limburgher> Not here.
19:46:09 * nirik has nothing.
19:47:01 <mitr> OK, thanks all!
19:47:04 <mitr> #endmeeting
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux