#fedora-meeting: FESCO (2014-12-03)
Meeting started by nirik at 18:00:13 UTC. The full logs are available at
* init process (nirik, 18:00:13)
* ticket #1349 Fedora 22 scheduling strategy (and beyond) (nirik,
* LINK: https://fedoraproject.org/wiki/Fedora_21_Retrospective
* will decide final schedule based on feedback from f21 release cycle
* LINK: https://fedoraproject.org/wiki/Fedora_21_Retrospective
* LINK: https://fedorahosted.org/fesco/ticket/1349#comment:24
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,
* 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)
* 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, by person
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
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
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
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
18:09:08 <nirik> heck, I guess I can make a wiki page and ask people to edit it up
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
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
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
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
18:15:49 <nirik> #info will decide final schedule based on feedback from f21 release
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
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
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
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
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
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
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
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"
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
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
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
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
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,
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
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
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
18:38:39 <tflink> sgallagh: we've gotten scolded for testing things too early,
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
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
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
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
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"
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
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,
18:44:23 <mattdm> Right so restricting change might not _necessarily_ preclude a new
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
, 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
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
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
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
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
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
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
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
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
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