Summary/Minutes from today's FESCo meeting (2014-12-03 at 18UTC)

Kevin Fenzi kevin at scrye.com
Wed Dec 3 19:12:16 UTC 2014


===================================
#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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141203/2bb7c851/attachment.sig>


More information about the devel mailing list