17:59:49 <sgallagh> #startmeeting FESCO (2014-03-05)
17:59:49 <zodbot> Meeting started Wed Mar  5 17:59:49 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:59:55 <sgallagh> #meetingname fesco
17:59:55 <zodbot> The meeting name has been set to 'fesco'
18:00:01 <sgallagh> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
18:00:01 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:06 <sgallagh> #topic init process
18:00:16 <mitr> Hello
18:00:22 <pjones> hi.
18:00:24 <nirik> morning
18:00:25 * dgilmore is here
18:00:25 <abadger1999> hola
18:00:28 <sgallagh> .hellomynameis sgallagh
18:00:30 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:00:45 <sgallagh> notting will be a few minutes late
18:02:47 * sgallagh waits two more minutes before proceeding
18:03:11 <mattdm> hi!
18:03:54 <t8m> hi all
18:04:12 <sgallagh> #info mitr pjones nirik abadger1999 dgilmore sgallagh mattdm t8m present. notting coming shortly
18:04:23 <sgallagh> That's everyone, then
18:04:31 <sgallagh> #topic #1178 	Fedora 21 scheduling strategy
18:04:39 <sgallagh> .fesco 1178 https://fedorahosted.org/fesco/ticket/1178
18:04:39 <zodbot> sgallagh: Error: '1178 https://fedorahosted.org/fesco/ticket/1178' is not a valid integer.
18:04:43 <sgallagh> .fesco 1178
18:04:44 <zodbot> sgallagh: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178
18:05:49 <mitr> So we got a few technical specifications... were there any scheduling requests?
18:06:46 <sgallagh> In Server, we discussed that if we want to have Cockpit support, we're probably in a "not before September" situation.
18:07:14 <sgallagh> I think Workstation has also noted that October would be preferable to time with GNOME 3.14
18:07:19 <mattdm> We don't have any in particular in Cloud. We will just be less ambitious if it is earlier.
18:08:12 <dgilmore> I personally like October
18:08:22 <t8m> The Cockpit support could be handled through the change process, couldn't it? This would be another step for collecting the knowledge of needed resources (including time) to finish
18:08:28 <nirik> when is gnome 3.14 scheduled again?
18:08:34 <jwb> sgallagh, that point was brought up by adamw i think.  not sure Workstation actually said anything either way, but i can imagine there wouldn't be a huge objection
18:09:49 <adamw> drago01: ping?
18:10:01 <sgallagh> t8m: Well, Cockpit is shaping up to be the primary way we handle Server Roles in the first pass, so it's pretty tightly integrated
18:10:05 <adamw> (just picking a desktop folk who happens to be here)
18:10:14 <pjones> a folk?
18:11:50 <sgallagh> Proposal: Fedora 21 will target a release at the end of October
18:11:56 <t8m> sgallagh, +1
18:12:22 <abadger1999> sgallagh: Note about cockpit... there's  an unresolved bundling issue with it, we'll have to get that sorted.
18:12:34 <pjones> abadger1999: but that's still something we can handle through Changes
18:12:36 <sgallagh> abadger1999: Not any more.
18:12:38 * abadger1999 puts that ticket onto the FPC meeting agenda
18:12:41 <drago01> adamw: pong
18:12:47 <mitr> abadger1999: If it's not affecting the schedule in the order of months, let's not discuss the details here
18:12:49 <pjones> Or not, apparently ;)
18:12:49 <mattdm> How about targetting _beginning_ of october, to give our traditional room to slip?
18:12:49 <sgallagh> abadger1999: They got tired of waiting and fixed that :)
18:12:50 <abadger1999> sgallagh: oh, okay -- update me on the status after hte meeting.
18:13:20 <adamw> drago01: see discussion about gnome 3.14 scheduling - does desktop team have any notes?
18:13:34 <adamw> drago01: just a few lines before i pinged you
18:13:53 <dgilmore> sgallagh: im +1 to your proposal
18:14:07 <mitr> I'm not too thrilled about extending the release to ~11 months
18:14:09 <drago01> adamw: ah no "offical" schedule yet but should be around end of sep. like every year
18:14:33 <mitr> OTOH I can live with it, I suppose.
18:14:35 <nirik> mitr: on the plus side, it means f20 is a long term release. ;)
18:14:44 <dgilmore> nirik: and f19 :)
18:14:53 <nirik> yeah, but 20 more so even
18:14:59 <adamw> drago01: and i guess desktop team would like it if f21 release schedule was timed to include 3.14?
18:15:04 <dgilmore> have we ever decided to change the release support lifecycle?
18:15:10 <nirik> dgilmore: nope.
18:15:33 <mitr> nirik: In an unplanned way that our contributors didn't sign up for :/
18:15:43 * nirik nods
18:15:43 <abadger1999> dgilmore: not yet for fedora.next.
18:15:57 <drago01> adamw: can't speak for others but that seems to be what most want (go back to an aligned schedule)
18:16:02 <sgallagh> dgilmore: Still an open question, but generally accepted to mean "Not for F21"
18:16:42 <drago01> adamw: oh and 3.14 means better / more complete wayland ;)
18:17:07 <t8m> mitr, do you think it is a real problem?
18:17:11 * jreznik is a bit late - we have our team meeting
18:17:12 * nirik is not opposed to changing the release cadience, but is very opposed to having different release cycles per product.
18:17:30 <mattdm> If there is a general consensus that the lifecycle "deal" for fedora is "~ 13 months", not necessarily "n + 1 + one month" if n is long, we could look at retiring F19 early
18:17:45 <jreznik> do you want to set the release schedule today or I thought it's going to be more based on Changes proposed (and yeah, I asked people to share the dates in changes)
18:17:50 <mitr> t8m: I don't think it's a deal-breaker.  I do favor shorter release cycles in general ("the sooner the deadline is, the sooner things get done")
18:17:50 <sgallagh> mattdm: That should be a separate topic, I think
18:17:51 <t8m> mattdm, -1
18:17:55 <sgallagh> Let's not divert too far here
18:17:56 <jreznik> but yeah, it's october for sure now
18:18:02 <drago01> mattdm: ugh no
18:18:10 <mattdm> just throwing that out there :)
18:18:15 <drago01> mattdm: always have been "n + 1 + 1"
18:18:30 <mitr> jreznik: based on what?  So far I've seen third-party suppositions of what Workstation would want; do you have other reasons to say "for sure"?
18:18:36 <t8m> mitr, I think we should go back to the shorter release cycle after F21, just this single release should be special
18:19:02 <dgilmore> we really can't do different cycles per product
18:19:04 <drago01> t8m: we should go back to the old may/oct model
18:19:13 <dgilmore> not without forking the distro
18:19:21 <mattdm> I agree that we should just schedule this release now and leave the larger cycle question for _after_ f21
18:19:34 <pjones> mattdm: ick
18:19:41 <pjones> that's how we get stuck doing things we don't like.
18:19:42 <jreznik> drago01: but I'm not sure for how long we would be able to fulfil it
18:20:04 <sgallagh> mattdm: I don't think we need to wait that long, but I don't feel this is the right conversation to have it
18:20:09 <drago01> jreznik: why? we managed to do it more or less for years
18:20:15 <mattdm> pjones okay, then: let's answer the schedule question now, and then deal with the larger cycle as part of a separate agenda item
18:20:17 <mitr> t8m: Right.  I don't really want to be just stop energy here - it just seems to me that we are "drifting" towards extending the release further and further "by default" without any single strong reason, the way we ended up with ~54 "voting" positions without any single strong reason
18:20:33 <drago01> also longer cycle somehow contradicts with our "First" foundation
18:20:36 <jreznik> drago01: but then we decided we'd like to really plan the release
18:20:50 <jwb> drago01, frankly, too much emphasis is put on that
18:20:56 <drago01> jreznik: chicken-egg
18:21:00 <drago01> ;)
18:21:02 <jwb> it doesn't matter if you're first if what you're first in doesn't work
18:21:02 <abadger1999> +1 to October for F21.
18:21:10 <nirik> proposal: have jreznik work up a proposed schedule based on a f21 release in later october, review and discuss next week?
18:21:10 <mattdm> (mitr I actually feel like there is a very strong reason. but this is _definitely_ a topic for a different discussion)
18:21:17 <drago01> jreznik: we cannot be feature and time based on the same time
18:21:23 <t8m> nirik, why later october?
18:21:26 <jreznik> nirik: I'd say earlier october
18:21:42 <nirik> sure, ok. I don't care... just october? whatever is actually being proposed?
18:21:47 <mattdm> I am definitely +1 to october but Ialso am in favor of earlier.
18:21:53 <jreznik> nirik: say october and I can prepare more versions
18:21:55 <nirik> (which is why a thing with dates might be nice to review before  +1ing it)
18:21:56 <mattdm> i mean earlier october
18:22:11 <drago01> earlier october means later october anyway
18:22:17 <mattdm> drago01 exactly
18:22:21 <dgilmore> lets look at October 14 as release date
18:22:23 <abadger1999> Basically, I see F21 as a "Features" driven release instead of a time driven release.  Where the "Features" have to do with changes to how we create Fedora (not the changes to the software inside of Fedora).
18:22:23 <jreznik> and I'd really to see more adjustments based on on Changes proposed
18:22:24 <mattdm> and later october means "thanksgiving"
18:22:26 <sgallagh> nirik: Yeah, I was expecting my proposal to be outright shot down got being ambiguous. I just needed to focus the discussion
18:22:33 <t8m> drago01, later october means november then :D
18:22:38 <mitr> nirik: ok, +1; this also gives us a week to receive the Change proposals which may actually contain scheduling requests
18:22:39 <drago01> t8m: indeed ;)
18:22:46 <nirik> mitr: yep. that too.
18:22:49 <dgilmore> we have Oct 7 14 21 or 28 as potential release dates
18:23:10 <dgilmore> proposal: have jreznik do a schedule based on a Oct 14 release date
18:23:11 <nirik> but I want to know what that means for alpha/beta, when we could do mass rebuild/branch, etc.
18:23:19 <mattdm> dgilmore +1
18:23:29 <sgallagh> dgilmore: +1 works for me
18:23:30 <dgilmore> then we can see if it needs early tweaking
18:23:45 <abadger1999> +1 early October... I'm a little worried about slipping into the holidays if we don't start with a target in early October.
18:23:45 <t8m> why not oct 7 but +1 to Oct 14 anyway
18:23:54 * mattdm echoes t8m
18:24:00 <mitr> dgilmore: +1 wfm
18:24:04 <pjones> I'd be happier with the 7th as well
18:24:08 * abadger1999 sane as t8m.
18:24:12 <pjones> I've worked over too many thanksgiving holidays
18:24:27 <sgallagh> Revised then to ask him to provide examples of both?
18:24:27 <jreznik> the scheduling rules say "on a Tuesday as close as possible to October 31st" but I really prefer earlier date and 14th would be ok
18:25:02 <jreznik> sgallagh: I'm ok with it, once I have it in TJ, I can do everything
18:25:07 <t8m> jreznik, where is the 31st coming from?
18:25:35 <sgallagh> TJ?
18:25:44 <pjones> t8m: we've always aimed for halloween.  literally always.
18:25:49 <dgilmore> only reason for 14th over 7th is to make sure gnome has time to get final in and tested assuming a sept release
18:25:51 <jreznik> sgallagh: task juggler
18:25:53 <sgallagh> ah
18:25:55 <jreznik> t8m: http://fedoraproject.org/wiki/Releases/19/Schedule
18:25:55 <t8m> pjones, OK :D
18:26:15 <jreznik> t8m: and where 19 you can put any XX
18:26:19 <sgallagh> Ok, so I think that's agreed.
18:26:20 <pjones> t8m: like, since 1994.
18:26:39 <pjones> (I mean, for every alternate release of course.)
18:26:43 <sgallagh> #action jreznik to work up and provide a schedule proposal for Oct 14 target date for next week.
18:26:44 <mattdm> Halloween/Mother's Day.
18:26:52 <sgallagh> Shall we move on for today?
18:26:57 <dgilmore> yep
18:26:58 <abadger1999> t8m:   Also: https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Steps_to_Construct_a_New_Schedule
18:27:06 <sgallagh> #topic #1221 	Product working group activity reports
18:27:07 <t8m> OK
18:27:14 <sgallagh> .fesco 1221
18:27:15 <zodbot> sgallagh: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
18:27:33 <sgallagh> The general consensus here seems to be: "Everyone was working on Tech Specs"
18:27:41 <jwb> yes
18:27:47 <mattdm> #info The general consensus here seems to be: "Everyone was working on Tech Specs"
18:28:06 <nirik> yep.
18:28:07 <mattdm> Except for cloud. We did things differently. :)
18:28:20 <sgallagh> mattdm: Isn't that kind of your charter?
18:28:24 <nirik> some good discussions, with some understandable digressions. ;)
18:28:25 <mattdm> sure :)
18:28:45 <sgallagh> Ok, anyone have anything specific to call out this week?
18:28:49 <abadger1999> mattdm: I liked the document that cloud produced.
18:28:54 <mattdm> abadger1999 thanks
18:28:56 <mitr> So did I
18:28:58 <sgallagh> Does FESCo want to make any kind of a ruling on the FS topic?
18:29:00 <abadger1999> Very hekpful for planning
18:29:04 <mattdm> can we link them here with infos?
18:29:10 <mattdm> so for the minutes?
18:29:12 <jwb> sgallagh, err... what?
18:29:16 <notting> sorry about that
18:29:23 <sgallagh> such as "Proposal: all Fedora Products will use ext4"?
18:29:26 <sgallagh> (Which I am -1 to)
18:29:37 <jwb> i'd be pretty irate if FESCo did anything like that
18:29:52 <drago01> sgallagh: why would fesco want to decide that?
18:29:52 <mattdm> #info https://fedoraproject.org/wiki/Workstation/Technical_Specification
18:29:55 <pjones> sgallagh: I'd be +1 to a proposal that we make no requirements /of that kind/
18:29:56 <notting> here now
18:29:58 <mattdm> #info https://fedoraproject.org/wiki/Cloud_Changelist
18:30:19 <mattdm> #info https://fedoraproject.org/wiki/Server/Technical_Specification
18:30:54 <abadger1999> sgallagh: I'd like to push questions like this to Base Design.  I'd think answers to the question could be: (Must be implemented as X.  By default implemented as X but Products can document they implement a different default.  Up to the product to decide.)
18:31:08 <sgallagh> abadger1999: Yeah, I'm good with that too
18:31:09 <t8m> What about all Fedora products will use ext4 or xfs or btrfs? (btrfs at this point in biggest doubt)
18:31:17 <dgilmore> mattdm: can i suggest you move cloud things under Cloud/ space like the others have
18:31:40 <mattdm> dgilmore wiki guidelines say everything should be top level. we've ended up with some with and some not.
18:31:53 <mattdm> dgilmore but sure, we can rearrange for consistency
18:31:54 <mitr> t8m: Let's not vote on things that nobody even suggested shouldn't be done :)
18:32:08 <jwb> t8m, what about we don't second guess the WGs in their discussions with everyone on what is best for their product and just let them decide?
18:32:08 <dgilmore> mattdm: i like consistency :) and things under namespaces is much more common
18:32:26 <nirik> jwb: +1
18:32:26 <t8m> no problem
18:32:26 <mattdm> dgilmore *nod*
18:32:43 <sgallagh> jwb: I framed the conversation poorly.
18:32:44 <nirik> I don't see any conflict here we need to decide/mediate...
18:32:55 <sgallagh> My intent was to ask whether FESCo has a problem with different FS defaults
18:33:01 <notting> i don't have an issue with it
18:33:01 <sgallagh> The answer appears to be "no", so let's move on
18:33:03 <mattdm> nirik, jwb +1
18:33:13 <mattdm> sgallagh +1
18:33:15 <mattdm> so many +1s
18:33:20 <jwb> wait, hang on
18:33:27 <jwb> i want to explain something
18:33:46 <pjones> t8m: one of many problems with a statement like that is that there's no scope in it.  Are we talking for F21, or until we say otherwise, or forever unless somebody thinks to ask again?
18:34:10 <t8m> pjones, no problem, it was not meant really seriously
18:34:21 <jwb> the reason i would be irate is that this FS discussion was almost a perfect example of how broader issues should be dealt with.  the WGs came up with what was best, it was discussed in broader context on the devel list, pulling in experts and other WG reps as needed
18:34:37 <jwb> it was long.  there was noise.  but it was done, overall, as it should have been
18:34:43 <t8m> jwb, +1
18:34:44 <sgallagh> jwb: Agreed
18:34:54 <pjones> jwb: yes.
18:34:56 <mitr> jwb: Yes.
18:35:01 <abadger1999> <nod>
18:35:04 <nirik> sure.
18:35:12 <jwb> so to even be discussing some kind of mandate from FESCo or Base is irritating at best
18:35:25 <jwb> i think my soapbox is broken now.
18:35:27 <pjones> yeah, that's why I said I'd be against making statements of that kind.
18:35:58 <sgallagh> Ok, now that we've all agreed that I shouldn't have asked about this topic in that way, can we move on?
18:36:20 <nirik> one question...
18:36:42 <nirik> what are next steps for working groups? continue to work on tech specs/flesh out and convert things into changes that are changes?
18:37:08 <jreznik> convert to changes is what I'd like to see
18:37:10 <jwb> nirik, i think that's a good summary
18:37:17 <t8m> nirik, +1
18:37:18 <sgallagh> nirik: Yeah, that was my understanding
18:37:28 <nirik> cool. Just want that to be clear... ;)
18:37:29 <sgallagh> Get all of our Changes in by the April 3(?) deadline
18:37:36 <dgilmore> I have a question for the workstation workgroup, how do they expect upgrades to work?
18:37:37 <jreznik> Apr 7th
18:37:48 <sgallagh> jreznik: Thanks
18:37:58 <mattdm> #info we're all pretty happy with the way the wg discussion about filesystems went, providing a good example of how broader issues should be dealt with in the fedora.nex structure
18:38:09 <dgilmore> they don't want an install DVD, the creation of that is what makes the upgrade tree for fedup
18:38:32 <mitr> nirik: Also, if anyone does have scheduling requirements, they should speak up _now_
18:38:45 <drago01> dgilmore: can't we create the tree without having to build and ship a dvd iso?
18:38:54 <dgilmore> drago01: no
18:39:00 <drago01> dgilmore: why?
18:39:12 <t8m> dgilmore, "they don't want an install DVD" - that means we won't produce it at all or that the install DVD won't be the Workstation product
18:39:13 <dgilmore> not without major unplanned work
18:39:42 <dgilmore> t8m: well, they state that their install method is livecd only
18:39:47 <mitr> dgilmore: build the ISO and drop it?
18:39:50 <dgilmore> which you cant use for a upgrade
18:39:56 <sgallagh> dgilmore: Would you mind putting together an explanation of how that process works on the Wiki? I'd like to see what the dependencies are.
18:40:07 <t8m> so we won't have install DVD at all?
18:40:08 <dgilmore> mitr: we can not build the dvd, but we have to build a install tree
18:40:23 <dgilmore> unless they reuse the tree from another product
18:40:37 <pjones> no, that sounds like the right thing.  build an install tree but not isos
18:40:41 <mattdm> So, I think this is the request to plan that work. I think it's perfectly fine to say "Hey workstation team: releng can't do this without some contribution of resources"
18:40:46 <t8m> I suppose server would want some kind of install DVD
18:40:57 <sgallagh> dgilmore: Can you think of a reason they couldn't use the Server tree for this?
18:40:59 <dgilmore> sgallagh: its simple. pungi imports lorax which makes the initramfs for both install and upgrade
18:41:00 <jreznik> t8m: for ws, lives only
18:41:04 <mitr> jwb, dgilmore: Could you bring this back to the Workstation WG?  Thanks for highlighting the concern, but I don't think we can solve this here.
18:41:09 <sgallagh> Presumably on upgrade they're pointing at the Everything+Updates repos
18:41:14 <notting> by 'install tree', it's just stage 2? the repo would be there regardless
18:41:19 <dgilmore> sgallagh: thats not installable
18:41:33 <sgallagh> dgilmore: I think you missed half of that
18:41:48 <sgallagh> I suggested using the Server tree and making sure it was pointed at the Everything+Update repos
18:41:55 <jwb> install and upgrade aren't synonymous...
18:41:56 <sgallagh> That should cover it, or am I mistaken?
18:42:08 <jwb> so i'm not sure why Everything+Update wouldn't work for upgrades
18:42:17 <drago01> I don't get it either
18:42:23 <dgilmore> jwb: it doesnt have the kernel and initramfs needed
18:42:33 <jwb> needed?
18:42:33 <sgallagh> I suspect there's some aspect of fedup that we're missing.
18:42:38 <pjones> you still need to build the bits fedup's going to reboot into
18:42:47 <pjones> but... you shouldn't need an iso for that
18:43:00 <dgilmore> you probably could use the servers kernel and initramfs
18:43:15 <notting> the upgrade bits in stage2 should be product independent, for now
18:43:19 <dgilmore> anyway we cant solve it here.
18:43:22 <mitr> sgallagh: Would we be essentially deciding-by-code that the packagesets (and comps) must not diverge between Products by this?
18:43:37 <jwb> dgilmore, would you be so kind as to ask on the desktop list with as much background tech info as possible?  be happy to follow up there
18:43:41 <sgallagh> I don't think comps matters here
18:43:49 <dgilmore> jwb: im not on the desktop list
18:43:53 <sgallagh> but I thought the plan was that the packagesets must not diverge
18:43:54 <pjones> mitr: I'm not sure that makes a big difference for an upgrade
18:44:07 <sgallagh> And that places that required divergence would be managed by product-specific subpackages
18:44:12 <mitr> dgilmore: then sign up?
18:44:30 <dgilmore> mitr: no thanks
18:44:34 <mitr> dgilmore: "nomail" option
18:44:49 <dgilmore> I already get more email than i can deal with
18:45:01 <nirik> dgilmore: if you do a writeup I'd be happy to pass it along to the desktop list and collect responses for you...
18:45:01 <pjones> that's why he suggested the "nomail" option.
18:45:16 <mattdm> dgilmore Can you delegate this to someone who will work with desktop on it?
18:45:24 <nirik> anyhow, this is something we need to figure, but not sure in this meeting will work.
18:45:33 <t8m> nirik, +1
18:45:33 <notting> shall we move on?
18:45:34 * EvilBob sees dgilmore running in circles with his fingers in his ears repeating "What I don't know can't hurt me"
18:45:54 <EvilBob> ;)
18:46:09 <abadger1999> sgallagh: Hmm... do product specific subpackages require Conflicts?  Probably should open an FPC ticket to list that in the Conflicts guidelines.
18:46:34 <sgallagh> abadger1999: Yeah, I'd been meaning to discuss that with you since DevConf and forgot.
18:46:45 <mattdm> abadger1999 I think they should.
18:46:47 <abadger1999> sgallagh: Cool -- talk with me after the meeting.
18:47:02 * nirik would like to see some examples where we actually need them first
18:47:03 <sgallagh> abadger1999: I have another meeting in 45 minutes.
18:47:11 <abadger1999> sgallagh: ah -- later today then?
18:47:15 <sgallagh> Mind sending me a meeting invite for tomorrow?
18:48:12 <abadger1999> sgallagh: can do -- but I don't know if we'd get to it (agenda has been pretty full lately.)  Maybe best to talk with me and do some initial drafting before it gets to a meeting.
18:48:14 <sgallagh> Anyway, shall we move on to the next topic?
18:48:19 <abadger1999> +1
18:48:27 <notting> ok
18:48:42 <nirik> +1
18:48:45 <pjones> yes
18:48:47 <notting> #topic #1230    Requesting FESCo address Cherokee logo issue
18:48:47 <notting> .fesco 1230
18:48:47 <notting> https://fedorahosted.org/fesco/ticket/1230
18:48:50 <zodbot> notting: #1230 (Requesting FESCo address Cherokee logo issue) – FESCo - https://fedorahosted.org/fesco/ticket/1230
18:49:03 <sgallagh> So it's past the deadline. I say we orphan it as we originally stated.
18:49:16 <sgallagh> s/orphan/retire/
18:49:29 <notting> have we confirmed he hasn't done it yet, or has he just not announced that he's done it?
18:49:35 <sgallagh> notting: No build has occurred
18:49:37 <sgallagh> I checked Koji
18:49:40 <pjones> Proposal: Go ahead and orphan it for the reasons we've said before.
18:49:44 <notting> yeah, looking at git, it's not done yet
18:49:54 <sgallagh> pjones: +1
18:49:56 * pjones +1
18:50:04 <sgallagh> pjones: Orphan or retire?
18:50:06 <nirik> s/orphan/retire/
18:50:22 <sgallagh> Proposal: Retire cherokee from the distribution
18:50:22 <pjones> Er, I do actually mean retire, don't I.
18:50:24 <sgallagh> (for clarity)
18:50:27 <pjones> sgallagh: +1
18:50:30 <t8m> Very unhappy +1
18:50:38 <pjones> sgallagh: you screwed me up when you said orphan the first time.
18:50:39 <dgilmore> +1
18:50:43 <notting> sgallagh: we said we would, we might as well follow through. +1
18:50:44 <sgallagh> pjones: I know
18:50:49 <masta> what if somebody decided to un-orphan the package? that would kinda suck
18:50:49 <abadger1999> Eh
18:50:52 <mitr> +1 to retiring I'm afraid.
18:50:54 <mattdm> yeah, what notting said.
18:50:56 <abadger1999> How about give it a week.
18:51:02 <nirik> +1, but sad since maintainer said they would. Do we want to give them a tiny bit more time?
18:51:04 <abadger1999> I'll try to put a placeholder image in this week.
18:51:14 <mitr> masta: Nothing prohibits that, but we would still want the logos gone.
18:51:17 <abadger1999> If I or the maintainer don't get to it orphan next week.
18:51:24 <nirik> abadger1999: +1
18:51:26 <mattdm> yeah, what nirik said. I'd like to at least wait for a chance to respond to the reminder.
18:51:48 <t8m> I can be +1 to abadger1999 as well
18:51:52 <mitr> abadger1999: If you are willing to do that, +1.
18:51:53 <mattdm> And assume that the maintainer is at this point acting in good faith.
18:51:56 <dgilmore> proposal: retire Monday if not fixed in the mean time
18:52:06 <mattdm> dgilmore +1
18:52:09 <sgallagh> dgilmore: +1
18:52:13 <notting> actually, that is probably better
18:52:15 <notting> dgilmore: +1
18:52:21 <abadger1999> dgilmore: wfm: +1
18:52:24 <mitr> dgilmore: +1 (fior clarity, assuming that abadger1999 fixing this counts)
18:52:40 <dgilmore> mitr: anyones fixing counts
18:53:38 * dgilmore will gladlly do the retirement on monday
18:53:39 <nirik> sure.
18:53:59 <t8m> dgilmore, +1
18:54:24 <sgallagh> Question: how do we handle released Fedoras here?
18:54:33 <drago01> does retire mean rawhide or released ones as well?
18:54:40 <drago01> what sgallagh said
18:54:40 <sgallagh> Assuming we retire it for being unacceptable, I mean.
18:54:42 <notting> #agreed FESCo decision reiterated. Package will be retired Monday if not fixed. (+:7,-:0,0:0)
18:55:04 <sgallagh> Presumably that means we shouldn't be continuing to ship it anywhere.
18:55:13 <sgallagh> Do we drop it from the stable repos?
18:55:19 <sgallagh> Fake out an Obsoletes: to remove it?
18:55:30 <drago01> I mean having a webserver suddenly retired mid release is ....
18:55:30 <mitr> sgallagh: I would strongly oppose making a "remove-cherokee" update, and we can't drop it from releases isos
18:55:32 <t8m> mitr, +1
18:55:45 * mattdm hopes the update just happens
18:55:48 <sgallagh> mitr: Sure, but I'm just noting that this is an exceptional case.
18:55:50 <t8m> let's not change past
18:56:14 <notting> yeah, i wouldn't do that yet. ideally, we get someone to fix it.
18:56:18 <sgallagh> And it wouldn't hurt to have a plan for this if we ever had to deal with a legal issue forcing a removal, but that's hypothetical.
18:56:30 <sgallagh> Ok, defer that question to next week
18:56:47 <mitr> sgallagh: RHL did edit the isos once, about 10 years in the past IIRC; let's not plan for that pain just yet
18:57:00 <notting> mitr: ugh, don't remind me
18:57:22 <notting> woohoo, new business.
18:57:23 <notting> #topic #1219    Contributor nationality
18:57:24 <notting> .fesco 1219
18:57:24 <notting> https://fedorahosted.org/fesco/ticket/1219
18:57:25 <zodbot> notting: #1219 (Contributor nationality) – FESCo - https://fedorahosted.org/fesco/ticket/1219
18:57:48 <notting> so, brought this up on the agenda just to clarify the note from legal:
18:58:04 <notting> #info Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th
18:58:05 <notting> en they are required to bring that information to the attention of Fedora Legal.
18:58:12 <notting> #undo
18:58:12 <zodbot> Removing item from minutes: INFO by notting at 18:58:04 : Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th
18:58:43 <drago01> so what happens if a country gets added to that list? hunt down contributor accounts and kick them out?
18:58:44 <notting> #info Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th
18:58:44 <notting> en they are required to bring that information to the attention of Fedora Legal.
18:58:45 <dgilmore> so dont ask dont tell
18:58:57 <t8m> notting, split it at sentences
18:59:30 <notting> #undo
18:59:30 <zodbot> Removing item from minutes: INFO by notting at 18:58:44 : Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence. If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries (currently: Cuba, Iran, North Korea, Sudan & Syria), th
18:59:31 <pjones> just take the list off
18:59:36 <notting> t8m: yeah
18:59:37 <pjones> #info current countries that are export restricted are: cuba, iran, north korea, sudan, and syria.
18:59:51 <notting> # Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence.
18:59:55 <notting> DAMMIT
19:00:00 <notting> #info Sponsors (or any other contributors) in Fedora should not make any effort to determine a contributor's nationality, country of origin, or area of residence.
19:00:25 <notting> #info If a potential contributor independently (and explicitly) reveals their nationality, country of origin, or area of residence, and that nationality, country of origin, or area of residence is in one of the export restricted countries, then they are required to bring that information to the attention of Fedora Legal
19:00:26 <abadger1999> dgilmore: Yeah, that seems to be the summary.
19:00:50 <notting> #info In the specific case that prompted this ticket, Fedora Legal has deemed the contributor is OK.
19:02:27 <notting> moving on
19:02:34 <notting> #topic #1240    taking ownership of packages fityk and sundials
19:02:34 <notting> .fesco 1240
19:02:34 <notting> https://fedorahosted.org/fesco/ticket/1240
19:02:35 <zodbot> notting: #1240 (taking ownership of packages fityk and sundials) – FESCo - https://fedorahosted.org/fesco/ticket/1240
19:02:52 * nirik meant to comment on this one.
19:03:20 <sgallagh> While I doubt malicious intent, I don't think we want to set a precedent on bypassing non-responsive process here.
19:03:22 <nirik> we could either just do it, or request a direct ack from the fomer maintainer in ticket or whatever
19:03:37 <mitr> sgallagh: +1
19:03:54 <notting> nirik: i'm ok with requesting a direct ack
19:03:59 <nirik> I'm happy to help people reassign packages, as long as we are sure the identity of the person wanting to do it.
19:04:03 <sgallagh> Yeah, a direct ack would be preferable
19:04:05 <dgilmore> nirik: well if his fas account is inactive he can't comment in the ticket right
19:04:15 <nirik> dgilmore: right, he would have to activate it.
19:04:24 <notting> #proposal Request a direct ack from nonresponsive maintainer via e-mail, and then proceed with reassigning
19:04:28 <dgilmore> its not hard to reactivate, orphan and go inactive again
19:04:36 <mattdm> notting +1
19:04:47 <dgilmore> notting: +1 im okay with that
19:04:54 <mitr> notting: +1
19:04:57 <nirik> dgilmore: yeah... I guess they might not want to bother figuring out the right places to do that.
19:04:58 <dgilmore> any other action he should just do it himself
19:04:58 <nirik> notting: +1
19:05:03 <t8m> notting, +1
19:05:06 <sgallagh> .fasinfo jpye
19:05:07 <zodbot> sgallagh: User: jpye, Name: John Pye, email: john@curioussymbols.com, Creation: 2007-07-01, IRC Nick: , Timezone: Africa/Abidjan, Locale: en, GPG key ID: C08DCD91, Status: active
19:05:10 <zodbot> sgallagh: Approved Groups: fedorabugs cla_fedora cla_done packager cla_fpca
19:05:13 * nirik can ask for the ack and do the reassigning.
19:05:21 <nirik> unless someone else wants to
19:05:29 <sgallagh> Account is still active
19:05:29 <pjones> notting: +1
19:05:51 <abadger1999> notting: +1
19:05:54 <sgallagh> notting: +1 (good enough)
19:06:01 <notting> #agreed nirk will request a direct ack from nonresponsive maintainer via e-mail, and then proceed with reassigning (+:9, -:0, 0:0)
19:06:35 <notting> next...
19:06:37 <notting> #topic #1241    Cloud WG list of changes
19:06:37 <notting> .fesco 1241
19:06:37 <notting> https://fedorahsted.org/fesco/ticket/1241
19:06:39 <zodbot> notting: #1241 (Cloud WG list of changes) – FESCo - https://fedorahosted.org/fesco/ticket/1241
19:07:14 <notting> have people had a chance to look over these yet? if not, we can table for a week
19:07:46 <t8m> I didn't have
19:07:50 * mattdm would like people to look over them :)
19:07:57 <mattdm> a lot of these are ambitious.
19:08:06 <sgallagh> I haven't had a chance yet
19:08:18 * pjones has not yet had a chance.
19:08:19 <dgilmore> mattdm: we can use fedmsg today to upload images
19:08:24 <mitr> I have looked over them... I think discussing them as separate topics (within the Change process) would work better than mixing everything under a single heading
19:08:34 <sgallagh> mitr: +1
19:08:45 <dgilmore> mattdm: we should work to getting nightlies uploaded automatically now
19:08:57 <mattdm> dgilmore awesome.
19:09:03 <notting> mattdm: are you working to have people file these as individual changes?
19:09:09 <mattdm> notting yes, exactly.
19:09:27 <mattdm> we're working on getting specific people attached to all of them first
19:10:22 <notting> ok, if that's the case, then do we just want people to discuss on list, and we will discuss in meeting when they're submitted?
19:10:34 <mattdm> that works for me.
19:10:34 <dgilmore> notting: +1
19:10:55 <mattdm> if people want to join the cloud sig list to discuss that's ideal, but i can also redirect people to devel or wherever as appropriate
19:11:11 <abadger1999> Do we want to get people discussing the external changes now?
19:11:31 <notting> yes, please
19:11:51 <notting> #info Please discuss changes here on list for now; will be discussed more in the FESCo meeting when they go through the change process.
19:12:11 <notting> #info People are specifically encouraged to read the 'External Changes' section and discuss those with the Cloud SIG
19:13:21 <notting> ok, next
19:13:24 <notting> #topic #1242    Update policy proposal: disable autokarma on AutoQA fail
19:13:24 <notting> .fesco 1242
19:13:25 <zodbot> notting: #1242 (Update policy proposal: disable autokarma on AutoQA fail) – FESCo - https://fedorahosted.org/fesco/ticket/1242
19:13:29 <notting> https://fedorahosted.org/fesco/ticket/1242
19:14:05 <dgilmore> im torn on this
19:14:09 <mitr> adamw: Do you have an idea what proportion of bodhi tickets would be affected?  (1%? 10%?)
19:14:19 <dgilmore> autoqa fails on fedora-release every update
19:14:23 <t8m> +1 although some AutoQA failures are bogus due to timing
19:14:50 * nirik is +1 I think it will help some, even if it will be a slight pain for some folks.
19:14:51 <sgallagh> t8m: As stated, this can be manually overridden
19:14:59 <dgilmore> people really need to bundle dependent updates as a single update
19:15:08 <sgallagh> I think it may encourage people to actually build things in the right order, too...
19:15:31 <sgallagh> dgilmore: No, we need to have explicit update dependencies available.
19:15:35 <sgallagh> But that's another topic entirely
19:15:43 <t8m> sgallagh, does building help? If you submit updates for all releases at one go the upgradepath test will work fine?
19:15:44 <notting> if it leads to people reorganizing things better to help with it, i'm OK.
19:15:49 <notting> dgilmore: why does fedora-release fail?
19:16:21 <sgallagh> t8m: Well, the most common one I've hit is "my update got processed before Rawhide did a createrepo". So possibly not.
19:16:27 <dgilmore> notting: autoqas depcheck pukes on the conflicts in generic-release
19:16:27 <adamw> mitr: urgh, sorry, was reading backscroll
19:16:36 <adamw> dgilmore: fedora-release isn't updated very often, though, is it?
19:16:47 <dgilmore> adamw: more than id like
19:16:57 <dgilmore> i wouldnt block this over it
19:17:05 <adamw> notting: depcheck considers explicit conflicts to be 'failures'. basically any package with an explicit conflict with another package is going to fail depcheck.
19:17:09 <mitr> notting: generic-release conflicts with fedora-release
19:17:32 <mattdm> I think it's important to recognize this as stopgap. It ain't perfect but something better is actively being worked on.
19:17:33 <tflink> FWIW, we're replacing the current depcheck soon with a rewrite that doesn't have so many issues with false positives
19:17:47 <mattdm> right what tflink said :)
19:17:54 <mattdm> so I am +1, if anyone is counting :)
19:17:57 <mitr> dgilmore: There's no proposal to block an update
19:18:01 <notting> i am +1 as well.
19:18:01 <abadger1999> Since it's just disabling karma automatism, I'm +1
19:18:11 <sgallagh> +1
19:18:20 <notting> right, we're not blocking, just trying to make sure we don't accidentally push out screwups
19:18:21 <abadger1999> Seems pretty low impact for false postitives.
19:18:23 <dgilmore> mitr: i never said there is. I always rely on karma promotion
19:18:28 <adamw> to give an approximate timeframe for that - taskotron may be in good enough shape to replace autoqa in, say, five weeks (on the optimistic side), say i dunno, eight weeks on the pessimistic side
19:18:30 <dgilmore> which wont happen
19:18:40 <nirik> dgilmore: you can re-enable.
19:18:41 <adamw> dgilmore: as i planned it you can easily just go back in and turn it back on
19:18:49 <sgallagh> I have to leave now. Sorry, folks.
19:18:55 <adamw> dgilmore: the idea is just for bodhi to flip the state if the test fails. but if you're sure it's a false failure, you can just flip it back.
19:19:09 <adamw> the test shouldn't run again unless you edit the update, so you shouldn't wind up in an edit war with a bot.
19:19:12 <t8m> do we have enough +1s?
19:19:18 <notting> t8m: i count 6
19:19:29 * pjones +1
19:19:31 <dgilmore> anyay on the whole I think its more good than harm
19:19:34 <dgilmore> +1
19:20:06 <mitr> +1 (hoping for a clear messaging from bodhi in affected tickets :) )
19:20:22 <notting> #agreed Proposal in ticket to disable autokarma if AutoQA fails accepted (+:9,-:0,0:0)
19:20:34 <notting> adamw: you ok with working this with autoqa and bodhi people?
19:20:54 <adamw> notting: if by 'working with' you mean 'email tflink and lmacken and ask them to do it', absolutely :)
19:21:03 <adamw> notting: i was kinda expecting fesco would check lmacken was OK with it before voting, but hey
19:21:38 <notting> adamw: ok. well, it's a request to change the behavior that way. reality can sadly intervene.
19:21:45 <adamw> yeah, sure.
19:21:57 <notting> #topic 1243     Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making
19:21:57 <notting> .fesco 1243
19:21:57 <notting> https://fedorahosted.org/fesco/ticket/1243
19:21:59 <zodbot> notting: #1243 (Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making) – FESCo - https://fedorahosted.org/fesco/ticket/1243
19:22:46 * nirik is torn on this... and would like to hear from kde sig some before we decide anything too.
19:23:10 <dgilmore> what do the KDE SIG think of no KDE image?
19:23:10 <mattdm> I'd like to defer until we hear back about some of the questions.
19:23:19 <notting> proposal: defer for a week
19:23:26 <mattdm> (From both the KDE SIG and the Workstation WG)
19:23:55 <dgilmore> notting: +1 i want to at least hear from the KDE SIG i suspect they will object to no KDE image
19:24:00 <notting> i'm OK with deferring - this ticket was opened and assorted threads started less than a day ago in any case
19:24:01 <mattdm> ideeeallly, those groups talk and come up with a happy solution
19:24:05 <mitr> notting: +1
19:24:06 <nirik> dgilmore: there's goign to be one tho, since we are doign spins just as we have?
19:24:17 <pjones> they seem to be against this in the ticket...
19:24:22 <t8m> notting, +1 to defer
19:24:27 * pjones +1 to defer as well
19:24:34 <adamw> i'm fine with deferral, i wasn't necessarily expecting a decision this week or anything.
19:25:07 <abadger1999> +1 defer
19:25:29 <abadger1999> Are there any other questions/aspects of this we want to make sure the kde sig discusses at their meeting?
19:25:45 <notting> #agreed defer this one week waiting for more feedback from both KDE SIG and Workstation WG (+:7,-:0,0:0)
19:27:30 <notting> abadger1999: i don't have specific questions/aspects in mind - i guess it's just whether they come to an agreement on a particular single delivery of KDE, or whether they want multiple deliveries
19:27:40 <abadger1999> <nod>
19:28:20 <notting> #topic Next week's chair
19:28:24 <notting> volunteers?
19:28:30 <mattdm> I have not done it in a long time
19:28:35 <mattdm> so I guess I'll stick my hand up :)
19:29:15 <notting> #info mattdm to chair next week's meeting
19:29:21 <notting> #topic Open Floor
19:29:26 * dgilmore is on PTO next monday-wednesday
19:29:36 <dgilmore> so ill miss next weeks meeting
19:29:51 <mattdm> enjoy your pto!
19:30:55 <abadger1999> Just to mention -- I won't be around for much of April (conference + vacation)
19:31:51 <notting> abadger1999: thx for the early warning
19:34:04 <notting> if there's nothing else, will close meeting in 2 minutes
19:36:07 <notting> #endmeeting