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