fesco
LOGS
17:59:37 <sgallagh> #startmeeting FESCO (2013-11-20)
17:59:37 <zodbot> Meeting started Wed Nov 20 17:59:37 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:59:41 <sgallagh> #meetingname fesco
17:59:41 <zodbot> The meeting name has been set to 'fesco'
17:59:44 <sgallagh> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
17:59:44 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
17:59:47 <sgallagh> #topic init process
17:59:57 <sgallagh> .hellomynameis sgallagh
17:59:58 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:00:00 * abadger1999 is present
18:00:01 <nirik> morning everyone.
18:00:05 <pjones> I'm here, but I'm also simulcasting to the UEFI Security Subteam meeting.
18:00:10 <mattdm> afternoon :)
18:00:16 <pjones> (this won't get confusing at all...)
18:00:49 <pjones> oh actually it just ended.  on time.  how... odd.
18:00:52 <mitr> Hello
18:00:55 <mmaslano> hi
18:00:55 <nirik> can we boot this FESCo meeting without being signed? ;)
18:01:03 <pjones> hehe
18:01:04 <t8m> hello
18:01:09 * notting is here no
18:01:11 * notting is here now
18:01:19 <sgallagh> I think that is everyone, yes?
18:01:47 <sgallagh> Just an FYI, I have a hard-stop in two hours. Given our long agenda, this may be necessary to point out.
18:02:10 <sgallagh> Ok, let's start with follow-up business
18:02:13 <sgallagh> #topic #1193 reboots for all updates -- are we ready for this?
18:02:17 <sgallagh> .fesco 1193
18:02:18 <zodbot> sgallagh: #1193 (reboots for all updates -- are we ready for this?) – FESCo - https://fedorahosted.org/fesco/ticket/1193
18:02:52 <mattdm> this is waiting for an update to the feature wiki page and to the release notes, right?
18:02:57 <nirik> yep.
18:03:01 * sgallagh nods
18:03:11 <nirik> would one of us like to step up to do that? or nag others who could?
18:04:01 <sgallagh> mattdm: This was your topic; mind taking this?
18:04:01 <mattdm> I guess I can ask the feature owner to?
18:04:23 <mattdm> sgallagh Yeah I can.
18:04:29 <sgallagh> #action mattdm to contact the Change owner to update the wiki page and release notes
18:04:41 <sgallagh> OK, moving on
18:04:43 <sgallagh> #topic #1185 Enable "-Werror=format-security" by default
18:04:47 <sgallagh> .fesco 1185
18:04:48 <zodbot> sgallagh: #1185 (Enable "-Werror=format-security" by default) – FESCo - https://fedorahosted.org/fesco/ticket/1185
18:05:22 <sgallagh> So we now have a list of the packages that failed the rebuild.
18:05:25 <nirik> +1 to adding a note about component name to mass bugs thign
18:05:40 <t8m> given the number of build failures due to this I'm definitely against making it Werror
18:05:41 <mitr> nirik: ?
18:05:49 <mitr> 400 components is a rather high number, yes
18:05:59 <t8m> mitr, there was proposal to mass file bugs
18:06:02 <mitr> OTOH I have looked at a few and most were real errors.
18:06:09 <mitr> t8m: right, thanks
18:06:19 <sgallagh> t8m: Yes, and the proposal owner also plans to provide many of the patches.
18:06:27 <sgallagh> In most cases, it's automatable
18:06:37 <mitr> (grass has a very large number - seems to be an incorrect __attribute__ but I haven't checked to be sure)
18:06:56 <mattdm> #info 400 packages fail rebuild
18:06:58 <nirik> I'm ok with doing it, but I think we should wait at least another week before filing any bugs.
18:07:04 <notting> i'd be fine with enabling it... eventually. seems worth it to do an initial cleanup pass
18:07:27 <sgallagh> notting: Well, the easiest way to accomplish a cleanup pass would be to enable it.
18:07:29 <t8m> so I am definitely +1 to mass file bugs
18:07:41 <sgallagh> And optionally disable it later if it causes too much trouble
18:08:05 <mattdm> we are talking about doing this in rawhide, right?
18:08:12 <sgallagh> mattdm: Yes, Rawhide only
18:08:22 <sgallagh> Though obviously anyone who also wants to backport it can
18:08:35 <abadger1999> mitr: to be fair, it's about 2.75% of packages.
18:08:38 <mitr> Proposal: 1) wait a week for devel feedback (from people already interested); 2) if there are no show-stoppers identified, mass file bugs; 3) 3 weeks later, enable in rawhide configuration by default
18:09:01 <mattdm> +1 mitr
18:09:04 <notting> mitr: that seems reasonable enough
18:09:07 <sgallagh> mitr: Sounds good to me. +1
18:09:09 <mmaslano> +1 mitr
18:09:10 <nirik> +1 mitr
18:09:14 <abadger1999> mitr: +1  wfm
18:09:14 <notting> 4) write release note
18:09:24 <mitr> ... wait a moment
18:09:34 <t8m> +1 to mitr
18:09:44 <sgallagh> notting: This should probably be a Change page, honestly
18:09:45 <mitr> Now that rpm requires redhat-rpm-config, i.e. this _will break 2.75% builds of  non-Fedora packages_
18:09:56 <mitr> sgallagh: yes
18:10:25 <pjones> mitr: +1
18:10:27 <mitr> Is making it difficult to compile 2.75% of Linux-targeted software in C really acceptable?
18:10:32 <sgallagh> mitr: By "break", I think you may mean "force to fix"
18:10:42 <notting> mitr: well, there's no guarantee that the number is representative of the greater universe
18:10:43 <mitr> sgallagh: "whatever"
18:10:44 * jreznik can drive Change page process if asked to do so
18:11:06 <pjones> 2.75% seems like a pretty small number, when you put it that way.
18:11:08 <abadger1999> mitr: We've seen higher breakage from updating gcc than this.
18:11:10 <mattdm> By "greater universe", we mean "things packaged in RPM for Fedora but not by Fedora"?
18:11:23 <mitr> sgallagh: Or, rather - there would have been a diffference if we had a SDK and allowed us to say "compile like on F19", but now there isn't
18:12:03 <sgallagh> For what it's worth, I suspect much of the "greater universe" does their own builds with their own flags.
18:12:14 <notting> ...and doesn't build rpms
18:12:14 <mitr> mattdm: OK, the requirement to use rpm does limit this
18:12:16 <sgallagh> Of course, it's impossible to get statistics on that
18:12:51 <mitr> abadger1999: but we haven't been the only distribution that refuses to build the software.  "But it works and will continue to work on Ubuntu, wontfix"
18:13:42 <mitr> ... I suppose if this is still limited to RPMs, I'm fine with my original proposal.  But I'm noticeably less enthusiastic.
18:13:54 <mitr> (+1 to my proposal for the record)
18:14:01 <sgallagh> Does anyone want to revise their earlier vote?
18:14:08 * nirik doesn't. fine with it.
18:14:21 <t8m> nope
18:14:35 <mattdm> I think it's pretty likely that any third-party RPMs will either a) want to adapt or b) already uses their own build options
18:14:37 <abadger1999> mitr: from the ticket: "At this point in time, turning on this flag should be relatively safe, since many FTBFS issues have been found (and fixed) already by Debian and Ubuntu folks. This means that all the hard work has already been done for us ;)"
18:14:50 <sgallagh> #agreed  1) wait a week for devel feedback (from people already interested); 2) if there are no show-stoppers identified, mass file bugs; 3) 3 weeks later, enable in rawhide configuration by default (+8, 0, -0)
18:14:59 <notting> proposal: file a retroactive Change page for this
18:15:04 <abadger1999> notting: +1
18:15:04 <mitr> abadger1999: but Ubuntu doesn't have Werror by default
18:15:06 <sgallagh> notting: +1
18:15:19 <mitr> notting: +1.
18:15:25 <nirik> sure, +1
18:15:38 <sgallagh> jreznik: You said you'd be willing to walk them through this?
18:15:44 <mitr> (I take it all proposals have implicit "Ask the halfie to...")
18:16:20 <sgallagh> Or someone willing to do it for him, yes
18:16:45 <pjones> notting: +1
18:16:52 <t8m> notting, +1 sure
18:17:44 <sgallagh> #agreed Please file a Change page for this. (+7, 0, 0)
18:18:04 <sgallagh> Ok, next topic.
18:18:08 <sgallagh> #topic #1198 Possible changes to Fedora EOL bug procedure
18:18:10 <jreznik> sgallagh, sure
18:18:12 <sgallagh> .fesco 1198
18:18:13 <zodbot> sgallagh: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198
18:18:36 <mattdm> okay, so, should we just ask the bugzilla people to implement the reopen-and-reversion request?
18:18:47 <jreznik> the answer from bz team is in ticket and it's possible
18:18:51 <sgallagh> mattdm: +1
18:19:01 <nirik> yeah, I would prefer that.
18:19:04 <notting> mattdm: yes, +1
18:19:12 <t8m> mattdm, I thought that is implicit so +1
18:19:33 <mattdm> t8m it got muddied because I thought of several alternative approaches :)
18:19:52 <mitr> mattdm: +1
18:19:52 <abadger1999> mattdm: +1
18:20:03 * nirik is +1 too for the record.
18:20:12 <mmaslano> +1
18:20:16 * mattdm is +1 to self
18:20:21 <sgallagh> #agreed Ask the Bugzilla administrators to implement the reopen-and-re-version request (+8, 0, -0)
18:20:37 <jreznik> we would have to do some changes in the future to match multiple products
18:20:40 <sgallagh> (Three tickets in 20 minutes. New record?)
18:20:52 <sgallagh> #topic #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17
18:20:55 <nirik> hopefully they can get it in before the next mass eol bug thing.
18:20:55 <sgallagh> .fesco 1140
18:20:56 <zodbot> sgallagh: #1140 (F20 Self Contained Changes - week 2013-07-10 - 2013-07-17) – FESCo - https://fedorahosted.org/fesco/ticket/1140
18:21:22 <sgallagh> So we need to rule on how to deal with a broken installer feature
18:21:35 <sgallagh> LVM Thin Provisioning apparently has many issues.
18:21:57 <sgallagh> Possible options: 1) Remove it from the installer by default and allow it via boot argument
18:22:02 <nirik> can we engage the contingency? or it's too late?
18:22:13 <sgallagh> 2) Remove the feature from F20 entirely
18:22:16 <sgallagh> 3) Otherwise note that it's experimental
18:22:20 <mitr> Proposal: simplify first, "there is no 'tech preview' in Fedora; either the Change has (within its updated scope) been finished and tested or not"
18:22:20 <notting> are there descriptions of the issues somewhere?
18:22:23 <jreznik> we ask for guidance how to proceed with tech preview in Fedora, btrfs is in question too - not a change...
18:22:29 <sgallagh> nirik: Contingency plan is sparse
18:22:32 <t8m> mitr, +1
18:22:37 <nirik> ah, it's N/A
18:22:43 <jreznik> mitr, it's not only about thinp
18:22:51 <mitr> jreznik: my proposal stands in general
18:22:58 <abadger1999> jreznik: When you say "technology preview/feature preview mode " do you mean there's an actual software mode in anaconda for tech previews?
18:23:16 <mattdm> mitr we have no _formal_ "tech preview" state but we certainly do informally have things that are that way.
18:23:25 <sgallagh> abadger1999: I think that's more in line with my 1) above
18:23:33 <pjones> mitr: well, that's /already/ true.  in the past we have had ways to get at new installer features ("icantbelieveitsnotbtr", etc.), but we don't call things "Tech Preview"
18:23:44 <mitr> jreznik: Then, on the specific, question, since this is not System-Wide why is it FESCo's job to dictate the self-contained contingency handling?
18:24:09 <jreznik> mitr, we ask for help to deal with such situations
18:24:15 <sgallagh> mitr: This probably should have been system-wide. I think we miscategorized it.
18:24:20 <mattdm> I don't think we're dictating, just coordinating.
18:24:25 <mitr> jreznik: It's really not clear to me what help you are asking for.
18:24:30 <abadger1999> jreznik: There have been ech previews in the past.  In fact, I think that filesystems (including btrfs) have often been listed as tech previews.
18:24:31 <pjones> mattdm: I wouldn't say that.
18:24:33 <jreznik> as currently btrfs and thinp issues are blocking issues
18:24:44 <mattdm> pjones -- in general or on this issue?
18:24:51 <pjones> mattdm: on this issue
18:24:52 <mitr> sgallagh: Perhaps.  The combination of "self-contained" and "release-blocking" is really weird.
18:25:06 <jreznik> and we don't have enough resources to deal with every single case
18:25:17 <sgallagh> Yeah, perhaps we should revise the definition of system-wide to include release-blocking.
18:25:19 <mattdm> jreznik Can you clarify exactly what guidance is asked for?
18:25:33 <mattdm> Whether anaconda is allowed to present something a s "tech preview"?
18:25:35 <sgallagh> mattdm: What contingency plan makes sense?
18:25:40 <notting> so the ticket (and this conversation) does not mention the actual problems. do i need to go trawl the blocker list, or is there a pointer somewhere?
18:25:50 <pjones> mattdm: fundamentally, what jreznik wants us to say is that the F17 thinp feature ( http://fedoraproject.org/wiki/Features/ThinProvisioning ) really wasn't ever finished, and because some people have realized that so very late in the Fedora 17 cycle, he'd like anaconda to do extra work to revert something that works as advertised.
18:25:53 <jreznik> mitr, nobody realized that once it's in installer it would be blocking thing
18:26:07 <nirik> http://fedoraproject.org/wiki/Features/Java8TechPreview and "ibus-gnome3 is provided in a ibus subpackage as a technology preview for Fedora 16." are some older examples.
18:26:16 <mitr> jreznik: How does it become blocking just because it is in the installer?  Is there a blanket guideline?
18:26:24 <mitr> ... blanket criterion, rather?
18:26:33 <pjones> mattdm: I don't happen to agree with /either/ part of that, though.
18:26:45 <nirik> notting: not sure I'd like to see that too.
18:26:52 <sgallagh> mitr: The release must boot to a usable system with any presented installer options
18:26:53 <kparal> mitr: we have a criterion that says we block on filesystems bugs offered by default in anaconda
18:26:58 <notting> nirik: missing comma?
18:27:00 <jreznik> installer is more sensitive in terms of data corruption etc
18:27:07 <nirik> yeah, sorry.
18:27:10 <nirik> I would like to see that also
18:27:20 * jreznik is on phone, can't read and type so fast
18:27:53 <mattdm> I whta does the Anaconda team *want* to do here?
18:28:10 <adamw> to take some of the heat off jreznik, this comes from QA too - we discussed it at our monday meeting
18:28:15 <pjones> mattdm: to be honest I'm not sure, and I'm talking to dlehman now
18:28:37 <sgallagh> Proposal: defer to the judgement of the anaconda team unless they also ask us to step in
18:28:40 <adamw> when we say 'tech preview' or 'feature preview' we're really just saying let's maybe de-emphasise the feature a bit
18:28:42 <nirik> adamw: can you summarize that conversation?
18:28:48 <pjones> mattdm: but on a technical level, I find this bug offensive.
18:29:20 <adamw> nirik: we're worried that thinp really isn't mature enough to be listed in the Installation Options dropdown as a 'primary' choice along with ext4, lvm and btrfs, and promoted as a Change for f20
18:29:39 <adamw> since it seems to have been the source of quite a few bugs in validation testing so far
18:29:46 <sgallagh> adamw: Wasn't there also mention made of the same stance for btrfs?
18:29:53 <adamw> sgallagh: it was considered, but rejected.
18:29:56 <sgallagh> ok
18:29:57 <nirik> adamw: do you have a list of bugs?
18:30:05 <mattdm> pjones why's that?
18:30:07 <adamw> not handy, but let me search my awesomebar
18:30:14 <nirik> awesome!
18:30:21 <pjones> mattdm: because the feature, as far as I know, does actually work as advertised.
18:31:00 <mattdm> pjones but adamw says it's hitting lots of bugs. What am I missing here?
18:31:02 <pjones> and the "problems" people have with it a) were true when everybody was fine with the F17 feature as well, and b) are true of other things we're not rushing to jettison
18:31:45 <adamw> what was the f17 feature here?
18:31:53 <dlehman> we've had probably less than ten bugs related to thinp. is that a large number for such a feature?
18:31:59 <pjones> adamw: lvm thin provisioning.
18:32:08 <sgallagh> adamw: thinp was added in F17, but it only showed up as an installer target in F20
18:32:26 <pjones> and /none/ of the problems we're discussing are issues with the installer feature AFAICS
18:32:47 <sgallagh> I'd still like to see what problems we're discussing, though.
18:32:49 <adamw> right, but the presence of thinp int he installer makes it much more prominent
18:32:51 <notting> pjones: you're saying the installer lays down thinp, and then thinp misbehaves later?
18:32:59 <adamw> cmurf would probably have a better list than me
18:33:01 <mitr> pjones: having stricter requirements GUI-accessible features seems at least plausible
18:33:13 <t8m> pjones, that does not mean that something that is partially broken and won't be fixed should be presented among the choices for fs in fedora installer
18:33:16 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1024144
18:33:19 <t8m> mitr, +1
18:33:20 <pjones> notting: I actually wouldn't strictly agree with the last part, but it's possible my understanding doesn't include more recent bugs.
18:33:24 <adamw> we had https://bugzilla.redhat.com/show_bug.cgi?id=1013767 , that was fixed
18:33:45 <pjones> t8m: and that would have been a fine thing to bring up before approving the change.  there was plenty of time to know.
18:34:05 <kparal> from what I understand, we proposed re-evaluation not because thinp is problematic, but because we have a lot of anaconda-related blockers with it and delay the release quite a bit
18:34:19 <Viking-Ice> ?
18:34:40 <sgallagh> kparal: Can you *please* cite these blockers?
18:34:45 <jreznik> and only one storage developer overloaded with other bugs...
18:35:22 <dlehman> btrfs has presented at least as many actual bugs as thinp in f20 so far
18:35:26 <pjones> jreznik: forgive me, but so far we've seen one bug cited, and in it dlehman says in perfectly plain English that he's got patches to fix the problem in it.
18:35:31 <jreznik> so we would like to offload at least part of that with not 100 percents perfect tech preview
18:35:47 <notting> 1013767 is fixed... 1024144 is ... not a blocker, from what i can understand.
18:35:50 <mitr> so, proposal: 1) there is no formal "tech preview status", 2) amend Change Policy to make anything release-blocking a System-Wide Change; 3) leave it to Anaconda to resolve the problem of blocking F20, either by fixing it or hiding the feature
18:35:55 <pjones> jreznik: so really either present actual facts or it's very hard to take you seriously.
18:36:01 <mitr> (3) implies that FESCo is not currently deciding to overrule the QA criteria)
18:36:03 <mattdm> I'm hearing two different stories here
18:36:08 <t8m> mitr, +1
18:36:38 <abadger1999> mitr: -1 to #1.  Have to think about #2 some more.  #3... +0.5 right now.
18:36:47 * adamw is finding more closed bugs than he expected in his search
18:36:48 <dlehman> indeed. "thinp is wreaking havoc on f20" needs to be reformulated into a statement containing actual bugs ids, facts, &c
18:36:58 <kparal> sgallagh: adamw provided some, another one is 1020111
18:37:10 <dlehman> seriously, btrfs is a real hog these days IMO
18:37:30 <sgallagh> mitr: 1) Abstain. 2) +1. 3) +1
18:37:31 <mitr> dlehman/adamw/jreznik: It's not really reasonable to have a detailed review of quality of thinp in a FESCo meeting, especially with 0 information available in advance
18:37:43 <adamw> mitr: yeah, that's reasonable
18:37:48 <nirik> mitr: I'm similar to abadger1999 here... perhaps we vote on your 3) now and leave the other two for more discussion?
18:37:50 <abadger1999> .bug 1020111
18:37:51 <mmaslano> +1 to sgallagh
18:37:54 <zodbot> abadger1999: Bug 1020111 devicetree.py:1294:addLV:ValueError: 'File descriptor 3 (/tmp/anaconda.log) leaked on lvm invocation. Parent PID 2234: /usr/bin/python' is not in list - https://bugzilla.redhat.com/show_bug.cgi?id=1020111
18:37:54 <pjones> mitr: it's true - the people bringing up this issue should /already have that covered/
18:38:02 <adamw> looking through the blocker list, the largest number of currently accepted, unresolved storage blockers appears to relate to resizing
18:38:04 <jreznik> pjones, I'm not saying it's broken in the way it should not be allowed as some tech preview, just we are not sure on how many bugs we can block and I'd let this part on dlehman to decide... last time we chat he was more inclined to spend more time on important bits...
18:38:25 <sgallagh> mmaslano: What were you giving +1 to?
18:38:26 <mitr> pjones: I default to trusting QA to have reasonable criteria and to reasonably apply them.
18:38:32 <dlehman> right -- 1020111 is lvm -- not specifically thinp
18:38:41 <mmaslano> sgallagh: 1) Abstain. 2) +1. 3) +1
18:38:44 <mattdm> there's a big difference between "turns out to be shaky after install and users should be warned" and "will put the whole release schedule at risk"
18:38:44 <adamw> mitr: that's not necessarily the case for storage; it's very very difficult to quantify into simple criteria
18:38:50 <sgallagh> mmaslano: Ok, just making sure.
18:39:04 <mitr> adamw: FESCo will realistically not do a better job
18:39:08 <adamw> mitr: the storage criteria aren't perfect, we know they're not perfect, and i don't currently have any particularly awesome ideas for making them a lot better
18:39:24 <adamw> so this area gets a bit messy at times :/
18:39:59 <pjones> mitr: the difficulty I have with that is that right now what we've got is essentially a request /to FESCo/ to ask dlehman to do /something ambiguous/ to remove this feature without any concrete substantiation that it actually needs it.
18:40:05 <sgallagh> Can we just vote on mitr's three proposals and move on here? This is eating more time than it probably deserves...
18:40:09 <mitr> jreznik: If you are concerned about the schedule and want to avoid a slip by cutting anaconda scope/features, I don't think it's reasonable to dictate to Anaconda which scope/features to cut
18:40:19 <kparal> it would be nice to define whether that feature can be listed as experimental of technical preview in anaconda. that was purpose of that ticket as I understood it
18:40:22 <pjones> mitr: I'd feel one way if they had a list of bugs and wanted our judgement on "do these bugs mean it shouldn't ship", but there's not even that.
18:40:25 <nirik> mitr: 1) -1, 2) -1, 3) +1
18:40:30 <adamw> pjones: i think we asked fesco not as a way of going 'over the heads' of anaconda team or anything but just as it involves a change, and fesco owns the change process.
18:40:36 <jreznik> kparal, yep
18:40:37 * mitr is 1) +1 2) +1 3) +1 for the formal record
18:40:57 <pjones> adamw: you have responded to the only part of my statement I didn't think was contentious ;)
18:41:08 <adamw> pjones: but you're right that it would've been better to have some detailed data
18:41:11 <notting> mitr: your 1) is 'clarification of current procedures' or 'declaration of how it should be'?
18:41:11 <sgallagh> t8m: Can you clarify your vote? Was that +1 to each?
18:41:19 <t8m> sgallagh, yep +1 to each
18:41:21 <adamw> cmurf tends to have the most storage knowledge to hand and he's not around :/
18:41:25 <mitr> notting: both I suppose
18:41:32 <adamw> he's the guy who runs around testing crazy storage configurations
18:41:37 <t8m> sgallagh, so i count at least +5 for 3)
18:41:42 * sgallagh nods
18:42:04 * sgallagh tries to count
18:42:12 <mitr> pjones: I default to QA having reasonable criteria, as said before; so dlehman seems already _by default_ on the hook for getting Anaconda storage to not violate them.  If the argument is that the criteria are unreasonable, then anaconda should be coming to FESCo and asking to overrule QA.
18:42:29 <notting> i am 1) +1, 2) +1 3) ... i'm not sure how blocker-iness is gated on the designation of a Change/Feature. what am i missing?
18:42:53 <mitr> notting: I don't think it's related
18:42:55 <pjones> not by default.  dlehman's going to do his job, like he always does.  but what's being asked of us, not of qa, is to change what that is, wildly at kind of the last minute.
18:43:26 <notting> mitr: ok, then the question is how does the proposal address the question raised by the ticket, i guess
18:43:40 <mattdm> If real problems are discovered at the last minute they're still real problems....
18:43:40 <dlehman> are there any open thinp-specific bugs right now?
18:43:46 <dlehman> oh, the raid one.
18:43:52 <adamw> one of the ones i linked up there is open
18:44:09 <t8m> mattdm, +1
18:44:09 * adamw doing some more searching
18:44:27 <mitr> notting: "we're not micromanaging this"
18:44:29 <notting> i.e., what does listing something as 'feature preview' or 'tech preview' have to do with release blocking
18:44:43 * sgallagh can't keep up with three proposals at once...
18:44:47 <kparal> notting: QA does not apply as strict criteria there
18:44:59 <nirik> notting: I guess if that meant it was not displayed then it wouldn't block because the critera say "all displayed" ?
18:45:11 <mitr> notting: more specifically, this will not be a "tech preview" because we don't have such a thing, and if it is release blocking then it needs to be resolved.
18:45:38 * nirik notes again we have had tech preview in the past...
18:45:45 <jreznik> tech preview could be then freeze exception
18:45:46 <abadger1999> mitr: we have had tech previews in the past.
18:45:55 <nirik> it's just never been defined really.
18:46:05 <mitr> nirik, abadger1999: I think it's just RHEL terminology leaking
18:46:06 <pjones> we've used the term casually
18:46:13 <pjones> that's not the same thing as having them be a thing as a matter of policy
18:46:18 <mattdm> and even if we didn't have "tech previews" in the past, we certainly *COULD*
18:46:18 <abadger1999> mitr: no, it's not.
18:46:24 <sgallagh> Can we just re-vote on 3) at this point? It's the only really relevant one, I think.
18:46:25 <abadger1999> pjones: I would agree with that.
18:46:26 <notting> (i HATE tech preview as a name. it's a rheloligism due to a fear of labelling something 'beta' or 'alpha'. but i digress.)
18:46:38 <adamw> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&component=anaconda&component=lvm&component=lvm2&component=python-blivet&list_id=1922711&query_format=advanced&short_desc=thin&short_desc_type=allwordssubstr is a quick sesarch i just came up with for anaconda, blivet and lvm bugs with 'thin' in the summary
18:46:45 <mattdm> http://fedoraproject.org/wiki/Features/Java8TechPreview
18:46:47 <pjones> (I LOVE rhelelogism as a name.)
18:46:48 <sgallagh> i.e. Can we just assert that the anaconda and storage guys will come to the appropriate decision here?
18:46:52 <mattdm> ^ fedora tech preview!
18:46:57 <pjones> rheloligism even.
18:47:00 <pjones> hard to type, easy to love.
18:47:32 <t8m> rhelologism
18:47:36 <adamw> notting: so, to bring it down to brass tacks: the final criterion that's relevant here states "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
18:47:44 <adamw> (which in itself is a huge catch-all that's really a bit broad, but never mind)
18:47:59 <adamw> what would make a difference would be if we did not "offer" thinp "in a default installer configuration"
18:48:19 <adamw> i.e. if we hid it behind a 'not supported' warning or a secret sauce kernel aprameter like we did for btrfs
18:48:27 <adamw> that was the kind of thing we had in mind with 'tech preview', i think.
18:48:34 <jreznik> yep
18:48:58 <adamw> (not necessarily advocating that we actually do that, at this point, just answering notting's question as to what practical change can actually be made)
18:49:18 <notting> hm
18:49:24 <dlehman> adamw: more importantly, if we offer to create linear thin pools as part of a thinp config, are then somehow obligated to support every possible permutation of thinp that lvm can produce?
18:49:49 <adamw> dlehman: that's the kind of broader question we need to be looking at, but probably outside of a fesco meeting
18:49:54 <t8m> can we move on?
18:49:56 <notting> then along those lines, if i'm understanding the #3) of mitr's proposal of "no changes, blockers remain blockers as they arise"... i can be +1 to that
18:50:08 <adamw> and it kinda plays into this whole debate about whether we need to revisit how we handle storage completely and so on
18:50:19 <sgallagh> We are now way over the 15 minute limit. If I don't see a majority vote to continue, I'm just advancing us to the next topic...
18:50:37 <t8m> sgallagh, there was actually +5 on #3)
18:50:40 * nirik thought 3) of mitr's had enough votes already
18:50:57 * abadger1999 agrees with nirik
18:50:57 <sgallagh> too much discussion followed. If we want to revote on just that one, let's do that.
18:51:01 <abadger1999> sgaProposal: leave the decision of whether to hide or fix thinp to anaconda.  We're also okay with QA's interpretation of the criteria which may lead to release slippage if some thinp bugs are considered blockers.
18:51:11 <sgallagh> abadger1999/mitr: +1
18:51:15 <pjones> abadger1999: +1
18:51:16 <abadger1999> +1
18:51:18 <nirik> sure +1
18:51:21 <mattdm> abadger1999 +1
18:51:22 <notting> abadger1999: +1
18:51:25 <t8m> abadger1999, +1
18:51:57 <mitr> +1
18:52:00 <mattdm> I wouldn't mind seeing some release notes even though it's not a system-wide change.
18:52:07 <sgallagh> #agreed leave the decision of whether to hide or fix thinp to anaconda.  We're also okay with QA's interpretation of the criteria which may lead to release slippage if some thinp bugs are considered blockers (+7, 0 -0)
18:52:19 <sgallagh> On to new business
18:52:28 <sgallagh> #topic #1205 Workstation WG governance charter
18:52:31 <sgallagh> .fesco 1205
18:52:32 <zodbot> sgallagh: #1205 (Workstation WG governance charter) – FESCo - https://fedorahosted.org/fesco/ticket/1205
18:52:36 <t8m> +1
18:52:50 <mitr> +1
18:53:08 <notting> +1
18:53:14 <sgallagh> +1
18:53:30 <mattdm> I'm +1, with the pedantic caveat that this says "Work Group" where everything else has been "Working"
18:53:33 <jreznik> just a note - I'd like to thanks dlehman for his job he's doing
18:53:45 <mmaslano> +1
18:53:53 <nirik> +1
18:54:08 <pjones> +1
18:54:35 <sgallagh> #agreed Workstation Governance Document is approved (+8, 0, -0)
18:54:39 <abadger1999> +1 jwb, just to be clear, abstentions are different than in iether fesco or in env&stacks, correct?
18:54:46 <sgallagh> #undo
18:54:46 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x25698690>
18:54:51 <sgallagh> #agreed Workstation Governance Document is approved (+9, 0, -0)
18:54:56 <pjones> abadger1999: you mean than in board?
18:55:09 <abadger1999> pjones: well in fesco, abstention is == -1.
18:55:12 <pjones> abstentions here are not votes against.
18:55:22 <pjones> you're confused about which meeting you're in ;)
18:55:25 <abadger1999> In env and stacks, abstention is not a vote against but must be explicit.
18:55:31 <mattdm> so a vote could pass with 1 for and 8 abstentions.
18:56:00 <abadger1999> pjones: Hmm... Okay, That's what I kept saying but eveytime I brought it up in the meeting, I was corrected.
18:56:12 * abadger1999 must be in an alternate reality where things actually make sense.
18:56:18 <pjones> mattdm: no, you still need 5.
18:56:25 <abadger1999> hah!
18:56:27 <sgallagh> abstentions in FESCo are like voting for a third-party candidate.
18:56:33 <pjones> sgallagh: exactly ;)
18:56:40 <abadger1999> okay -- So I'm back in the reality where things don't make sense again :-)
18:56:55 <pjones> alright, since that's where you were looking to be, we can continue.
18:56:55 <abadger1999> pjones: If you still need 5, then an abstention is a -1.
18:56:56 <sgallagh> abadger1999: In FESCo, any proposal must get +5.
18:57:00 <mattdm> pjones if you still need 5, abstention ...
18:57:01 <abadger1999> (equivalent to)
18:57:04 <mattdm> right what abadger1999 says
18:57:08 <pjones> abadger1999: I don't agree with that statement, but let's move on ;)
18:57:15 <sgallagh> Moving on...
18:57:17 <mattdm> (it's just math.)
18:57:27 <sgallagh> #topic #1203 Soft dependencies
18:57:30 <sgallagh> .fesco 1203
18:57:30 <pjones> (it's not just math, there's a record you're responsible for.)
18:57:31 <zodbot> sgallagh: #1203 (Soft dependencies) – FESCo - https://fedorahosted.org/fesco/ticket/1203
18:57:38 <jwb> uh, wait
18:57:38 <mattdm> pjones fair enough.
18:57:40 <abadger1999> anyhow, we can move on; I can clarify with jwb on ticket.
18:57:49 <jwb> ok, fine
18:58:07 <mattdm> (ftr I'm okay with either way, but it probably should be clear)
18:58:15 <abadger1999> <nod>
18:58:33 <sgallagh> I'm not really clear what the reporter wants here.
18:58:57 <mitr> Proposal: FESCo doesn't want soft dependencies now or for the forseeable future
18:59:02 <sgallagh> I think they're just looking for "FESCo does[n't] forbid soft dependencies"
18:59:03 <mitr> sgallagh: ^^^, except in the other direction, I think
18:59:04 <notting> sgallagh: as i read it, a statement of purpose
18:59:11 <t8m> mitr, -1
18:59:19 <mattdm> I think this is -> FPC
18:59:30 <nirik> I could go either way depending on how it was implemented. ;)
18:59:31 <mmaslano> mattdm: why?
18:59:31 <notting> sgallagh: i.e., is fesco ok with soft dependencies as a concept, before they go to hash out what the policy is
18:59:43 <mmaslano> notting: yea
18:59:52 <mattdm> mmaslano Because that part of the question is basically about packaging standards.
18:59:57 <abadger1999> mitr: eh -- I'd be okay with soft dependencies but I really want to understand what that means in practical matters... therefore, I'd want the dep solvers to weigh in on what their plan is before voting.
19:00:13 <nirik> I'm ok to exploring the idea, but yeah, what abadger1999 said.
19:00:17 <mmaslano> sgallagh: Mirek and rpm guys had a longer discussion. The question is if we like to see soft dependencies in Fedora or not. Easy
19:00:48 <pjones> abadger1999: I'm somewhere between you and mattdm here.  By which I mean you both seem to be right.
19:00:56 <mitr> abadger1999: I think 1) it doesn't bring all that much that is useful, 2) figuring out "what it means" and designing it is too much work, 3) implementing is too much work => let's just not bother.
19:01:06 <pjones> mmaslano: that's only easy if "soft dependencies" means one thing.  It does not.
19:01:06 <nirik> I don't want us saying "+1, go and explore" to be seen as "whatever you decide is fine to implement"
19:01:07 <abadger1999> There definitely would be an FPC portion to this... I'm not sure whether it's 100% FPC or partially fesco, though.
19:01:18 <sgallagh> mitr: I'm not sure that'
19:01:25 <sgallagh> s a reasonable way to make the decision
19:01:32 <notting> proposal: FESCo would be ok with some implementations of soft dependencies. If you want a more clear ACK or NAK, come up with an implementation.
19:01:37 <sgallagh> I'm not about to demand support for it, but I could be okay with not forbidding it
19:01:39 <abadger1999> pjones: +1 to multiple definitions.
19:01:40 <nirik> notting: +1
19:01:46 <mattdm> sgallagh +1
19:01:48 <abadger1999> sgallagh: +1
19:01:55 <mattdm> notting +1
19:01:56 <abadger1999> notting: +1
19:02:05 <mmaslano> notting: +1
19:02:08 <pjones> notting: or maybe a /plan/ for an implementation?  we shouldn't ask them to do 100% of the work before getting approval
19:02:09 <mitr> notting: -1
19:02:09 <sgallagh> notting: +1
19:02:22 <abadger1999> pjones: yeah, I agree with that distinction too.
19:02:22 <notting> pjones: i like that wording better
19:02:29 <nirik> pjones: sure, agreed.
19:02:29 * mattdm nods
19:02:31 <sgallagh> +1 to pjones rewording
19:02:35 <pjones> also /If you want/To get/
19:02:42 <abadger1999> don't need code, just an explanation of what the behaviour is going to be.
19:02:44 <jwb> "plan for an implementation" is otherwise known as "design"
19:02:49 <pjones> I'd rather not suggest that they don't need one ;)
19:02:55 <pjones> jwb: you could use that word as well, sure.
19:03:09 <mitr> sgallagh: Why isn't a rough estimate of the risk/reward a good way to decide?  To me it seems fairly decisive.  Or are you disagreeing with the value judgements but not the principle?
19:03:25 <t8m> notting, +1
19:03:28 <t8m> pjones, +1
19:04:10 <sgallagh> mitr: I'm disagreeing with the value judgements. It sounded like your argument was "it's too much work, so let's not bother" (which didn't really sound like you, so I may have misinterpreted)
19:04:15 <abadger1999> mitr: I think the problem right now is that there's not an adequate understanding of the risk/reward without knowing what the plan is at the depsolver level.
19:04:29 <notting> re-worded proposal: FESCo would be OK with some implementations of soft dependencies. To get a more clear ACK or NAK, come up with an implementation design.
19:04:42 <nirik> +1
19:04:43 <abadger1999> +1
19:04:48 <mattdm> +1
19:04:49 <mitr> abadger1999: At best, the rewards is some saved disk space and more things to tinker with for people who like to tinker.  I don't value either much.
19:04:51 <sgallagh> +1
19:05:01 <mmaslano> +1
19:05:28 <sgallagh> mitr: Well, with "suggests" and "enhances", we can also offer new things that may need more disk space.
19:05:43 <sgallagh> But I'd still like to see a clear design
19:05:55 <sgallagh> I count +5; anyone else want to weigh in?
19:05:55 <notting> (i'm +1 to the proposal)
19:05:56 <mitr> sgallagh: In Server terms, I'm assuming you either install the role or don't, and that's pretty much the end of it.
19:06:28 <t8m> +1
19:06:30 <sgallagh> mitr: On that, I completely agree.
19:06:45 <sgallagh> The decision to NOT use soft dependencies in a package or set of packages will always be there
19:07:42 <mattdm> Of the things I'd like to see worked on in rpm (*cough* languages *cough*) this seems pretty low, but if someone really wants to work on it and won't automatically go do the thing I want to do if we say "no", then, eh, might as well say okay. :)
19:07:46 <sgallagh> That's +7. mitr: are you still -1? pjones: Can I assume +1 since you chose the phrasing?
19:07:52 <mitr> sgallagh: yes
19:08:17 <mattdm> I can see this potentially being useful in using the same packages in different ways for different products
19:08:27 <abadger1999> mattdm: I agree with the low priority of this to us as well.
19:08:36 <sgallagh> As do I
19:08:37 <abadger1999> for some definition of "us" :-)
19:08:57 <sgallagh> #agreed FESCo would be OK with some implementations of soft dependencies. To get a more clear ACK or NAK, come up with an implementation design (+7, 0, -1)
19:09:04 <sgallagh> #topic #1202 Release and Support lifecycle questions
19:09:08 <sgallagh> .fesco 1202
19:09:09 <zodbot> sgallagh: #1202 (Release and Support lifecycle questions) – FESCo - https://fedorahosted.org/fesco/ticket/1202
19:09:32 <sgallagh> Because we didn't have enough tough questions today...
19:10:07 <mattdm> I'm open to having different release cycles but think we need to tread carefully.
19:10:16 <t8m> I think they first would have to present the concrete plan with buy-in from infrastructure and releng
19:10:19 <mitr> I don't think we really know what anyone wants here.   Defer?
19:10:20 <nirik> I am against different release and support cycles at least at first
19:10:24 <sgallagh> I'm inclined to say that release cycles can be different but probably should not make that decision lightly
19:10:31 <pjones> sgallagh: yes
19:10:36 <mattdm> +1 to all of that :)
19:10:47 <mmaslano> sgallagh: definitely
19:10:54 <t8m> So unless there is any concrete plan we should defer.
19:11:00 <sgallagh> Well, I think we want to give some guidance here
19:11:04 <abadger1999> well..
19:11:07 <nirik> well, some working groups wanted to discuss/plan for this.
19:11:10 <abadger1999> yeah, exactly.
19:11:11 <notting> are the products *asking* to have separate release cycles?
19:11:11 <t8m> I would not reject "thinking about such plan" immediately.
19:11:13 <sgallagh> Because if we tell the products its ok, then they may choose to do so
19:11:23 <abadger1999> notting: sounded like base is in the ticket.
19:11:34 <nirik> and server has had some discussion around it.
19:12:24 <nirik> proposal: all products share initial release and support cycle (to be determined) and we revisit after initial release.
19:12:26 <sgallagh> Do we want to set any rules?
19:12:53 <t8m> nirik, OK, no problem with that +1
19:12:58 <sgallagh> For example, all WGs have to release on some multiple of Base's cycle? (Where multiple may be "one")
19:12:58 <Viking-Ice> nirik, what do you think we gain by with that
19:13:02 <mitr> nirik: -1 (premature)
19:13:33 <pjones> nirik: I think that's a good start, but not sure we should be making proposals and voting quite yet without some discussion...
19:13:45 <jreznik> would be nice to gather initial requirements from wgs
19:13:46 <notting> essentially, we have yet to define in any real sense how the different products interact in terms of shared components, forked components, build & release infrastructure, etc. - release cycle is part of that, but it's just one part
19:13:58 <abadger1999> nirik: I'd also add -- products that want separate cycles should let us know what they envision and we can start asking whether rel-eng/infra/qa/etc can handle that/what it would take to handle that after intial release.
19:13:59 <nirik> We gain: ability to use the same blocker/freeze process, ability to use the same package collection/update infra, ability to use the same marketing and releng resources, etc
19:14:02 <jreznik> notting, right
19:14:11 <Viking-Ice> I think you need to first answer if the fedora next will be developed and maintained on a separated branch
19:14:21 <sgallagh> nirik: Not necessarily the same package collection
19:14:24 <drago01> what does that mean for maintainers
19:14:33 <sgallagh> As notting mentioned, we may end up with some forked packages where it makes sense
19:14:38 <nirik> sgallagh: I think thats a really bad idea for the record. ;)
19:14:59 * jreznik would let decision on this to base wg
19:15:04 <abadger1999> sgallagh: that's probably another thing that needs to havew a fesco ticket and vote.
19:15:06 <nirik> "Hi, I installed fedora httpd-2.3 and..." which one?
19:15:14 <sgallagh> abadger1999: Sure
19:15:32 <mitr> nirik: With dist tags that's not at all a new problem
19:15:36 <drago01> sgallagh: and the vote should really be no ... you don't want to open this can of worms
19:15:46 <Viking-Ice> nirik, easily answered ( seperated branch == seperated brand )
19:15:53 <nirik> so to get down to it: are we now producting 3 distros? or are we sharing as many resources as makes sense and producing 3 products from that single distro?
19:16:02 <drago01> how do users file bugs?
19:16:05 <sgallagh> drago01: I probably agree on that in general, but it's a conversation we haven't had yetr
19:16:05 <mitr> nirik: unknown
19:16:14 <abadger1999> nirik: I am for the second of those.
19:16:19 <nirik> abadger1999: me too.
19:16:27 <nirik> others seem to be for the first. :)
19:16:27 <mattdm> me too to second
19:16:43 <mmaslano> nirik: I would prefer second
19:16:47 <mattdm> i'm open to hearing people who think we could have advantages from the other approach though.
19:16:51 <nirik> (or more toward it than I think is sane)
19:16:51 <sgallagh> I'm closer to the second than the first
19:17:07 <Viking-Ice> when and how are you going to cleanup the distribution ?
19:17:08 <sgallagh> But I would be okay with there being some differences.
19:17:20 <pjones> nirik: second please.
19:17:34 <sgallagh> e.g. Server might be required to carry extra compat libs or somesuch
19:17:39 <notting> mattdm: the original rings implied more towards the first, at least in the sense that the would be more separate
19:17:57 <nirik> anytime we don't share a resource between products there's going to be a cost... different release cycles, lifetime, branches, are all going to be high cost.
19:18:23 <mattdm> notting "that the (second ring) would be more separate"?
19:18:31 <Viking-Ice> keeping things the same will not make things more manageable for us in QA
19:18:36 <sgallagh> For what it's worth, my view is that we really should be differentiating between software useful to Fedora (the stuff that's part of the Products) and software that people might want to run *on* Fedora (Everything else)
19:18:53 <notting> mattdm: the different environments, stacks, etc. all being separate, and so on. in that world, is 'distro' a meaningful concept?
19:19:25 * sgallagh notes there's a reason he chose the term OS when originally talking about these three products, rather than distro.
19:20:33 <nirik> well, If we duplicate things it's more "raindrops" than clear rings. ;) I had the idea that all the existing packages stuff would be on one ring and things would use that, instead of duplicating that ring over to another area for their product. Then instead of rings we get the towers of hanoi to do releases. :)
19:21:04 <notting> nirik: well, until we use sendmail.cf to solve the deps of the release
19:21:12 <nirik> :)
19:21:15 <abadger1999> :-)
19:21:17 <sgallagh> nirik: Too many metaphors. I don't really follow.
19:22:24 <nirik> ok, to be more clear, I was envisioing that we would have package foo that would be used by serveral products, in that case it would be setup to work with any of them (compromising as needed), not split into bar/baz/goo for each product. I think that way lies support maddness.
19:22:49 <mmaslano> nirik: +1
19:23:02 <Viking-Ice> I would think the WG's exist to ensure such madness does not come to pass
19:23:16 <sgallagh> nirik: Ok, on that I agree completely.
19:23:19 <sgallagh> Viking-Ice: +1
19:23:40 <nirik> but who maintains all that junk? the wg members? the orig owner of foo?
19:23:43 <Viking-Ice> how is not breaking things into manageable pieces different then the mad world we live in now?
19:23:52 <notting> nirik: while i agree that is simplest, that is also ... not a huge change from now, if you look at how different groups for different use cases collaborate on the single package repo
19:24:25 <mattdm> nirik: I think that's the idea but we may need to have some places where a package splits because it's being used in a very different way and compromise just makes it unsuitable for both.
19:24:42 <nirik> notting: right. I see the value higher level at least to start with... integration, best practices, testing, etc.
19:24:51 <mitr> nirik: I don't like to argue this in the abstract.  I expect package divergence to be rare, but I don't see it's obvious that it should be ruled out.
19:24:57 <sgallagh> Yeah, what do we do if we really DO need a package with different build flags?
19:25:28 <t8m> can we please move on? I think we're seriously off topic
19:25:30 <sgallagh> I suppose we can just create a new SRPM/set-of-subpackages
19:25:31 <pjones> sgallagh: it's called "working together to resolve the issue"
19:25:33 <nirik> anyhow, I think we are drifting. ;)
19:25:34 <mitr> t8m: yes please
19:25:45 <nirik> so, people want to defer this?
19:25:49 <sgallagh> So do we want to make any kind of response to this ticket, or defer?
19:25:52 <nirik> or say that initially we will share release cycles?
19:25:53 <mattdm> Yeah this is am important conversation but kind of in the weeds on the ticket itself.
19:26:18 <mitr> defer (not to next week, but until there actually is a proposal)
19:26:27 <nirik> well, I had one a while back...
19:26:28 * sgallagh still thinks tying to multiples of whatever the Base WG decides on would be reasonably sane
19:26:29 <t8m> Proposal: No resolution until there is a concrete proposal
19:26:33 <abadger1999> nirik: +1
19:26:34 <nirik> proposal: all products share initial release and support cycle (to be determined) and we revisit after initial release.
19:26:50 <notting> nirik: i'd be -1 to that fo rnow
19:26:54 <sgallagh> nirik: -1
19:26:58 <mitr> nirik: -1
19:27:04 <notting> (might end up +1 once we get further into planning)
19:27:05 <nirik> ok. :)
19:27:11 <nirik> I mean... RAGEQUIT!!!!!
19:27:15 <mattdm> lol
19:27:24 * nirik is fine with defer if there's not enough votes to pass
19:27:24 <t8m> nirik, I'm changing my vote to abstain
19:27:28 <mattdm> I want to defer
19:27:32 <abadger1999> nirik: +1
19:27:47 <mmaslano> defer and move to next topic
19:27:58 <mattdm> Although I think we should also give guidance saying that we expect schedules to be coordinated.
19:28:14 <abadger1999> I'm okay to defer but -- a concrete proposal is unlikely to be usable for the initial release anyhow.
19:28:26 <abadger1999> because there's so many other parts of hte project to coordinate.
19:28:28 <nirik> abadger1999: agreed.
19:28:43 <Viking-Ice> abadger1999, oh I'm pretty sure that can be done
19:28:54 <Viking-Ice> having likely concrete proposal
19:29:18 <t8m> +1 to defer
19:29:39 * abadger1999 nots that Harald made a concrete proposal in the fesco ticket... but I don't know if that's just his proposal or if the WG he's on is approving of it.
19:29:45 <abadger1999> s/nots/notes/
19:29:54 <sgallagh> Proposal: If working groups want to use different cycles, they should provide justification by <date> for us to make a decision.
19:30:26 <mattdm> where <date> = january with the rest of the prd? or before, or after?
19:30:36 <mitr> sgallagh: Isn't that basically "the discussion in this ticket will start by <date>"?
19:30:39 <nirik> should be before right? so they can adjust anything if thats not the plan
19:30:43 <sgallagh> I would say "before", since it'll affect the output
19:30:49 <abadger1999> sgallagh: not so much justification but plan.  and I'm more wanting them to be aware that they can have a plan but it may not be implemented for several releases.
19:31:17 <sgallagh> abadger1999: Care to suggest a rephrasing?
19:32:03 <notting> "Along with the PRD, the products should submit a preferred release cadence and lifecycle, and what they can tolerate"?
19:32:38 <pjones> notting: you know that's going to get back random, incoherent results in terms of "what they can tolerate", right?
19:32:55 <notting> pjones: probably. so maybe just the preferred, and then we stick them all in a blender
19:33:07 <abadger1999> Proposal: If working groups want to use different cycles, they should provide us with what they want to do along with the PRD.  They should be aware that even if we can okay the plan, it is unlikely to be implementable for one or more releases. Please do not make your PRD depend on an alternate release lifecycle.
19:33:25 <sgallagh> Yeah, let's just ask for preferred and then make it a FESCo task to get them aligned sensibly or overruled if alignment is impossible
19:33:31 <pjones> notting: I think we're going to need to ask for a preferred cycle and a rationale
19:33:32 <nirik> abadger1999: +1
19:33:41 <sgallagh> abadger1999: +1
19:33:59 <abadger1999> +1
19:34:05 <mitr> -1 "we all need to talk to each other, and do, and nobody will remember this proposal in a month anyway (or do we need to set up a PRD policy?)"
19:34:05 <mmaslano> +1
19:34:08 <pjones> abadger1999: same statement applies to your proposal - if we're going to ask them for what they'd like, that's not going to be meaningful unless we know why alongside that.
19:34:20 <sgallagh> pjones: Good point. abadger1999: can you do s/provide us with what they want to do/ provide us with what they want to do and a rationale/
19:34:39 <nirik> sure, I assumed that, but ok
19:34:40 <pjones> (but mitr also has a point)
19:34:53 <abadger1999> Proposal: If working groups want to use different cycles, they should provide us with what they want to do with rationale along with the PRD.  They should be aware that even if we can okay the plan, it is unlikely to be implementable for one or more releases. Please do not make your PRD depend on an alternate release lifecycle.
19:34:59 <t8m> abadger1999, ₊
19:35:07 <t8m> abadger1999, +1
19:35:14 <nirik> +1
19:35:18 <abadger1999> +1
19:35:19 <pjones> +1
19:35:21 <mattdm> abadger1999 +1
19:35:26 <sgallagh> abadger1999: +1 with the rationale note
19:35:42 <notting> abadger1999: i can be ok with that. i guess the 'once we have the PRDs' comes the great hashing out of "how do we actually do this again?"
19:36:06 <nirik> we should communicate this to the non fesco liasions as well to take back to their groups.
19:36:15 <sgallagh> I'll do that
19:36:19 <abadger1999> sgallagh: thanks
19:36:30 <abadger1999> They should all be cc'd o nthe fesco tickets now too?
19:36:40 <nirik> abadger1999: yes, so if we update ticket they should see it too.
19:36:50 <sgallagh> I see +6; any other votes?
19:36:52 <sgallagh> mitr: You still -1?
19:36:54 <abadger1999> (but it never hurts to specifically call something out in email )
19:37:07 <mitr> sgallagh: yes (... I can't see what we are accomplishing now)
19:37:34 <abadger1999> mitr: All I want with this is to set expectations appropriately.
19:37:41 * sgallagh assumes mmaslano is +1 still from the first version
19:37:57 <mitr> abadger1999: the -1 is kind of strange, I admit...
19:38:09 <mmaslano> yeah +1
19:38:14 <mitr> abadger1999: still, aren't these expectations already the default (or even a stricter version?)
19:38:14 <sgallagh> #agreed If working groups want to use different cycles, they should provide us with what they want to do with rationale along with the PRD.  They should be aware that even if we can okay the plan, it is unlikely to be implementable for one or more releases. Please do not make your PRD depend on an alternate release lifecycle. (+7, 0, -1)
19:38:33 <sgallagh> mitr: It was obviously unclear, or it wouldn't have been asked
19:38:47 <sgallagh> Anyway, can we move on?
19:38:52 <sgallagh> I have only 20 minutes left.
19:38:55 <nirik> please
19:39:07 <sgallagh> #topic #1206 Allowed licenses in Copr
19:39:10 <sgallagh> .fesco 1206
19:39:10 <abadger1999> mitr: I.... Don't know.  From jwb's original (general policy on how much autonomy the WG's have) I'm not sure that expectations are all the same right now.
19:39:11 <zodbot> sgallagh: #1206 (Allowed licenses in Copr) – FESCo - https://fedorahosted.org/fesco/ticket/1206
19:39:16 <sgallagh> Man, when it rains it pours...
19:39:58 <nirik> so, really we are being asked if we should allow licenses that are not ok for fedora packages to be coprs... but this puts a burden on fedora legal to review them each.
19:39:58 <sgallagh> Proposal: COPR projects must use approved Fedora licenses for now.
19:40:25 <jwb> nirik, to be fair, that burden exists whether they're officially allowed or not
19:40:33 <pjones> sgallagh: +1
19:40:39 <t8m> sgallagh, -1
19:40:43 <jwb> because if nothing on coprs is reviewed, then it doesn't matter what you say here anyway
19:40:48 <mitr> sgallagh: 0 IMHO not a FESCo matter
19:40:50 <abadger1999> sgallagh: +1
19:40:59 <mattdm> sgallagh: +1
19:41:10 <nirik> jwb: not exactly... there's at least expectations and easier for others to check things.
19:41:13 <nirik> sgallagh: +1
19:41:15 <sgallagh> jwb: Having an official statement on permissable content is sensible though
19:41:17 <pjones> mitr: nominally we're also the technical overseers for e.g. infrastructure and whatever is hosted on it
19:41:31 <jwb> sgallagh, yes, agreed.  there is still burden to actually do review though
19:41:48 <jwb> nirik, i'm not sure it's easier to review.  it's easier to justify removal
19:41:55 <mattdm> +1 jwb
19:41:56 <nirik> I suppose
19:42:06 <mmaslano> sgallagh: I also don't think it's FESCo matter
19:42:32 <mattdm> mitr/mmaslano -- board or legal? or something else?
19:42:37 <mmaslano> packages from copr don't go into Fedora repositories so..
19:42:57 <pjones> mattdm: I do suspect legal will have the last say here if we do anything /but/ approve this proposal.
19:43:02 <sgallagh> mmaslano: But they are technically distributed by the Fedora project
19:43:10 <mitr> mattdm: legal for principal permissibility (but we seem to already have an answer), board for trademark and infra usage
19:43:12 <mattdm> mmaslano Oh, I don't think that's the defining factor. Fedora is bigger than "in the repos".
19:43:17 <sgallagh> I could see this being a Board decision, though
19:43:24 <jwb> mitr, there is no trademark usage here
19:43:41 <abadger1999> When I talked with skvidal about Copr and licensing, he talked about having the policy and removing offenders like jwb says... I can't recall if he had talked to spot about that, though.
19:43:49 <mitr> jwb: I disagree but see your point
19:43:55 <pjones> mattdm: precisely.  we're overseeing technical matters for Fedora.  not for Fedora's repos, which are merely some of the output.
19:43:59 <mmaslano> abadger1999: yeah and the functionality is still there
19:43:59 <notting> right now, as posted in the ticket... it seems to be a request for how much work we want to make legal do, no?
19:44:02 * nirik shrugs. We could just decide in FI I suppose too (this was filed without infrastructure discussion of it first)
19:44:49 <jwb> if you take this to the Board, i'm going to ask that coprs be suspended from production until a decision is reached.
19:44:55 <jwb> as in, not usable.
19:44:56 <pjones> (also we're at +5 assuming sgallagh's vote)
19:45:04 <sgallagh> jwb: Taking hostages now?
19:45:07 <sgallagh> ;-)
19:45:34 <sgallagh> pjones: I'm leaning +1, yes.
19:45:38 * pjones has to go
19:45:40 <jwb> sgallagh, not at all.  if it's not something you feel comfortable deciding, then it's clearly a piece of technology that isn't ready to be used.
19:45:41 <mmaslano> jwb: are you joking? people just started using it
19:45:42 <notting> i'm +1 to keeping the fedora package license restrictions unless someone comes up with a specific compelling case not to
19:45:43 <sgallagh> Not strongly, which is why I haven't said it.
19:45:48 <jwb> mmaslano, no, i'm not joking
19:46:03 <nirik> so, we have enough, lets approve and move on?
19:46:16 <mattdm> I'm comfortable with FESCo making decisions on this kind of thing.
19:46:17 <sgallagh> Ok, I'm +1 as well. We can always loosen it later if we see the need
19:46:36 <jwb> mattdm, not speaking for the Board, i'm comfortable with that as well
19:46:38 <sgallagh> #agreed COPR projects must use approved Fedora licenses for now (+6, 0, -1)
19:46:43 <t8m> please can we count votes and move on
19:46:48 <t8m> good
19:46:59 <sgallagh> #topic #1204 F21 System Wide Change: Python 3.4 -https://fedoraproject.org/wiki/Changes/Python_3.4
19:47:04 <sgallagh> .fesco 1204
19:47:05 <iThinkDev> i'm jus waching
19:47:06 <zodbot> sgallagh: #1204 (F21 System Wide Change: Python 3.4 - https://fedoraproject.org/wiki/Changes/Python_3.4) – FESCo - https://fedorahosted.org/fesco/ticket/1204
19:47:48 <notting> i would be the normal ACK on this, but how does this fit in an env&stacks world?
19:47:52 <mattdm> release notes should be for _fedora_ release notes, not pointing to upstream
19:48:03 <nirik> +1 here
19:48:04 <t8m> +1
19:48:12 <abadger1999> Update from python3.3 to 3.4.  There's going to be a bit of work around unbundling but there's a plan for it.
19:48:13 <mmaslano> notting: um we didn't even speak about updates of languages
19:48:15 <abadger1999> I'm +1
19:48:17 <mitr> +1
19:48:19 <mmaslano> +1
19:48:24 <iThinkDev> +1
19:48:31 <mattdm> notting I think it's not a big deal since it's a forward-compatible change to the python 3.x stack.
19:48:36 <mattdm> +1
19:48:36 <sgallagh> iThinkDev: You are not FESCo, you do not get to vote.
19:48:46 <abadger1999> notting: env and stacks hasn't talked much about it yet but I don't think env and stacks has any new technology that would change this at this point.
19:48:58 <mitr> notting: I think when env/stacks comes up with a way to treat runtimes, we might want to revisit (and not just Python); for now this is a reasonable plan of record
19:48:59 <iThinkDev> sory
19:49:01 <notting> mattdm: mmaslano: yes, i'm just wondering if we move to envs & stacks providing stacks of langauges, is this a 'fedora' systemwide change?
19:49:05 <sgallagh> +1
19:49:09 <notting> in any case, sure, latest python, go for it. +1
19:49:23 <abadger1999> (ie: at present, we wouldn't be isolating the python stacks or building them into a separate repo or anything like htat).
19:49:30 <nirik> iThinkDev: no biggie ;)
19:49:30 <mmaslano> notting: maybe. env & stacks area is not very clear
19:49:30 <notting> just wanted the idea of the handwavy future out there
19:49:30 <mattdm> notting Until we do something different, it affects the base python
19:49:34 <sgallagh> #agreed Python 3.4 Change is approved (+8, 0, -0)
19:49:37 <jwb> python might also fall into Base
19:49:40 <jwb> fwiw
19:49:44 <sgallagh> iThinkDev: Sorry, it just makes it harder to count.
19:49:59 <mattdm> mmaslano -> will still post that message to env & stacks wg i promised i would :)
19:50:20 <sgallagh> #topic #1201 Enabling third party repositories
19:50:23 <sgallagh> .fesco 1201
19:50:24 <zodbot> sgallagh: #1201 (Enabling third party repositories) – FESCo - https://fedorahosted.org/fesco/ticket/1201
19:50:52 <sgallagh> We have ten minutes; Proposal: defer to next week.
19:51:07 <nirik> can we do a test vote to see where folks are?
19:51:09 <jwb> next week is bad
19:51:28 <jwb> are you even having a meeting next week?  i would expect most of the US people to be out for holidays
19:51:34 <sgallagh> nirik: Come up with a proposal?
19:51:46 <sgallagh> jwb: We'll discuss that in Open Floor, I guess...
19:52:01 <mattdm> I think there are some questions for Legal here too.
19:52:24 * sgallagh doesn't believe we can decide this in the remaining time.
19:52:33 <jwb> sgallagh, order of operations matters here.  if you're going to defer something to next week, you need to make sure next week exists
19:52:33 <sgallagh> If people want to continue without me...
19:52:44 <notting> "However, after talking with Fedora Legal, the requirements for us to be able to point to repositories outside of our control may be so costly that in practice there's very few repositories that we can actually point to. "
19:52:56 <nirik> proposal: no 3rd party repos shipped or enabled.
19:53:04 <sgallagh> nirik: +1
19:53:18 <sgallagh> Actually, hold
19:53:33 <notting> are those above referenced requirements what spot says in comment #7?
19:53:42 <t8m> nirik, -1 for now
19:53:42 <sgallagh> Are we ruling this for the standard repos only, or are we going to allow COPRs to ship an enabled repo for their content on-demand?
19:53:48 <abadger1999> notting: my impression from the FPC meeting was no.
19:54:11 <abadger1999> notting: Comment#10, fedora legal bullet point was my impression from the FPC meeting.
19:54:19 <nirik> sgallagh: "copr/repos.fedorapeople.org can be considered third-party for the purposes of Fedora Legal's responsibilities."
19:54:57 <sgallagh> nirik: I read that to mean that the standard Fedora repos couldn't contain packages with repo files pointing to COPRs
19:54:58 <abadger1999> comment#7 spells out what would be legal.  comment #10 spells out what Fedora legal would need to ensure the repos were in compliance with #7.
19:55:11 <sgallagh> Not whether they were allowed to ship repo files themselves
19:55:27 <nirik> oh I see. I think thats seperate...
19:55:29 <sgallagh> nirik: I think I'd need that spelled out
19:55:59 <mmaslano> -1 for now, I guess we should have more repositories, but we need to figure out, which are good for us
19:56:00 <abadger1999> sgallagh: yes, my understanding is that would be separate.
19:56:14 <sgallagh> abadger1999: Separate ruling?
19:56:43 <abadger1999> sgallagh: but it's also possible that copr repos haven't fully been looked at by fedora legal... short answer -- need to clarify with spot.
19:56:54 <sgallagh> Proposal: Defer to the next FESCo meeting and ask further questions in the ticket for clarification.
19:57:00 <mattdm> Given that we can't point to repos with "legally problematic" packages, I'd be more for finding a way to get repos without those problems under the Fedora umbrella directly.
19:57:31 <abadger1999> mattdm: I think that was spot's suggestion as well.
19:57:52 <t8m> sgallagh, +1
19:57:53 <sgallagh> Ok, if this conversation is going to continue, I need someone else to take over the chair.
19:58:05 <notting> i'm +1 to postpone to next meeting
19:58:12 <mattdm> +1 postpone to next meeting
19:58:12 <nirik> sure, defer
19:58:33 <abadger1999> I'm okay with defer -- it would be nice to invite spot explicitly as well.
19:58:41 * nirik nods
19:58:43 <sgallagh> #agreed Defer to the next FESCo meeting and ask further questions in the ticket for clarification.
19:58:49 <sgallagh> #topic Next week's chair
19:59:02 <sgallagh> Who will not be here next week? I expect to be around.
19:59:04 <nirik> are we meeting next week? who will be around?
19:59:04 <mmaslano> I can do it
19:59:09 * nirik should be around
19:59:28 <sgallagh> #info mmaslano to chair the next meeting
19:59:34 <notting> i will not be around
19:59:49 <nirik> I guess if we have no quorum we just punt to the following week
19:59:53 <mattdm> I may or may not be depending on how that day goes
20:00:05 <mitr> I'll probably be around
20:00:25 <sgallagh> Ok, I count at least 5 of us, so we'll expect the meeting to occur
20:00:27 * abadger1999 has been around traditionally but lately been thinking he should spend more time with the kids
20:00:51 <sgallagh> #topic Open Floor
20:00:55 <Viking-Ice> will the output of fedora WG's  be developed and maintained on a separated branch and released under a separated brand Or will current Fedora be altered to the output of WG's products and their images ?
20:01:20 <sgallagh> I am now late for my next meeting, can someone please take over?
20:01:31 <abadger1999> I would not want the first of those options.
20:01:31 <mattdm> i also have to run off.
20:01:33 <sgallagh> I'll handle the tickets later
20:01:47 <abadger1999> sgallagh: If you also handle mailing the meeting notes, you've got a deal :-)
20:01:54 <sgallagh> abadger1999: Done
20:01:57 <sgallagh> Thanks
20:01:58 <abadger1999> Cool.
20:02:01 <t8m> can we just have hard stop just now? 2 hours is enough
20:02:05 * nirik also doesn't want the first option.
20:02:10 <jwb> Viking-Ice, i would expect the latter.  e.g. there won't be Workstation, Server, Cloud, and then a "traditional" f21 release
20:02:27 * abadger1999 agrees with jwb on that.
20:02:34 <nirik> right
20:02:51 <Viking-Ice> well that answers QA participation in this as well thanks
20:02:52 <abadger1999> Okay.  Any followups or anything else?
20:03:21 <abadger1999> #endmeeting