=================================== #fedora-meeting: FESCO (2014-12-03) =================================== Meeting started by nirik at 18:00:13 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-12-03/fesco.2014-12-03-18.00.log.html . Meeting summary --------------- * init process (nirik, 18:00:13) * ticket #1349 Fedora 22 scheduling strategy (and beyond) (nirik, 18:03:09) * LINK: https://fedoraproject.org/wiki/Fedora_21_Retrospective (nirik, 18:13:42) * will decide final schedule based on feedback from f21 release cycle (nirik, 18:15:49) * LINK: https://fedoraproject.org/wiki/Fedora_21_Retrospective (nirik, 18:16:01) * LINK: https://fedorahosted.org/fesco/ticket/1349#comment:24 makes sense to me (kalev, 18:16:02) * AGREED: jreznik_2nd will send to devel-announce: retrospective wiki page, changes must be testable by early feb 2015, and we are targeting a may release. Specific dates to come. (+6,0,0) (nirik, 18:54:22) * ticket #1369 packages should disable internal crash handlers and depend on ABRT (nirik, 18:54:49) * AGREED: Let projects continue to do as they see fit (+6,0,0) (nirik, 19:05:42) * next weeks chair (nirik, 19:05:51) * thozza to chair next week. (nirik, 19:06:49) * we will not meet on the 24th or the 31st. (nirik, 19:08:25) * Open Floor (nirik, 19:08:29) Meeting ended at 19:11:37 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (88) * mattdm (59) * jwb (57) * sgallagh (44) * jreznik_2nd (36) * kalev (27) * thozza (13) * mitr (9) * t8m (9) * adamw (8) * zodbot (6) * otaylor (5) * tflink (4) * mclasen (3) * stickster (2) * mmaslano (0) * dgilmore (0) -- 18:00:13 <nirik> #startmeeting FESCO (2014-12-03) 18:00:13 <zodbot> Meeting started Wed Dec 3 18:00:13 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:13 <nirik> #meetingname fesco 18:00:13 <nirik> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:00:13 <nirik> #topic init process 18:00:13 <zodbot> The meeting name has been set to 'fesco' 18:00:13 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:00:52 <jwb> present 18:00:52 * mattdm is here 18:01:00 <t8m> hi 18:01:04 <mitr> Hello 18:01:55 <nirik> so, I guess we have quorum today at least. ;) 18:02:04 <t8m> :) 18:02:12 <sgallagh> I'm here 18:02:20 <nirik> jreznik_2nd: you around? 18:02:36 <thozza> hi all 18:03:06 <nirik> lets go ahead and get started... 18:03:09 <nirik> #topic ticket #1349 Fedora 22 scheduling strategy (and beyond) 18:03:09 <nirik> .fesco 1349 18:03:10 <zodbot> nirik: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349 18:03:16 * jreznik_2nd is here but give me two minutes 18:03:19 <nirik> any further thoughts or discussion on this? 18:03:22 <nirik> sure... 18:03:30 <kalev> hi all 18:04:19 <mattdm> So, we're definitely running into some schedule and process related conflicts with anaconda team and qa 18:04:33 <mattdm> I don't think we can or should solve that right now 18:04:47 <jreznik_2nd> mattdm: yeah, my thoughts 18:04:55 <nirik> right, but perhaps we could/should wait on this ticket until after we do a retrospective for f21? 18:04:59 <mattdm> but we need to take some time to understand what's going on there and make some (possibly big) adjustments to fix. 18:05:07 <mattdm> nirik: yes. 18:05:10 <jreznik_2nd> but if we want may release, we have a real pressure now on having changes done asap 18:05:42 <sgallagh> As I've been mentioning all over the place, I'd like to host a FAD on revamping some of the process 18:05:54 <mattdm> sgallagh: face to face fad or vfad? 18:06:08 <sgallagh> (Things like running blocker testing earlier, tightening up the Final Freeze, etc.) 18:06:17 <sgallagh> mattdm: Probably a vFAD 18:06:44 <mattdm> sgallagh: good because I don't think we have much money left for real ones, which would put it to march or later, which is too late for f22 18:06:58 <nirik> we could start collecting things now? ie, stick up a wiki page with "problems you saw" and "good things you saw" ? 18:06:59 <jreznik_2nd> well, I didn't see any big issues this release if you take a look on all what was done 18:07:08 <mattdm> nirik: sounds good. 18:07:19 <nirik> and 'possible solutions/ideas' ? 18:07:25 <sgallagh> jreznik_2nd: Except for the last two weeks, when things got a bit hairy. 18:07:32 <sgallagh> nirik: Probably an excellent idea 18:08:00 <nirik> would anyone like to make such a thing? I could, but might not get to it for a bit as I am traveling later today and will be away/busy at a FAD. ;) 18:08:03 <kalev> I think the final release has been exceptionally smooth actually, mostly thanks to the additional freeze week I guess 18:08:18 <mattdm> I also thing we should position f22 as a ".1" release (even if we're not changing the numbering) 18:08:29 <nirik> well, until the last week, then it's back to hero testing again. ;( 18:09:01 <jreznik_2nd> kalev: we had a few issues with anaconda but it was more about not being aware of all internal processes anaconda has so it's more about having better interface to the team than anything else 18:09:05 <thozza> mattdm: what about DevConf in Brno? a lot of people will be here (I guess) 18:09:08 <nirik> heck, I guess I can make a wiki page and ask people to edit it up from there... 18:09:11 <thozza> for FAD 18:09:37 <mattdm> thozza true. did anyone submit this as a workshop for the fedora day schedule? i know we just missed the deadline 18:09:59 <mattdm> although for it to be really useful we need to get a good portion of the qa team + the anaconda team there 18:10:01 <thozza> mattdm: I can discuss this with Radek as he is doing the schedule 18:10:27 <mattdm> thozza: cool 18:11:20 <thozza> although if you can help with gathering information about who is planning to come, it would be helpful 18:11:26 <mattdm> thozza: yeah I can do that 18:11:31 <thozza> great 18:11:33 <jreznik_2nd> mattdm: I can still get it on schedule for devconf 18:11:43 <jreznik_2nd> or I expect many folks to come to fosdem 18:11:59 <kalev> one point I'd like to make is that it's easier for all teams to plan if we can put out _some_ kind of schedule 18:12:29 <mattdm> kalev: you mean beyond http://fedoraproject.org/wiki/Releases/21/Schedule ? 18:12:31 <kalev> so even if we're unsure if it's going to be the final schedule, it might make sense to put out _something_ that targets the end of may or something? 18:12:33 <jreznik_2nd> so if we want seesion on scheduling, fixing processes etc., we can just use any red hat place even not being scheduled for devconf 18:12:48 <kalev> mattdm: yes, I mean we'd need one for F22 18:12:51 <jreznik_2nd> kalev: well, it's in ticket 18:13:16 <jreznik_2nd> again no earlier - it's compromise between no schedule at all and having schedule in stone day 1 18:13:18 <kalev> yes, but that's only in the FESCo trac, it's not a place where other parties would look in 18:13:22 <thozza> jreznik_2nd: agree... and even prior to the conference itself 18:13:35 <jreznik_2nd> kalev: once fesco says yes, I'll put it into wiki 18:13:42 <nirik> https://fedoraproject.org/wiki/Fedora_21_Retrospective 18:13:52 <nirik> (stolen from the Fedora 15 one which was the last one we had) 18:13:53 <jreznik_2nd> I can do it even now with a note "this is not yet approved" 18:14:31 <mattdm> jreznik_2nd: yes please 18:14:51 <nirik> yeah, I think we want to target that timeframe... 18:14:56 * kalev nods. 18:15:10 <nirik> but we might want to move freezes and stuff around based on f21 18:15:34 <jreznik_2nd> mattdm: well, before I do that, I'd like to hear at least some feedback 18:15:49 <nirik> #info will decide final schedule based on feedback from f21 release cycle 18:15:54 <jreznik_2nd> aka it's complete nonsense, don't publish it :) 18:16:01 <nirik> #link https://fedoraproject.org/wiki/Fedora_21_Retrospective 18:16:02 <kalev> https://fedorahosted.org/fesco/ticket/1349#comment:24 makes sense to me 18:16:45 * jreznik_2nd does not have problem with publishing it, just current process was to get fesco ack first... 18:16:58 <mattdm> yeah. although with the early-january deadline we need to start socializing that to the various teams _soon_ 18:17:23 <nirik> yeah. 18:17:24 <stickster> (non member comment) Guessing from feedback in the Workstation WG meeting a couple hours ago, having *some* idea of schedule and how long the window is for change submissions is helpful 18:18:01 <kalev> yes, I too think it would be very helpful for various teams to have a published schedule, even if we plan to fine-tune it later 18:18:06 <stickster> e.g. knowing the deadline will not be before 2015-Jan-20 is still helpful 18:18:23 <jreznik_2nd> stickster: I agree 18:18:42 <jreznik_2nd> so I'll take it as ack from FESCo to publish it with notice, it may change even more 18:18:47 <mattdm> and also knowing how serious we are about that being a deadline 18:18:50 <jreznik_2nd> than just no-earlier-than 18:18:58 <nirik> right, so perhaps a devel-announce post now saying thats the changes submission deadline, mentioning the retrospective page for input and the rest of the schedule will be decided in january? 18:19:05 <jreznik_2nd> mattdm: I'm always serious about it :) 18:19:18 <mattdm> nirik +1. 18:19:32 <jreznik_2nd> nirik: that's what I expected from this meeting 18:19:47 <jwb> nirik, sounds like a good start 18:19:55 <nirik> sounds good to me. other votes or nays? 18:19:58 <kalev> sure, +1 from me as well 18:20:07 <kalev> maybe also mention the targeted release date in the post 18:20:16 <mattdm> maybe put in the post that this seems soon already because it _is_, and that we're seeing this as a "polish" release cycle? 18:20:19 <kalev> but leave the other milestones out since they are still changing 18:20:33 <thozza> nirik: +1 18:20:35 <sgallagh> I think we should talk about what each of those dates really means, but maybe that's a better topic for the FAD if we can have it soon 18:20:57 <sgallagh> I'm thinking "right after the holidays" is a good time, before people ramp back up fully but after they've had time to relax. 18:21:03 <nirik> so, do we want to mention all those dates? or just the change submission? 18:21:17 <jwb> i'd go with change submission 18:21:25 <jwb> mattdm, i'm not sure everyone is thinking this is a polish release 18:21:30 <mattdm> nirik: change submission and targeted date? 18:21:33 <jreznik_2nd> we can say "subject of change"? 18:21:47 <nirik> mattdm: sure. 18:21:52 <mattdm> jwb: not everyone in fesco, or not everyone project-wide? 18:21:53 <sgallagh> jwb: Perhaps that should be our first vote, here? 18:21:54 <jreznik_2nd> it's how "no earlier than" suppose to work 18:22:03 <jwb> mattdm, particularly since a lot of the bigger features/differentiation between products didn't land in f21... 18:22:12 <jwb> mattdm, both? 18:22:14 <jreznik_2nd> jwb: that's a good point 18:22:20 <t8m> nirik, +1 18:22:21 <nirik> jreznik_2nd: well, we might want to adjust things more given feedback... longer freezes, or something... 18:22:43 <mattdm> I'm just looking at the calendar here.... december is never a high productivity month 18:22:59 <jreznik_2nd> mattdm: and beginning of january neither 18:23:09 <mattdm> jreznik_2nd: right 18:23:21 <mattdm> and we're looking at the beginning of february for "changes complete" 18:23:34 <nirik> proposal: announce retrospective, announce change submission deadline, say we are broadly targeting may for f22? 18:23:36 <mattdm> which means either a) that's a lie or b) what time is there for _more_ than polish? 18:23:45 * jreznik_2nd was thinking about crazy idea proposing another long release cycle as we had for f21, so he understands what jwb wants to say and it could give us more time to reconsider the whole release process 18:23:56 <kalev> nirik: +1 18:24:14 <t8m> nirik, +1 18:24:15 <jwb> mattdm, if you're going to push for it being a polish release, maybe we should actually talk about that and decided on it first? i think you're assuming here 18:24:33 <jwb> unless we already did, and i've completely forgotten about it 18:24:36 <jwb> nirik, +1 18:24:36 <sgallagh> jreznik_2nd: I for one would really like for us to get back on a two-release cadence 18:24:43 <kalev> if we put out a short schedule, it inevitably ends up being a polish release since there's not much time to do anything else 18:24:49 <mattdm> jwb: we talked about it before but I don't think a strong decision was made. 18:24:50 <sgallagh> nirik: I don't want to vote on that yet, please 18:24:57 <jwb> mattdm, then we need to make that 18:25:13 <nirik> sgallagh: ok. 18:25:16 <mattdm> I actually didn't mean to be assuming -- I'm just not phrasing myself very clearly 18:25:18 <jwb> kalev, that seems reasonable, but not everyone will think that. a lot of people will just plow ahead and then we're stuck with cleanups 18:25:21 <mattdm> yes, I think we should decide that. 18:25:46 * nirik doesn't think we have ever had one of those... 18:25:58 <sgallagh> Maybe it's time 18:26:00 <mattdm> and, yeah, I _don't_ want to do a short release cycle without being clear about it 18:26:02 <jwb> nirik, not in an organized "this is a polish release" sense 18:26:15 <jwb> also... what does "polish" mean? 18:26:17 <nirik> jwb: right. 18:26:18 <mattdm> note that this isn't actually "short" — it's the nominal 6 months from this release 18:26:31 <nirik> does it mean we reject things that are not 'polish' ? :) 18:26:34 <jwb> because a lot of people are going to be like "oh! i can totally upgrade LXDE to the next version because it's prettier" 18:26:40 <jwb> (to use a contrived example) 18:26:44 <nirik> we already accepted dnf as default. 18:26:49 <nirik> thats not very polish. ;) 18:26:53 <jwb> nirik, right 18:27:04 <mattdm> maybe "polish" isn't the right word 18:27:12 <mattdm> (/shrug or maybe it is) 18:27:19 <jwb> well, define it 18:27:23 <sgallagh> Maybe we should talk about the Intel "tick and tock" approach as a better metaphor? 18:27:35 <kalev> dnf isn't the best example because it's been in the default install set since f20 -- anaconda drags it in to all live images 18:27:40 <mattdm> sgallagh: okay -- what's our tick and tock? 18:28:02 <jwb> because to me it would mean something like... Workstation doesn't upgrade underlying gnome, focuses on bugfixes, UX testing and feedback, and the common theme between GTK and qt 18:28:03 <nirik> kalev: there's still a ton of work. releng scripts, compose tools, anaconda itself isn't using it, mock, etc. 18:28:36 <thozza> kalev: and that it is installed doesn't necessarily mean it is used 18:28:49 <sgallagh> Tick: smaller changes, routine rebases, targeted at the April/May timeframe. Tock: bigger changes, targeted at the Oct/Nov timeframe. 18:28:50 <jwb> nirik, right. i think the "backend" stuff can be worked on in a polish release, if the rest of the distro isn't moving out from underneath it 18:28:53 <jwb> but... 18:29:03 <sgallagh> Or reversed, whichever 18:29:45 <nirik> sgallagh: probibly reversed as the big changes could more easily slip in the middle of the year, but the end of the year runs into holiday block 18:30:00 <sgallagh> Right, I thought the same thing just after hitting "enter" 18:30:04 <jwb> nirik, so we already did it backwards? 18:30:15 <jwb> which means f22 is Tock 18:30:25 <jwb> if we're going to get on a tick-tock schedule 18:30:30 <nirik> jwb: yeah, except this year we did 'ticktock' in one release. ;) 18:30:30 <jwb> which means not polish. 18:30:44 <jwb> STOP LIVING IN THE PAST MAN! THE FUTURE IS NOW 18:30:44 <jwb> :) 18:30:57 <nirik> :) 18:31:30 <jwb> ok, so now we have two competing ideas for what f22 is 18:31:39 <jwb> polish vs. "get us on a tick-tock schedule" 18:31:43 <nirik> at least. ;) 18:31:56 <nirik> there's also: get us back on 6mo cycle. 18:31:57 <jwb> see what you've done mattdm ? :) 18:32:10 <mattdm> jwb: yes :-/ 18:32:22 <kalev> not sure we can reach a decision on tick/tock or anything that big today 18:32:29 <kalev> but we could go with nirik's proposal above 18:32:34 <jwb> kalev, yes 18:32:45 <mattdm> nirik: right... so, are both of the ideas jwb suggested compatibile with a 6 month (that is, may) f22 cycle? 18:33:06 <jwb> (jwb summarized, not suggested) 18:33:06 <mclasen> if I may: I would really hate to get out of sync with the upstream gnome schedule again (re: not putting in a new gnome release) 18:33:11 <nirik> one problem I have deciding this right now is given the discussion between anaconda and qa folks, both wanting off the hero treadmill, I think we may need to adjust things more than just when is alpha... but when are freezes and what we test when, etc 18:33:58 <mattdm> mclasen: is having a new gnome in each release compatible with the idea of having a "tick-tock" schedule? 18:34:11 <mattdm> (Asking seriously.) 18:34:18 <mclasen> tick-tock schedule doesn't make much sense to me, tbh 18:35:02 <mattdm> I take that as a "no"? 18:35:25 <sgallagh> mclasen: Doesn't make sense in that you don't understand it or don't think it solves a problem? 18:35:32 <nirik> so, I think perhaps we should focus today on shorter term... can we give people some guidance? (whatever form that would take) for f22? 18:35:43 <mattdm> And presumably it's certainly not compatible with the idea of a strongly polish-focus release. 18:35:49 <jreznik_2nd> nirik: the answer is simple - get that automation, CI etc. in place but that means, we have to skip another release and really, really work on tooling 18:35:53 <mclasen> sgallagh: it may solve a problem, but it creates a bunch of other problems at the same time 18:36:11 <mattdm> nirik: well, I think we're basically agreed on a may target, _whatever_ that means. 18:36:13 <sgallagh> jreznik_2nd: not exactly 18:36:18 <nirik> jreznik_2nd: I'm not sure that would solve things, wouldn't hurt for sure... 18:36:35 <kalev> I don't think we'd gain that much from skipping another release 18:36:40 <sgallagh> We *could* do the polish release where we strongly limit change and let the set of people that need to work on automation go do it. 18:37:04 <jreznik_2nd> it would help a lot, not sure about skipping but we really need to know release blockers earlier without killing qe guys 18:37:26 <jreznik_2nd> and this time we had very nice and early coverage 18:37:26 <nirik> and anaconda and releng 18:37:44 <sgallagh> jreznik_2nd: Yes. I think one thing we can do there is require that all release criteria are tested at Alpha, and blockers for Beta and Final filed *at that time* 18:37:47 <jreznik_2nd> and other folks in release... or just get more contributors :) 18:38:20 <sgallagh> Rather than the current approach of only testing criteria once we enter Beta or Final Freeze and then having a week to fix it. 18:38:27 <nirik> sgallagh: of course some tests may be blocked by bugs that exist then. 18:38:39 <tflink> sgallagh: we've gotten scolded for testing things too early, though 18:38:40 <jreznik_2nd> sgallagh: and you're back to killing qe without tools... what helped final was earlier tc, not earlier freeze but earlier tc meant huge pressure on qe and we're back in circle 18:38:44 <sgallagh> nirik: Sure, but it's still an improvement 18:39:04 <mattdm> sgallagh this is an interesting idea but maybe is part of the bigger discussion? 18:39:05 <sgallagh> tflink: By whom? Send them to me, please. 18:39:12 <jwb> so, the thing that prevented us from doing that this release is what? 18:39:15 <jreznik_2nd> sgallagh: criteria are in place from alpha 18:39:33 <jwb> afaik, it's lack of resources to do the testing. either automated or human 18:39:41 <jreznik_2nd> jwb: yep 18:39:47 <jwb> did magic happen between now and then and we suddenly fixed that? 18:40:01 <sgallagh> jreznik_2nd: The pressure on QA is the same if we do nine release-validations at Final or three of them at each phase. 18:40:02 <jreznik_2nd> and lack of resource in installer team and many other places, maybe we try too much? 18:40:08 <tflink> lack of resources to do testing and there's not a whole lot of control over when things land outside of freezing 18:40:23 <sgallagh> Arguably less, since they're more likely to catch stuff with time for it to be solved. 18:40:32 <sgallagh> So QA isn't in the position of trying to demand a slip all the time. 18:40:36 <tflink> sgallagh: I'll have to dig through my IRC logs but I recall being scolded by anaconda devs for testing final stuff too early "before it was ready" 18:40:54 <jwb> so if the focus of F22 becomes "get us in a place where we can do releases without heroes", then what should we focus on to do that? 18:41:07 <sgallagh> tflink: After the conversation I had with them today, if you ever here that from them again, I'd be shocked (and angry) 18:41:11 <tflink> sgallagh: but that wasn't F21, probably 19 or 20 18:41:12 <sgallagh> s/here/hear/ 18:41:23 * nirik thinks this is a great question, but we don't have all the right people here to answer it. 18:41:27 <mattdm> jwb: I can get on board with that focus 18:41:31 <sgallagh> jwb: I think that's a really good focus 18:42:00 <kalev> I'm not sure it's possible, but worth a try :) 18:42:04 <jwb> then we'd mostly be focusing on backend. which means back to a restricted amount of change 18:42:20 <mattdm> yes 18:42:35 <jwb> but you still have the "we don't have enough people" problem 18:42:37 <otaylor> I don't think restricting amount of change is in *general* feasible, since we don't control the development of a big chunk of the development in FEdora 18:42:53 <jwb> getting the rest of the distro to stop moving helps the existing resources we have, but it isn't a solution 18:43:03 <jwb> otaylor, also true 18:43:16 <jwb> otaylor, but a big chunk honestly doesn't matter in most cases 18:43:39 <mattdm> Managing change in areas which affect the release process. Releng, qa, and critical path. 18:43:41 <otaylor> I do get the sense taht all parts of Fedora aren't equally likely to cause slips - (especially considering our "does it install, update, and log in" release criteria) 18:43:42 <jwb> we'd have to restrict critpath, some extra libraries perhaps, etc 18:44:23 <mattdm> Right so restricting change might not _necessarily_ preclude a new Gnome release? 18:44:40 <jwb> mattdm, except anaconda uses it 18:44:41 <adamw> mattdm: so there's an interesting effect there 18:44:42 <mattdm> Although it has potential impact on Anaconda 18:44:42 <otaylor> mattdm: lots of gnome is critpath (and lots not) 18:44:52 <adamw> which is that we kind of half-ass the desktop requirements 18:44:56 <mattdm> ooh everyone at once! 18:45:21 <adamw> if we actually were as strict on the desktop as we were on anaconda, it'd probably be just as likely to cause blockers, we'd be on their ass for regressions between 3.12 and 3.14 or whatever 18:45:35 <adamw> in practice, most desktop testing doesn't go a lot beyond 'log in and click around a bit' 18:45:38 <mattdm> adamw: so, as part of this, maybe asking workstation wg to decide on how... full-ass they want to be with that? 18:46:03 <nirik> well, adding a bunch of testing seems unlikely to meet a goal of 'no hero releases' :) 18:46:03 <adamw> the strictest desktop test is probably https://fedoraproject.org/wiki/QA:Testcase_desktop_menus , but even that doesn't require the apps to do much beyond start up without crashing, and half the time violations of it get fudged anyway 18:46:13 <otaylor> To me, the most important thing is not *preventing* changes, but making sure that there is a clear line of responsibility between the person making the change (or the person pulling it into Fedora) and the effect it has on the release criteria 18:46:26 <adamw> right, i'm just saying that the only reason some bits of critpath don't cause as many slips as others is we don't have such strict requirements for them 18:46:28 <sgallagh> nirik: Part of my plan for the FAD will be to go through the criteria and tighten it up, possibly discarding pieces that are no longer worth blocking on. 18:46:41 <adamw> sgallagh: i've been progressively doing that since f19, fwiw. 18:46:51 <nirik> yeah, thats a living process... 18:46:54 <nirik> happens all the time 18:46:55 <otaylor> Which of course gets back to tools - its a lot easier to say that the more we have automated composes and testing 18:46:55 <sgallagh> adamw: Thanks for that 18:47:04 <jreznik_2nd> otaylor: +1 18:47:21 <adamw> right. the better our test coverage, the saner this whole complex. 18:48:12 <nirik> anyhow, do we want to actually decide something today? or punt to next week? or just keep discussing high level? 18:48:46 <sgallagh> Well, this is all relevant to "What does the F22 schedule look like" 18:49:29 <mattdm> Are we all agreed on a May target plus "This means changes need to be complete by the beginning of Februrary, which isn't that far off, with the holidays and all?" 18:49:37 <nirik> sure. I'm happy as the next person to discuss the general ideas here, except I have about 50 things to do today before I get on a plane, so it's not as exciting as it normally would be. Also, we have a RC5 to make and test and such 18:49:41 <kalev> mattdm: yes 18:49:58 <jwb> mattdm, i guess 18:50:11 <mattdm> jwb: Do you want to nail down more specifics now? 18:50:15 <nirik> "complete" ? is that 'testable'? submitted? 18:50:32 <jwb> mattdm, no, because i don't think we can today in a reasonable amount of time 18:51:00 <jwb> mattdm, i simply didn't want the announcement to say "this is a polish release" or whatever without actually deciding it was 18:51:13 <mattdm> jwb: *nod* 18:51:15 <jwb> so, give the facts and only the facts and we're fine 18:51:28 <jwb> we can figure the rest out on the fly like we always do 18:51:29 <sgallagh> worksforme 18:51:33 <kalev> yes, let's continue the discussion, but at the same time put out a crude schedule to have something that other parties can target 18:51:34 <nirik> I'm +1 to may target and reminder that changes need to be testable by early feb. 18:51:43 <kalev> I'm +1 as well 18:51:51 <sgallagh> Though I'd like to have a more concrete definition before we disappear for the holidays 18:52:03 <nirik> jreznik_2nd: you can send the announce? 18:52:07 <mitr> +1 18:52:08 <mattdm> "testable" is nicely defined at https://fedoraproject.org/wiki/Changes/Policy#Change_Checkpoint:_Completion_deadline 18:53:01 <nirik> proposal: jreznik_2nd will send to devel-announce: retrospective wiki page, changes must be testable by early feb 2015, and we are targeting a may release. Specific dates to come. 18:53:12 <nirik> how does that sound? did I miss anything? 18:53:23 <jwb> looks good 18:53:39 <mattdm> yes good 18:53:46 * kalev nods. 18:54:01 <sgallagh> yes 18:54:22 <nirik> #agreed jreznik_2nd will send to devel-announce: retrospective wiki page, changes must be testable by early feb 2015, and we are targeting a may release. Specific dates to come. (+6,0,0) 18:54:28 <nirik> anything else on this now? or move on? 18:54:41 <sgallagh> I suppose we should move on 18:54:49 <nirik> #topic ticket #1369 packages should disable internal crash handlers and depend on ABRT 18:54:49 <nirik> .fesco 1369 18:54:50 <zodbot> nirik: #1369 (packages should disable internal crash handlers and depend on ABRT) – FESCo - https://fedorahosted.org/fesco/ticket/1369 18:54:59 <nirik> not too much change on this from previous weeks. 18:55:20 <kalev> KK and other KDE folks left some feedback there after the last fesco meeting, I believe 18:55:48 <nirik> yeah 18:56:44 <nirik> we could make it 'no 3rd party crash handlers, unless acked by fesco' but then thats more busy work... 18:56:51 <sgallagh> proposal: Let projects continue to do as they see fit for now and revisit it in the future. 18:57:27 <nirik> sharkcz just wanted a suggestion I think orig... 'please don't use your own' 18:57:28 <mattdm> +1 18:57:35 <mitr> sgallagh: revisit when/why? 18:57:44 <jreznik_2nd> nirik: I'll do it tomorrow morning, have to go now 18:58:01 <sgallagh> mitr: In the undefined future, ideally after I've left FESCo :-P 18:58:12 <kalev> I'd cut out the revisit part and just say 'Let projects continue to do as they see fit for now' 18:58:16 <mitr> sgallagh: Then just srike that non-promise? 18:58:21 <mitr> strike 18:58:23 <sgallagh> Sure 18:58:39 <sgallagh> proposal: Let projects continue to do as they see fit. 18:58:52 <jreznik_2nd> btw. abrt guys offered abrt/retrace server to kde upstream at akademy but seems it gots stuck 19:00:00 <mitr> I… guess… +1; not because standardizing on abrt would be bad but because what would actually help sharkcz is avoiding broken/non-standard handlers 19:00:03 <nirik> does abrt work on secondary arches? 19:00:13 <t8m> What about proposal: FESCo recommends using abrt but in general the projects can continue to do as they see fit. 19:01:16 <sgallagh> t8m: I don't think that's functionally any different. If FESCo isn't making a demand, projects will just continue as they were anyway (in most cases) 19:01:17 <mitr> t8m: I think that makes most sense, OTOH on more recommendation nobody will ever see unless they read _this_ meeting log (and no, making it a paragraph in packaging guidelines would not be better) 19:01:47 <t8m> sgallagh, I know 19:02:02 <mitr> I.e. either prohibit the non-standard ones (and make it an automatically-verified guideline), or we can express a preference but it will matter little. 19:02:04 <jwb> sgallagh, projects are going to continue to do what they want regardless of FESCo's demand 19:02:38 <jwb> this is, again, an upstream issue really. i don't think many projects are going to add support for swappable/disable-able crash handlers 19:02:57 <sgallagh> Well, in this case, I don't really see that FESCo is going to have any impact here, so we should just acknowledge that and get on with our lives. 19:02:58 <jwb> firefox can be built without it's own and is on non-x86 19:03:00 <mattdm> basically since we don't have a crack team of coders proficient in all software, we have only the big hammer of "ban the package!" at our disposal for things like this 19:03:00 <mitr> Upstream project, yes; downstream packages, hopefully not (this might be naive but if we can do nothing that upstreams don’t do what are we doing here?) 19:03:02 <jwb> that's about the best we cna hope for 19:03:04 <nirik> perhaps abrt could make a breakpad like thing that project could plug in. ;) 19:03:25 <jwb> mitr, it's not "we can do nothing". it's "is forking the package worth the effort?" 19:03:27 <nirik> I guess +1 to sgallagh's proposal. 19:03:29 <mattdm> and we should reserve that for last resort 19:04:59 <nirik> thats 3 votes for sgallagh (assuming he's +1 to his own proposal) 19:05:05 <t8m> ok +1 to sgallagh anyway 19:05:22 <sgallagh> yes, +1 19:05:32 <kalev> +1 from me too 19:05:36 <jwb> +1 19:05:42 <nirik> #agreed Let projects continue to do as they see fit (+6,0,0) 19:05:51 <nirik> #topic next weeks chair 19:05:51 <jwb> aspiring packagers can write patches to help if they want 19:05:58 <nirik> who wants it next week? 19:06:06 <jwb> i'll likely miss next week 19:06:11 <thozza> I can do that 19:06:13 <t8m> Me too 19:06:15 <nirik> also we might decide/note that we are not meeting on the 24th and 31st 19:06:30 <nirik> and possibly the 17th. 19:06:36 <t8m> miss next week that is 19:06:38 <nirik> thozza: thanks. 19:06:49 <nirik> #info thozza to chair next week. 19:07:09 <nirik> do we want to decide on those other dates? I will definitely not want to meet on the 24th and 31st. 19:07:15 <mattdm> definitely note missing 24th and 31st. 19:07:19 <nirik> I could meet on the 17th or not 19:07:35 <thozza> I can do it on 17th 19:07:43 <mattdm> I will be around on the 17th 19:07:46 <thozza> but definitely not on 24th and 31st 19:08:06 <kalev> I'll be around on the 17th as well 19:08:10 <jwb> yeah, i'll be around on the 17th 19:08:13 <nirik> ok. 19:08:25 <nirik> #info we will not meet on the 24th or the 31st. 19:08:29 <nirik> #topic Open Floor 19:08:36 <nirik> anyone have anything for open floor? 19:08:46 <sgallagh> Not I 19:09:06 <thozza> nope 19:09:16 <nirik> oh, I am going to be traveling and will not make the go/no-go tomorrow... will someone else from fesco be there? usually they want a go from fesco rep... not that we have any blockers I know of. 19:09:31 <mattdm> I will be there 19:09:51 <nirik> cool. ;) 19:10:02 <nirik> I'll close out the meeting in a minute or two if nothing else. 19:11:34 <nirik> thanks for coming everyone. 19:11:37 <nirik> #endmeeting
Attachment:
pgpP4nXMrzW9r.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
