17:00:22 <mattdm> #startmeeting FESCO (2014-10-22)
17:00:22 <zodbot> Meeting started Wed Oct 22 17:00:22 2014 UTC.  The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:24 <mattdm> #meetingname fesco
17:00:24 <zodbot> The meeting name has been set to 'fesco'
17:00:26 <mattdm> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza
17:00:26 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza
17:00:27 <mattdm> #topic init process
17:00:36 <mattdm> hello everyone!
17:00:41 <mattdm> or, anyone :)
17:00:49 <t8m> hi all
17:00:52 <jwb> hi
17:00:57 <dgilmore> hola
17:01:18 <jreznik_pp> /me has flat owner's meeting now but ChangeSet seems to be almost completed
17:01:18 <mattdm> dgilmore: you safely in managua?
17:01:21 <mitr> Hello
17:01:23 <kalev> hola
17:02:14 <mattdm> I think nirik said he couldn't make it and I assume sgallagh is paying attention to the other meeting
17:02:29 <sgallagh> I'm dividing my attention
17:02:40 <sgallagh> So if I started out as a half-wit, that would make me...
17:02:45 <dgilmore> mattdm: I am
17:03:05 <mattdm> I have a press interview later this afternoon so I want to not go too long here
17:03:14 <mattdm> so, followups...
17:03:20 <mattdm> #topic #1355 Please select Engineering Representiatve for the new Fedora Council
17:03:23 <mattdm> .fesco 1355
17:03:24 <zodbot> mattdm: #1355 (Please select Engineering Representiatve for the new Fedora Council) – FESCo - https://fedorahosted.org/fesco/ticket/1355
17:03:25 <mattdm> https://fedorahosted.org/fesco/ticket/1355
17:03:26 <mattdm> https://lists.fedoraproject.org/pipermail/devel/2014-October/203391.html
17:03:49 <mattdm> also
17:03:52 <mattdm> https://fedoraproject.org/wiki/User:Jwboyer/Fedora_Council_Engineering_Rep
17:04:22 <mattdm> First step: proposal: ratify the fedora council engineering rep as official policy
17:04:30 <mattdm> ^ rep draft doc
17:04:37 <mitr> +1
17:04:40 <mattdm> +1
17:04:46 <t8m> +1
17:04:53 <kalev> +1
17:05:06 <jwb> +1
17:05:07 <sgallagh> +1
17:06:05 <mattdm> #agreed fedora council engineering representative draft is accepted as official fesco policy (+6 / 0 / -0)
17:06:37 <mattdm> jwb can you move that page to somewhere official and add appropriate categories?
17:08:17 <jwb> sorry, yes
17:08:24 <jwb> (rawhide is not being kind)
17:08:38 <mattdm> #action jwb to move draft to somewhere official and add appropriate categories
17:08:47 <mattdm> so next, actual selection
17:08:54 <mattdm> We have three nominees
17:09:20 <mattdm> jwb, stickster (you around) and josef
17:09:35 <mattdm> you around? is a question :)
17:10:20 <mattdm> I talked to josef some in the ticket; as noted there, I think we're really looking for someone more currently active for this role
17:11:00 <mattdm> (and I think the general election process for the other seats is probably more of what he's looking for)
17:11:15 <mattdm> anyone else is free to have any comments or opinions here :)
17:11:45 <t8m> I think the person being FESCo member is a plus so I am for jwb
17:11:49 <sgallagh> As jwb has been a voice of sanity on the Board in the past, I trust him to be the same on the Council. So I'd like to third his nomination
17:11:57 <stickster> mattdm: I'm back.
17:12:07 <mattdm> stickster we are talking about you :)
17:12:20 <stickster> I have an alibi.
17:13:21 <mrunge> IMHO it would be great, to spread the load onto more shoulders than before
17:13:23 <mattdm> I think either stickster or jwb would be good for this role
17:13:34 <kalev> I would like to have both jwb and stickster on the new council :)
17:13:36 <kalev> but like sgallagh says, jwb has been a voice of sanicty there, and I too would like that to continue above all
17:13:48 <mitr> jwb has directly demonstrated the required ability as the Workstation WG liaison, and when he disagrees with me, he is usually right ☺
17:13:49 <jwb> both is still possible
17:13:57 <jwb> mitr, aww :)
17:14:09 <mattdm> I also hope that neither will be offended if I lean towards one over the other :)
17:14:35 <jwb> i won't.  and fwiw, i intend to run for election if i'm not picked.  i would imagine stickster might do the same
17:14:40 <stickster> I won't
17:14:46 <stickster> I mean, I won't be offended.
17:14:49 * mattdm wasn't really worried :)
17:15:14 <mattdm> any case as seems to be the general consensus anyway I think jwb is the best choice right now
17:15:18 <stickster> Full disclosure -- I self nominated in part out of concern that jwb carries a lot of responsibilities
17:15:27 <mattdm> so does stickster :)
17:15:31 <jwb> heh.  so do you
17:15:50 <mattdm> Do we need to let the two of you fight that out? :)
17:15:55 <jwb> i took this into consideration before i agreed.  it's not much different than what i was already doing on the pre-existing board
17:16:00 <stickster> But I can work with jwb to help him out in other areas if needed
17:16:05 <stickster> jwb++
17:16:07 <mattdm> okay so...
17:16:11 <jwb> FIGHT TO THE CRY OF UNCLE
17:16:22 <mattdm> proposal: jwb for fedora council engineering representative
17:16:28 <stickster> jwb: This seems not fair. Can't we have a sing-off?
17:16:42 <jwb> stickster, hm.  perhaps an eating contest
17:16:48 <t8m> mattdm, +1
17:16:52 <kalev> mattdm: +1
17:16:54 * dgilmore votes for jwb
17:16:56 <jwb> mattdm, abstain
17:16:57 <sgallagh> Oboes at dawn?
17:17:07 * mattdm is +1
17:17:12 <sgallagh> +1 jwb
17:17:17 <dgilmore> +1
17:17:19 <mitr> mattdm: +1
17:17:51 <mattdm> #agreed FESCo selects Josh Boyer (jwb) as Engineering Representative for Fedora Council (+6,-0,1)
17:18:12 <jwb> thanks all.  i'm honored
17:18:13 <mattdm> #info congratuations josh
17:18:27 <mattdm> not getting off so easy after all of this governance reorganization after all :)
17:18:37 <jwb> heh
17:18:43 <mattdm> #topic #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline
17:18:45 <mattdm> .fesco 1322
17:18:46 <zodbot> mattdm: #1322 (F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline) – FESCo - https://fedorahosted.org/fesco/ticket/1322
17:18:46 <mattdm> https://fedorahosted.org/fesco/ticket/1322
17:18:49 <mattdm> jreznik_pp: ?
17:19:20 <stickster> jwb: I'LL GET YOU AND YOUR LITTLE DOG TOO!
17:19:23 <jwb> heh
17:20:38 <mattdm> so it looks like from jreznik_pp's comment in the ticket that everything is settled except the uboot/arm thing which is waiting on dgilmore?
17:20:44 <mattdm> dgilmore do you have an update?
17:21:26 <dgilmore> mattdm: grubby patches are in TC4
17:21:36 <dgilmore> it should get moved to ON_QA now
17:21:40 <mattdm> awesome.
17:22:05 <mattdm> so unless jreznik_pp shows up and has more to say, move on to next ticket?
17:23:01 <jwb> yes
17:23:05 <mattdm> #topic #1357 please consider django-1.7 as late feature for f21
17:23:07 <mattdm> .fesco 1357
17:23:08 <zodbot> mattdm: #1357 (please consider django-1.7 as late feature for f21) – FESCo - https://fedorahosted.org/fesco/ticket/1357
17:23:08 <mattdm> https://fedorahosted.org/fesco/ticket/1357
17:23:12 <mattdm> ping mrunge, sgallagh
17:23:20 <mrunge> pong mattdm
17:23:23 <sgallagh> pong
17:23:34 * mattdm is overwhelmed, ducks
17:24:11 <mrunge> so briefly: we have Django-1.6 in F21 until now
17:24:32 * dgilmore things that getting django updated is fine but I am not for having it as a feature
17:24:40 <mrunge> if we go that route, it will be probably unmaintained by upstream during f21 lifecycle
17:24:42 <dgilmore> thinks even
17:24:54 <t8m> I think we are very past the line where it would be OK to update
17:25:09 <mrunge> changes are not that big
17:25:17 <sgallagh> We're past the line where an update without maintaining 1.6 is unacceptable to me
17:25:21 <kalev> does the Server WG have an opinion on that? I think it's their turf.
17:25:30 <mattdm> mrunge the new Fedora Security Team may be able to help backport patches if absolutely necessary
17:25:43 <sgallagh> kalev: Django isn't part of our Server platform (yet?)
17:25:47 <mitr> Looking at the 1.7 changelog and https://docs.djangoproject.com/en/dev/releases/1.7/#backwards-incompatible-changes-in-1-7 , this seems far from a smooth upgrade
17:25:51 <t8m> If changes are not that big, backporting high severity security patches should not be a problem
17:25:52 <mattdm> I can see the "past the line" argument.
17:25:57 <mrunge> Debian has Django-1.7 in their upcoming release
17:26:06 <sgallagh> ReviewBoard cannot run in 1.7 (for example)
17:26:06 <mrunge> https://packages.debian.org/jessie/python-django
17:26:13 <jwb> how is debian relevant here?
17:26:26 <sgallagh> Anyone else relying on django_evolution will be broken also, until that package is updated
17:26:26 <mrunge> just as a pointer: others do it
17:26:38 <jwb> that's not helpful
17:26:58 <mrunge> yeah, Django-1.7 integrated south for database migrations
17:27:01 <mattdm> so, is it feasible to ship python-django16, or does it need to be  python-django17 with the special name?
17:27:14 <mattdm> (if we go the ship-both route)
17:27:18 <mrunge> mattdm, that would absolutely be possible
17:27:51 <mrunge> sgallagh, said: ship parallel installable python-django16 and python-django in version 1.7
17:27:53 <mattdm> that'd require anything that really requires 16 to change dependencies, and would possibly break things on update, right?
17:28:13 <mrunge> yes
17:28:15 <sgallagh> mattdm: Probably not
17:28:19 <mattdm> (that's not necessarily a show-stopper in the land of fedora upgrades, just wanted to be clear)
17:28:25 <mattdm> sgallagh: why not?
17:28:31 <sgallagh> We had this with python-django15 and python-django (1.6) in the pasyt
17:28:33 <sgallagh> *past
17:28:54 <sgallagh> Hopefully, most Django packages are doing versioned Requires at this point
17:28:57 <mattdm> mrunge is the main concern with doing this the effort to support two, or that the EOL is looming?
17:29:03 <sgallagh> So they should just pull the right one
17:29:26 <mrunge> sgallagh, I really doubt that
17:29:48 <mrunge> IMHO reviewboard was the only application using parallel installable django
17:30:00 <mrunge> but I may be wrong
17:30:38 <mrunge> in the past, I had 3 django packages to update on two to three distributions
17:30:49 <mrunge> so: the fewer, the better (for me)
17:30:57 <mitr> sgallagh: They may be doing Python versioned requires, but how would they do a versioned RPM require that matches python-django [1.6] and python-django16 but not python-django [1.7]?
17:31:18 <mitr> sgallagh: At least I can’t see any Provides: that could do that in http://pkgs.fedoraproject.org/cgit/python-django.git/tree/python-django.spec
17:31:28 <kalev> my gut feeling is that having a 'django' + 'django16' package makes parallel installability harder than necessary, and it would be cleaner to go with 'django17' + 'django16'
17:31:43 <sgallagh> kalev: The problem with that is upgrades
17:31:55 <sgallagh> It would have been easier from the start, but harder now
17:32:01 <t8m> I think we shouldn't really try to solve such technical details now.
17:32:05 <mrunge> sgallagh, +1 right
17:32:07 <mitr> (Talking to upstream about longer-term API stability might be in order…)
17:32:38 <mrunge> there is a long time supported version django-1.4
17:32:43 <sgallagh> mitr: http://pkgs.fedoraproject.org/cgit/python-django15.git/tree/python-django15.spec?h=epel7&id=93d709c42b1b3fd0e848e15da6df7b51fca8162b
17:32:44 <mrunge> supported until March 2015
17:32:44 <mitr> Given the timing, I think we should strongly bias towards doing in GA the same thing, or a thing as similar as possible, to what will ship in Beta.
17:32:45 <t8m> And I am still -1 to the update
17:33:05 <kalev> anyway, I think we have two separate problems to solve here
17:33:07 <kalev> 1) do we allow django 1.7 in the repos?
17:33:08 <kalev> 2) do we kill off django 1.6 from the repos?
17:33:13 <sgallagh> mitr: Well, to be fair, they announce backwards-incompatible changes 9 months in advance
17:33:28 <kalev> (1) is difficult right now because of the naming.
17:33:29 <sgallagh> That's a lot better than most upstreams
17:33:30 <mitr> sgallagh: What am I looking for?  No Provides tag at all AFAICS
17:33:38 <mattdm> kalev: agreed
17:33:51 <sgallagh> mitr: You're right; that's the wrong version.
17:33:57 <mattdm> although with python-django17 there's no issue
17:34:00 <sgallagh> Maybe I'm misremembering how we did htat
17:35:57 <kalev> I would approach this incrementally: (a) add a new parallel-installable django17, (b) port everything in the repos over to use django17, (c) if b is completed before F21 final, approach fesco to retire django 1.7, (d) continue using djangoXX packages in the future to make parallel installing easier
17:36:15 <kalev> err, (c) is to retire 1.6
17:36:27 <mrunge> I can go with the proposal: update python-django to 1.7 and introduce python-django16 the same way we did last time with django-1.5
17:36:40 <mitr> kalev: (c), breaking existing scripts and dropping security updates during a release, is really unpalatable to me.
17:37:00 <mattdm> So basically four options are: I) just 1.7  II) 1.7 as main name, 1.6 as compat (mrunge suggestion) III) 1.7 as compat, 1.6 as main name IV) both with "compat" names (kalev suggestion)
17:37:34 <mattdm> III has the advantage that it doesn't require anything special from us. :)
17:37:55 <sgallagh> Not actually true, unfortunately
17:38:02 <sgallagh> (Complicated reason)
17:38:11 <t8m> mattdm, you forgot V) just 1.6
17:38:12 <mattdm> sgallagh: why's that?
17:38:14 <sgallagh> I'm for II), obviously
17:38:16 <mattdm> t8m: true
17:38:19 <mitr> Due to the required Provides: tags to keep compatibility (either right now or later), III and IV seem pretty equivalent
17:38:39 <mitr> t8m: III seems clearly superior to V _if_ there is someone interested to do the work.
17:38:50 <mattdm> VI) drop django entirely :)
17:39:04 <mrunge> fine with me.
17:39:10 * mrunge ducks
17:39:22 * sgallagh looks for his musket
17:39:26 <mitr> mattdm: (grumble: A distribution with high stability standards would actually do that.  But that’s not the distribution and user base we have.)
17:39:31 <kalev> my preferred approach is (III), since this can be evolved into (I) if all the porting work is completed before the F21 release
17:40:06 <mrunge> hmm, most of our django packages are leaf packages
17:40:10 <mitr> kalev: No, removing a package during a release lifetime is about impossible.
17:40:12 <sgallagh> kalev: I know that at least the Review Board upstream won't support 1.7 until they release 2.1 (probably in December sometime, but maybe January)
17:40:15 <mrunge> introduced, when askbot was around
17:40:22 <sgallagh> (RB 2.1, I mean)
17:40:49 <kalev> mitr: yes, that's what I'm saying all the time: if the porting gets completed before F21 is shipped, then we can retire django 1.6; otherwise keep it around for the F21 lifetime
17:41:09 <t8m> sgallagh, so what's the problem with III?
17:41:10 <mitr> kalev: No we can't because we will never be able to port users' private applications,.
17:41:31 <mitr> kalev: Oh, sorry, before F21 is shipped.  That would still imply doing all of this post-beta, eww.
17:41:50 <mattdm> mitr: in this particular case I think it would be okay since nothign really gets renamed. main name package just gets updated to 1.7, obsoletes compat 17 package
17:42:11 <mattdm> all of which I'm kind of leaning towards being too late
17:42:14 <sgallagh> One or the other has to be the "primary" version in python. (So if an app imports it without a version, it gets that one)
17:42:27 <sgallagh> It seems... complicated to have the primary one be the older one
17:42:36 <sgallagh> And I suspect that won't match applications' expectations
17:42:38 <mrunge> and quite unexpected
17:42:47 <mrunge> yes
17:42:51 <kalev> ah, so if _both_ are installed, it always picks the newer when doing 'import django' in python?
17:42:53 <mitr> mattdm: This is not C with sonames, random samplinb shows various packages with Requires:python-django so we can't so easily rename.
17:43:18 <t8m> hmm, that makes the option III not so appealing
17:43:28 <sgallagh> kalev: It always picks the *default*, which I believe is conventionally the higher verison
17:43:33 <sgallagh> This would buck that convention
17:43:52 <kalev> I see the problem now
17:43:53 <mrunge> sgallagh, higher version or shorter name
17:44:03 <sgallagh> right
17:44:04 <mrunge> (that's hard coded in yum)
17:44:10 <mattdm> okay, so, it seems like general leaning towards II (django-1.7, django16-1.6?)
17:44:22 <sgallagh> I was talking about the Python side, but yum has its part to play in the mess too
17:44:47 <mitr> mattdm: Isn’t that III?
17:44:54 <mrunge> I was told, dnf plays a lot nicer here
17:44:56 <t8m> mitr, no
17:44:56 <mitr> mattdm: sorry, ignore me.
17:45:09 <sgallagh> Who said that? ;-)
17:45:11 <kalev> mitr: dnf or yum doesn't play a role here, sgallagh is talking about python versioning
17:45:15 <mattdm> mitr: sorry not the best option naming scheme :)
17:45:18 <mrunge> sgallagh, dnf guys
17:45:39 <sgallagh> mrunge: Sorry, that was in response to mitr as a bad joke
17:45:49 <kalev> mrunge: whatever the packages are called, if you have both 1.6 and 1.7 installed, doing 'import django' gets you the higher version
17:45:55 <kalev> I think that's the problem with parallel installability
17:46:12 <mrunge> yes
17:46:13 <sgallagh> kalev: That's not *strictly* true
17:46:13 <mattdm> I think it's fine to have them conflict
17:46:27 <sgallagh> Thanks to setuptools, you CAN tell python "give me the highest version within these limits"
17:46:38 <mattdm> And we can teach people how to put 'em in docker if they need to have both served from the same machine :)
17:46:40 <sgallagh> Which we have done in the past
17:47:05 <mattdm> mrunge: are you resigned to having to support two versions no matter what we decide? :)
17:47:14 <mattdm> or do you want to argue for just 1.7 still?
17:47:16 <mitr> mattdm: That would essentially mean “have one version in the repo and the others as SCLs?”?
17:47:42 <mrunge> mattdm, I would even support two versions. but I try not to do so
17:47:53 <mattdm> mitr: that'd be nice, but no, both versions in repos, but you can't install them all into the same system
17:47:59 <t8m> I am still wondering whether we have to have 1.7 in F21 at all given these complications
17:48:06 <t8m> F22 should not be that far away
17:48:30 <mrunge> t8m, I want to believe you
17:48:31 <mattdm> mrunge: thoughts on that?
17:48:41 <mattdm> you mean on f22 timeframe?
17:48:42 <mitr> t8m: Given what is/will be in the Beta, yeah, the most natural default to me is to ship 1.6 as is, and to allow 1.7 if/when it can be done as an additional package that doesn’t break 1.6
17:48:54 <mrunge> what's the timeframe on f22?
17:49:03 <mattdm> f22 _will_ be a regular-length cycle
17:49:18 <kalev> mitr: That sounds like a good option to me.
17:49:20 <mrunge> so: release next September?
17:49:20 <mattdm> presumptively targetting late april / early may at this point.
17:49:22 <sgallagh> I'd still like to see it actually be a shortened cycle...
17:49:46 <mitr> t8m: OTOH perhaps FESCo should be allowing/enabling a heroic effort to port things to a better future as long as the release criteria are not in danger and this is unlikely to affect anyone but those heroes?
17:49:54 <sgallagh> Like, April yeah
17:50:12 <mrunge> if we really can get a shorter cycle, I'd be ok with going with django-1.6
17:50:15 <mattdm> mrunge: we don't really normally slip that much — a couple of weeks from nominal is normal
17:50:27 <mrunge> and skipping django-1.7 completely
17:50:33 <mattdm> mrunge: the long cycle here was an intentional one-time thing
17:51:04 <mrunge> mattdm, we had releases about every 8-9 months in the past
17:51:07 <mattdm> and previous time we had a long cycle was... long story but not going to happen again
17:51:38 <kalev> yes, let's get back to regular may / october release cycles
17:52:02 <mattdm> mrunge: it seems that way but we actually just did some historical analysis and it turns out that we're better than (even our own perception) at being close to 6 months
17:52:03 <mrunge> ok, joke aside. If we really can get a shorter cycle and a next release in april, I'd really be fine with going with Django-1.6
17:52:19 <mattdm> mrunge: how do you feel about may? :)
17:52:27 <mrunge> Django-1.7?
17:52:30 <mrunge> :P
17:53:08 <mitr> mrunge: (Separately, it might be worth thinking how to name Django packages / package things in the future to ensure smooth version transitions, to get a known working/established way.  But that's not urgent today, and more for you to decide and perhaps FPC.)
17:53:19 <mattdm> So sounds like we'll just skip 1.7? (could go in a copr)
17:53:31 <mattdm> Do we need a vote?
17:53:33 <mrunge> mattdm, sounds that way
17:53:38 * mattdm looks meaningfully at clock
17:53:46 <mitr> mattdm: Or could be parallel-installabe if it is non-breaking IMHO, but that’s nitpicking
17:53:51 <mattdm> it's mrunge's bedtime, too.
17:53:59 <mrunge> mitr, sadly, I don't have a good proposal to solve this
17:54:04 <mrunge> good night mattdm
17:54:25 <mrunge> .
17:54:41 <sgallagh> The real problem is that Django apps tend to trail Django platform releases by 4-7 months
17:54:53 <sgallagh> Django platform releases every 9 months with an 18-month lifecycle
17:55:00 <mattdm> #agreed no exception for 1.7; will stick to 1.6 (since fedora 22 release scheduled to be proper 6-month cycles) (no vote, just general agreement)
17:55:07 <sgallagh> It is *very* difficult on our end to strike a balance there
17:55:07 <mattdm> ^ anyone disagree with that? :)
17:55:21 <sgallagh> nope
17:55:32 <mrunge> I doubt, we'll find a real solution here
17:55:35 <dgilmore> mattdm: I think its okay
17:55:39 <mattdm> cool
17:55:48 <mrunge> but for developers, we should recommend to skip f21
17:55:56 <mrunge> as django is outdated
17:55:57 <mattdm> mrunge: possibly in the future, an scl-like-thing with its own lifecycle. but that's the glorious future
17:55:58 <kalev> I think in general it would would be nice to always ship last 2 django versions, but sounds like there are some parallel-installability problems here to figure out first
17:56:04 <sgallagh> mrunge: A COPR could address that
17:56:17 <mattdm> #info a copr could address 1.7 for people who need it
17:56:18 <mrunge> sgallagh, there is a COPR
17:56:18 <sgallagh> Without putting it in Fedora itself
17:56:24 <mattdm> cool.
17:56:24 <sgallagh> Well, there you go :)
17:56:32 <mattdm> okay so....
17:56:36 <mattdm> #topic Next week's chair
17:56:43 <mrunge> sgallagh, https://copr.fedoraproject.org/coprs/mrunge/django-1.7/
17:56:46 <dgilmore> in a scl future it oculd be part of fedora
17:57:01 <t8m> I probably won't attend next week but I could chair the week after that
17:57:05 <kalev> I could take the week after next, but not next week
17:57:14 <mattdm> hmmm.
17:57:26 <mattdm> not helping, guys :)
17:57:42 <sgallagh> I'll take next week
17:57:47 <mattdm> #infol t8m and kalev to fight for the week AFTER next
17:57:48 <dgilmore> I am not sure if I will make next weeks meeting
17:57:49 <mattdm> #info t8m and kalev to fight for the week AFTER next
17:57:56 <mattdm> #action sgallagh to chair next week
17:58:11 <mattdm> #info updated meeting process at https://fedoraproject.org/wiki/FESCo_meeting_process
17:58:18 <mattdm> ^ sgallagh in case you didn't see last week
17:58:25 <mattdm> #topic Open Floor
17:58:43 <sgallagh> I didn't
17:58:48 <mattdm> This came in too late to be ready for the meeting, but people should be aware of
17:58:49 <mattdm> https://fedorahosted.org/fesco/ticket/1359
17:58:54 <sgallagh> Thanks
17:58:56 <mattdm> firefox openh264
17:59:15 <mattdm> last time we talked we said we'd deal with it when something concrete came up (punt!), and now here it is
17:59:22 <sgallagh> Grrr... I'm reasonably sure that we determined that we CANNOT legally ship that
17:59:23 <sgallagh> Period
17:59:41 <mitr> sgallagh: this is auto-download, not shipping, AFAICS
17:59:46 <sgallagh> And that was why we approached the standards committee with a plea to accept webm instead
17:59:48 <mattdm> note that I don't want to talk about it right now because I have to go... if people want to, could someone take over ending the meeting and sending minutes?
17:59:56 <dgilmore> sgallagh: we need a ruling from legal on that
17:59:57 <sgallagh> mitr: We don't allow auto-download either (see Dropbox)
18:00:04 <mitr> And https://fedorahosted.org/fesco/ticket/1358 ?  Marked “Urgent” with deadline yesterday, do we want to discuss this or just close it?
18:00:05 <sgallagh> I'm pretty sure we have one
18:00:18 <t8m> sgallagh, +1
18:00:23 <mattdm> mitr oh yeah, didn't put that on agenda since I figured it'd be closed by now
18:00:33 <t8m> +1 to ...don't allow autodownload
18:00:50 <sgallagh> mitr: Fedora Workstation has voted to drop their netinstall for F21
18:00:57 <sgallagh> Thereby leaving option 1 the sensible one
18:01:05 <sgallagh> Which we have already accomplished
18:01:07 <mitr> For 1359, I’d give it the extra week for collecting data and options.
18:01:20 <mattdm> mitr+++++++
18:01:20 <mitr> sgallagh: so, shall we close it?
18:01:37 <mitr> (it being 1358 now, sorry.)
18:02:06 <sgallagh> mitr: Unless FESCo wants to overrule this (entirely sensible) decision, I think so
18:02:15 <sgallagh> (Yes, that was a biased statement)
18:02:17 <mattdm> sgallagh: heh.
18:02:38 <mattdm> I think we'd _do_ eventually need a workstation netinstall -- it's very popular at universities and such
18:02:47 <mattdm> but it's okay to direct people to the server one from now
18:02:58 <mattdm> sgallagh can you make sure that gets releasenotesed?
18:03:00 <sgallagh> Right, and the Server one will work for both
18:03:12 <sgallagh> I don't know that this is a release-note type thing...
18:03:32 <sgallagh> The WS guys seemed pretty clear that they didn't want to advertise it
18:03:36 <kalev> one thing that Workstation was asking was to completely drop the workstation netinstall images and the install tree -- can FESCo back this up?
18:04:01 <sgallagh> Meaning don't ship them to mirrors?
18:04:04 <kalev> since they basically turned out to be the same in every aspect as the server images
18:04:05 <sgallagh> I think that's a bad idea
18:04:06 <dgilmore> kalev: huh, since when.
18:04:07 <kalev> sgallagh: yes.
18:04:07 <mattdm> kalev: I think we need the install tree so people can do netinstalls with the server image, right?
18:04:11 <mitr> kalev: Is this a branding thing of not wanting a Workstation-branded media that installs Server, or not wanting that functionality at all?
18:04:14 <mattdm> dgilmore: since like yesterday
18:04:34 <sgallagh> mattdm: Well, technically they still can, by pointing to the Everything or Updates trees
18:04:36 <dgilmore> thats seriously too late in the f21 cycle to go doing something like that
18:04:43 <kalev> Workstation doesn't want to have an image labelled as 'Workstation' when it really defaults to server
18:04:59 <dgilmore> to change the comnposing process to not do it would be a huge undertaking that I am not willing to consider for F21
18:05:13 <dgilmore> F22 we can look at doing something differently
18:05:27 <dgilmore> kalev: it defaults to cloud afaik
18:05:29 <sgallagh> dgilmore: He's not suggesting changing the compose process, just not shipping the composes to the mirrors
18:05:34 <sgallagh> dgilmore: I fixed that yesterday
18:05:35 <mattdm> If it's going to cause releng heartache I'm not for it.
18:05:36 <kalev> dgilmore: this is unacceptable from Workstation POW to ship an image labelled as workstation that's actually not workstation
18:05:38 <sgallagh> It defaults to Server now
18:05:57 <sgallagh> (For certain definitions of "fixed", naturally)
18:06:04 <dgilmore> sgallagh: not shoipping is changing the process
18:06:14 <sgallagh> ok
18:06:20 <dgilmore> its going to cause quite a bit of extra work for releng
18:06:25 <jwb> shipping something that claims to be one thing but isn't is both misleading and stupid from a PR point of view
18:06:27 <sgallagh> I'm not in favor of it, I'm just trying to clarify the request
18:06:30 <dgilmore> and Its too late to go doing things like that
18:06:50 <dgilmore> this is the type of thing that needed to be sorted months ago
18:06:50 <mattdm> Not arguing that it's not a change, but isn't it just slipping an `rm` into a script somewhere?
18:06:52 <sgallagh> jwb: Well, we can ship it and just not link to it anywhere...
18:06:57 <jwb> dgilmore, you mean like by Alpha?
18:06:59 <jwb> damn right
18:07:22 <dgilmore> j	right
18:07:27 <dgilmore> m	its not slippinga  rm in anywhere
18:07:30 <kalev> I don't see a problem with changing the scripts to stop producing one image.
18:07:33 <jwb> sgallagh, not helpful.  people will still find it, install it, and then come ask workstation about it and we'll have to figure out wth they're talking about
18:07:33 <dgilmore> gahh laggy network
18:07:43 <kalev> It is extra work definitely, but not something that's unreasonable to ask.
18:07:50 <mattdm> I agree with jwb/kalev about the branding
18:08:29 <dgilmore> I would have to refacter the scripts that make the compose.
18:08:36 <kalev> can you do that?
18:09:01 <jwb> or could till or pbrobinson or perhaps one of the other releng people?
18:09:01 <mattdm> dgilmore: it can't be composed and then dropped (again, just trying to understand)
18:09:29 <dgilmore> mattdm: no
18:09:37 <kalev> why not?
18:09:54 <dgilmore> we would have to refactor a bunch of the compose process
18:10:15 <dgilmore> and this is just way too late in the cycle to be doing that
18:10:18 <kalev> you keep saying that, but why doesn't a 'rm -rf path/to/Workstation/' work?
18:10:21 <dgilmore> we can look at f21 options
18:10:41 <dgilmore> kalev: because the isso you want is in there also
18:10:57 <dgilmore> we could do something, but it is refactoring how we do composes
18:10:59 <mattdm> rm -f path/to/Workstation/iso-we-dontwant.iso?
18:11:31 <mattdm> I'm not trying to be difficult but I'm not understanding why something more than that is needed
18:11:32 <dgilmore> mattdm: you would want to remove everything but one iso I think
18:11:40 <jwb> dgilmore, we actually do
18:11:44 <jwb> that is exactly what we're asking for
18:11:53 <dgilmore> jwb: what is?
18:12:00 <jwb> sorry, i misread.  we are asking to remove just one file
18:12:27 <mattdm> I think just Fedora-Workstation-netinst-x86_64-21.iso is all we need
18:12:32 <dgilmore> remove the boot.iso and leave the pxe tree in place?
18:12:52 <dgilmore> mattdm: there is two copies of that file in the tree
18:13:03 <dgilmore> CHECKSUMS would also ned modified
18:13:03 <kalev> PXE tree would be nice to remove as well, yes
18:13:13 <jwb> aren't they in the same directory?
18:13:16 <jwb> just remove the whole directory
18:13:18 <sgallagh> kalev: WHY?
18:13:19 <dgilmore> then tehre is no point in have the install tree at alll
18:13:30 <jwb> agreed!  doesn't matter
18:13:32 <dgilmore> which trakes us back to refacter and not make the install tree at all
18:13:38 <kalev> sgallagh: because it's the same as the server tree
18:14:17 <dgilmore> basically you want the compose process refactored and its really too late to do so for f21
18:14:18 <mattdm> dgilmore no point, but it's much harder to refactor and all of the reasons you give about that being too much.
18:14:19 <kalev> sgallagh: well, not really the same, but installing from that tree leads to the same comps being pulled in as from installing from the server tree
18:14:47 <dgilmore> I need to follow up on emails I got told about to deal with branding because that likely wants changes to the compose process also
18:15:04 <jwb> dgilmore, no.  we're asking you to let the compose process run and then delete it's output
18:15:20 <jwb> that's not a refactor.  it's called a workaround for a crappy situation
18:15:35 <jwb> and it can be fixed for f22
18:16:03 <dgilmore> jwb: its simpler to refacter than it is to clean all the bits up
18:16:11 <mattdm> rm -rf Workstation*/os/images; rm -f Workstation/*/iso/Fedora-Workstation-netinst-*.iso
18:16:47 <mattdm> if possible _before_ checksum; otherwise also regenerate checksums in iso/
18:16:50 <dgilmore> not making the workstation tree at all would speed up the compose process
18:17:07 <dgilmore> mattdm: id rather refacter than do that
18:17:08 <mattdm> but _that's_ refactoring
18:17:17 <mattdm> I think we _want_ to refactor for f22
18:17:21 <dgilmore> but id rather not mess with any of it at this point
18:17:41 <kalev> I think we're all being nice here. The original plan at Alpha time was to give rel-eng more time to work on fixing netinstalls and allow Alpha to ship without them.
18:17:46 <kalev> Since that work didn't happen and netinstalls are still broken, we're finding workarounds that minimize releng work.
18:18:28 <dgilmore> kalev: it was never releng that was going to fix them
18:18:32 <kalev> Workstation is meeting half way there and has agreed to ship without a fixed image
18:19:16 <mattdm> kalev can someone from workstation help with the script changes necessary?
18:19:20 <dgilmore> kalev: its up to the products and anaconda folks to come up with a plan to fix them
18:19:37 <dgilmore> mattdm: idd do it, I just do not want to
18:19:44 <dgilmore> i'll
18:19:49 <kalev> dgilmore: the 3 repos was relengs plan in the first place. anaconda folks said all the time this is a hack that's not a good plan.
18:20:03 <dgilmore> kalev: it wasnt relengs plan at all
18:20:28 <jwb> enough.  let's focus on whatever we're doing to do now and not what people should have done
18:20:36 <mattdm> jwb +1
18:20:48 <jwb> you guys can point fingers after we come to a resolution here
18:20:54 * dgilmore needs to run and meet people for lunch
18:21:15 <mattdm> dgilmore we all recognize that it's not ideal. If we vote for _some_ approach, will you implement even if not preferred?
18:21:28 <dgilmore> jwb: I guess the big problem is that everyone thinks someone else is fixing things
18:21:31 <dgilmore> and so no one is
18:21:31 * mattdm also has to run
18:21:45 <mattdm> dgilmore: yeah that's definitely part of it. but also something to solve later
18:21:46 <dgilmore> mattdm: ill just not make the workstation tree
18:21:56 <dgilmore> its teh simplest way to deal with it for f21
18:21:58 <mattdm> dgilmore: that means no Workstation directory?
18:22:05 <kalev> dgilmore: that would be a good solution for f21, agreed -- and thanks
18:22:10 <dgilmore> mattdm: there will be none
18:22:13 <mattdm> -1 to that.
18:22:32 <dgilmore> kalev: its a bad solution, but it seems to meet what you want
18:22:52 <mattdm> I strongly prefer the other bad solution
18:22:58 <kalev> well, you can have a Workstation/iso/ directory with just two files in there, the iso image + checksum
18:23:04 <dgilmore> mattdm: the rm of parts of the tree?
18:23:15 <kalev> but the rest should be fine to remove like dgilmore says
18:23:17 <mattdm> well, can we do what kalev just said?
18:23:23 <jwb> i'm confused as to what "not make the workstation tree" actually maps to
18:23:23 <mattdm> I'm okay with that
18:23:53 <sgallagh> jwb: IIUC, it means that http://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC4/Workstation/ stops existing
18:24:04 <jwb> so no Workstation product at all?
18:24:06 <sgallagh> But presumably the live media is generated and placed somewhere else?
18:24:08 <mitr> jwb: Same here.  Can we talk in mitr-is-stupid lingo like netinstall iso / netinstall tree / dvd / live image?
18:24:23 <kalev> I think dgilmore's plan is sane to not generate the tree
18:24:24 <dgilmore> we would make a skeleton set of directories for the livecd
18:24:33 <dgilmore> f22 livecd will need the anaconda tree
18:24:42 <dgilmore> f21 livecd doesnt
18:24:51 <jwb> ok
18:24:53 <kalev> the "tree" here means the additional rpm repo for workstation, which is unneeded
18:24:58 <mattdm> dgilmore skeleton of directories for mirrors, too?
18:25:04 <dgilmore> mattdm: yes
18:25:28 <mattdm> so there would still be a top level Coud/Server/Workstation, in which case I'm fine with that.
18:25:28 <dgilmore> mattdm: it would change what we amke and put on the mirrros
18:25:35 <sgallagh> So the only real loss here is the ability to point virt-manager directly at http://dl.fedoraproject.org/pub/alt/stage/21_Beta_TC4/Workstation/os to do an installation
18:25:44 <dgilmore> mattdm: there would be but whats in Workstation will be different
18:25:52 <dgilmore> sgallagh: correct
18:25:52 <mattdm> dgilmore: okay. I can live with that.
18:26:05 <sgallagh> If you wanted to do a netinstall of Workstation, you'd point it at Server and add the Everything repo
18:26:09 <sgallagh> Correct?
18:26:11 <mattdm> The second loss is that we can't use mirrormanager stats to distinguish between products
18:26:11 <dgilmore> the install tree today would give you workstation only if you disabled the updates repos
18:26:56 <kalev> sgallagh: I don't think you'd even need to add any additional repos, just pointing to the Server tree is enough; you'll be presented with Server and Workstation and all the different spin options
18:27:02 <jwb> if workstation is fine with dgilmore's change, then let's just go with it.
18:27:18 <dgilmore> kalev: you would need to enable the fedora repo from memory
18:27:25 <t8m> jwb, ₊
18:27:31 <t8m> jwb, +1
18:27:39 <dgilmore> jwb: i think its a bad idea but it seems to be what workstation wants
18:27:59 <jwb> noted
18:28:02 <mattdm> jwb +1
18:28:13 <mattdm> we'll need to figure this out better for f22
18:28:20 <mattdm> with better coordination.
18:28:22 <sgallagh> kalev: No, I just confirmed: you'd need to add a repo
18:28:26 <mitr> jwb: +1
18:28:31 <mattdm> (ideally, get it going in rawhide long before f22 brances)
18:28:32 <dgilmore> mattdm: well in f22 the install tree is required to make livecds
18:28:51 <mitr> mattdm: that would be mirrormanager stats for network installs only?  I can live with that.
18:28:53 <dgilmore> you get comps with all options dure to the updates repo having it
18:29:12 <dgilmore> other options would be to not allow comps to be updated
18:29:20 <dgilmore> or make updates repos for products
18:29:23 <mattdm> so four +1s including jwb; 5 if we assume kalev, 6 if we also include dgilmore?
18:29:28 <sgallagh> +1 from me
18:29:31 <dgilmore> all of which is a fair bit of work to do
18:29:39 <dgilmore> mattdm: im -1
18:29:53 <dgilmore> I will do it but I really do not like it
18:30:00 <kalev> ok, can we go with just killing the netinstall iso, would you be +1 to that, dgilmore?
18:30:19 <dgilmore> kalev: ill be +1 to leaving it as is
18:30:40 <mattdm> yep, noted
18:30:52 <mattdm> kalev are you +1 to the "no workstation tree?"
18:30:55 <kalev> yes
18:30:58 <jwb> great, passed.
18:31:19 <mattdm> #agreed rel-eng will drop workstation tree so it isn't confusing (currently installs server) (+5,-1)
18:31:22 * dgilmore needs to go, people keep calling the room to get me to go to lunch
18:31:31 <mattdm> yeah I need to go too
18:31:36 <mattdm> anything else?
18:31:45 <dgilmore> mattdm: last i knew it defaulted to cloud, was that changed?
18:31:50 <mitr> dgilmore: yes
18:31:51 <mattdm> dgilmore yes
18:31:57 <dgilmore> okay
18:32:17 <mattdm> okay -- thanks everyone!
18:32:20 <mattdm> #endmeeting