18:00:15 <paragan> #startmeeting FESCO (2015-12-02)
18:00:15 <zodbot> Meeting started Wed Dec  2 18:00:15 2015 UTC.  The chair is paragan. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:15 <zodbot> The meeting name has been set to 'fesco_(2015-12-02)'
18:00:15 <paragan> #meetingname fesco
18:00:15 <zodbot> The meeting name has been set to 'fesco'
18:00:15 <paragan> #chair ajax dgilmore number80 jwb nirik paragan rishi thozza sgallagh
18:00:15 <paragan> #topic init process
18:00:15 <zodbot> Current chairs: ajax dgilmore jwb nirik number80 paragan rishi sgallagh thozza
18:00:25 <ajax> howdy y'all
18:00:36 <nirik> morning
18:00:43 <rishi> .hello rishi
18:00:44 <zodbot> rishi: rishi 'Debarshi Ray' <debarshir@redhat.com>
18:01:02 <paragan> Hi all
18:01:03 <rishi> I am at a hackfest and I might have to leave early.
18:01:26 <paragan> rishi, no problem
18:02:44 <paragan> number80, will be travelling and is not available today but he has already voted in tickets
18:02:55 <paragan> thanks to number80
18:03:09 <dgilmore> I am in another meeting right now. it should be over in 15 minutes
18:03:25 <dgilmore> I have a standing meeting at noon every day
18:04:09 <jkurik_mtg> Hi I am semi-available as I am on another meeting ... please ping me if you need something from my side
18:04:18 <paragan> sgallagh, jwboyer available here?
18:06:02 <paragan> I think we are 5 including dgilmore. Should we start with the meeting agenda?
18:07:22 <ajax> yes, that's quota
18:07:29 <paragan> cool
18:07:31 <ajax> er, quorum, whatever
18:07:50 <thozza> hi all
18:07:55 <thozza> sorry I'm late
18:08:00 <paragan> let's start with easy tickets and then last 1505 ticket
18:08:04 <paragan> thozza, hi
18:08:13 <paragan> #topic #1504 F24 System Wide Change: Fedora 24 Boost 1.60 uplift
18:08:13 <paragan> .fesco 1504
18:08:13 <paragan> https://fedorahosted.org/fesco/ticket/1504
18:08:15 <zodbot> paragan: #1504 (F24 System Wide Change: Fedora 24 Boost 1.60 uplift) – FESCo - https://fedorahosted.org/fesco/ticket/1504
18:08:37 <dgilmore> uplift in the name to me is weird
18:08:43 <dgilmore> but otherwise +1
18:08:57 <ajax> +1
18:09:08 <nirik> it's always been called that... I think the orig submittor years ago thought that was clever or something. ;)
18:09:14 <nirik> +1 in any event
18:09:27 <paragan> +1 from me also
18:09:29 <thozza> +1
18:09:35 <rishi> +1
18:10:12 <jwb> hi apologies.  i'm late and freenode is being difficult today
18:10:45 <paragan> jwb np, discussing first ticket, Boost Change, your vote please?
18:11:24 <jwb> +1
18:11:32 <paragan> #agreed Approved F24 System Wide Change: Fedora 24 Boost 1.60 uplift (8, 0, 0)
18:11:59 <jwb> we +1 this like every release.  i wish for a preemptive approval every time
18:12:58 <paragan> #topic #1509 yarock package maintainer not respoding
18:12:58 <paragan> .fesco 1509
18:12:59 <paragan> https://fedorahosted.org/fesco/ticket/1509
18:13:00 <zodbot> paragan: #1509 (yarock package maintainer not respoding) – FESCo - https://fedorahosted.org/fesco/ticket/1509
18:13:30 <nirik> so, it seems we are getting more and more of these where people just bypass any process and file a fesco ticket.
18:13:51 <jwb> yeah.  this looks more like "i want this updated and i want it updated now"
18:14:13 <paragan> here yarock maintainer has replied on the fesco list that he is okay with finding new maintainer
18:14:25 <thozza> and the person does not use fedora-devel
18:14:37 <nirik> I don't think the submittor is a package maintainer. ;)
18:14:46 <paragan> yes that is also one case
18:14:49 <thozza> it does not seem so :)
18:15:04 <paragan> so we need to ask on devel list for new maintainer
18:15:26 <nirik> yeah.
18:15:42 <paragan> Proposal: Based on jam3s email reply on fesco list, let's open yarock package for new maintainer
18:15:43 <nirik> I can do that, and/or just update it. (I haven't looked at how much hassle the package is)
18:16:12 <nirik> paragan: +1
18:16:16 <paragan> I just tried to update to latest upstream and seems it needs htmlcxx to be packaged in Fedora
18:16:28 <paragan> *just tried local build
18:17:09 <nirik> ok
18:17:09 <thozza> paragan: +1
18:17:30 <jwb> +1
18:18:21 <ajax> +1
18:19:24 <paragan> #agreed  Based on jam3s email reply on fesco list, let's open yarock package for new maintainer (5, 0, 0)
18:19:56 <sgallagh> /me is here late
18:20:01 <paragan> nirik, do we need to orphan this package and send email on devel list?
18:20:45 <nirik> yep. I can do that.
18:20:52 <paragan> nirik, thanks
18:21:10 <paragan> #topic #1510 F24 System Wide Change: Livemedia Creator
18:21:11 <paragan> .fesco 1510
18:21:11 <paragan> https://fedorahosted.org/fesco/ticket/1510
18:21:12 <zodbot> paragan: #1510 (F24 System Wide Change: Livemedia Creator) – FESCo - https://fedorahosted.org/fesco/ticket/1510
18:21:28 <jwb> +1
18:21:34 <paragan> +1
18:21:36 <nirik> +1
18:21:46 <sgallagh> +1, anything that makes rel-eng's life easier
18:22:12 <thozza> +1
18:22:21 <ajax> +1
18:23:04 <paragan> #agreed Approved F24 System Wide Change: Livemedia Creator (7, 0, 0)
18:23:18 <paragan> #topic #1505 Being able to prefer packages on distribution level
18:23:18 <paragan> .fesco 1505
18:23:18 <paragan> https://fedorahosted.org/fesco/ticket/1505
18:23:19 <zodbot> paragan: #1505 (Being able to prefer packages on distribution level) – FESCo - https://fedorahosted.org/fesco/ticket/1505
18:24:14 <sgallagh> OK, I have a couple issues with the implementation as described.
18:24:27 * nirik was hoping to also get some feedback on it from dgilmore
18:24:37 <sgallagh> Haikel touched on them in the ticket as well.
18:25:12 <sgallagh> Namely: I think that all preferred dependencies should be decided on by either FESCo or a specific WG
18:25:25 <dgilmore> sorry was distracted with teh other meeting
18:25:27 <dgilmore> it is done now
18:25:31 <sgallagh> And that means that these preferences probably belong in fedora-release[-*] rather than fedora-repos.
18:25:42 <sgallagh> Even though that seems a less natural fit
18:26:09 <thozza> since presets are there, it seems like a better place
18:26:26 <thozza> as these are also defaults
18:26:27 <ajax> i do like the trick of using Suggests for it, but yeah, does seem like it'd be nice to have per-product
18:26:35 <nirik> are we planning on having per product differences ?
18:26:41 <sgallagh> Full disclosure: I recommended to them about fedora-repos, but changed my mind since. Sorry about that
18:27:13 <jwb> nirik: i think we should plan to allow for it
18:27:24 <dgilmore> probalem is there is no one right answer
18:27:24 <thozza> nirik: I think the WGs should be able to do so if they need/want
18:27:26 <sgallagh> jwb: I was just typing exactly that
18:27:30 <nirik> ok, then I guess fedora-release* makes more sense...
18:27:42 <paragan> right
18:28:07 <dgilmore> the prefered option may depend on the software you have installed or are running.
18:28:55 <dgilmore> if we have packages providing pdf-reader the option you want to pick likely depend on teh running environment
18:29:27 <sgallagh> dgilmore: Well, there are stronger mechanisms for determining that
18:29:32 <sgallagh> Such as Recommends: and Requires:
18:29:42 <sgallagh> This is basically intended to only have an effect in the case of a tie
18:29:44 <dgilmore> sgallagh: sure. just an example
18:30:00 <ajax> i guess the question is which tag dnf will honor normally
18:30:10 <sgallagh> ajax: What do you mean?
18:30:41 <ajax> sgallagh: fedora-release-workstation might have a preference for a particular provider of a feature _if_ something requiring that feature gets installed, but not want to drag it in pre-emptively
18:31:14 <ajax> say, if there's better testing for postfix than sendmail, but you normally need neither
18:31:18 <sgallagh> ajax: I think that's better handled with the advanced deps that are just arriving in upstream RPM
18:31:25 <dgilmore> different products may well want different preferences
18:31:39 <ajax> sgallagh: yes, i'm saying, i think dnf honors Suggests now, and therefore...
18:31:46 <sgallagh> ajax: So Suggests: does not get brought in by DNF unless you pass a specific argument
18:32:08 <sgallagh> Recommends is brought in by default unless you disable it with another, different argument
18:32:28 <ajax> sgallagh: oh good, that's the distinction i was looking for
18:32:58 <sgallagh> (And of course Requires: is strict)
18:33:11 <ajax> in that case Suggests in the release subpackage seems like it's probably the right move
18:33:52 <dgilmore> sgallagh: I can see cases where at a distro level we want to set some preference, but products may have some other subset of preferences
18:34:25 <dgilmore> doing it all in fedora-release would allow us to manage it all in one place
18:34:26 <ajax> i don't? in a sense we're moving away from "the distro" being a thing
18:34:30 <sgallagh> dgilmore: That's possible, but I'm willing to address that when we get to it.
18:34:45 <sgallagh> dgilmore: All of the fedora-release packages are subpackages of fedora-release, so it's still handled in the same repo
18:34:52 <dgilmore> sgallagh: right
18:35:38 <sgallagh> ajax: I think he means there are cases where Fedora "in general" might prefer e.g. postfix but someone building an appliance might specifically select sendmail
18:35:58 <sgallagh> But I think those are more likely to be resolved by just setting a real Requires or membership in an env group, honestly
18:36:05 <nirik> right
18:36:07 <sgallagh> In reality, a conflict here will likely be rare
18:36:20 <sgallagh> So I'm willing to defer solving that problem until it actually comes up
18:36:28 <ajax> (conflict rare in fedora? that'd be nice.)
18:36:32 <ajax> yeah i agree
18:36:46 <paragan> sgallagh, would you like to provide proposal here?
18:36:48 <sgallagh> ajax: There are plenty of specific *kinds* of conflict that are rare ;-)
18:36:54 <sgallagh> paragan: Will do, one moment
18:37:34 <dgilmore> sgallagh: right
18:37:50 <dgilmore> sgallagh: spins would explicitly pull in areas they want to diverge
18:38:29 <sgallagh> Proposal: The use of Suggests: as a mechanism to resolve ambiguous dependencies is approved. FESCo wants these Suggests: to live in the fedora-release and fedora-release-$EDITION subpackages rather than fedora-repos so that they can be made edition-specific if needed and so any such differences are maintained in the same repository. All such preferences must be approved by FESCo or the relevant Edition WG.
18:38:36 <sgallagh> (Did all of that come through IRC?)
18:38:46 <jwb> i think so
18:38:48 <paragan> yes :)
18:38:55 <ajax> end with "Edition WG."
18:39:03 <jwb> +1
18:39:06 <ajax> +1
18:39:08 <nirik> +1
18:39:12 <sgallagh> +1
18:39:13 <paragan> +1
18:39:13 <dgilmore> +1
18:39:31 <thozza> sgallagh:  you saw the point 3, right?
18:39:53 <thozza> in the ticket
18:40:25 <sgallagh> thozza: I'd missed that, but I don't think this is a complex process. Ask and ye shall receive.
18:40:37 <sgallagh> This is firmly in FESCo's area of responsibility.
18:40:40 <thozza> hopefully :)
18:40:50 <thozza> ok, +1
18:41:41 <nirik> so the two example ones, do we want to talk about those? or farm them to server WG? or /
18:41:42 <paragan> #agreed  The use of Suggests: as a mechanism to resolve ambiguous dependencies is approved. (7, 0, 0)
18:41:57 <paragan> I will add full text of proposal in the ticket
18:42:01 <sgallagh> Selecting a distro- or edition-wide default is probably going to be a religious debate in general...
18:42:03 <dgilmore> thozza: there is no sperate product release packages
18:42:16 <dgilmore> thozza: they are sub-packages of fedora-release
18:43:02 <sgallagh> nirik: Let's take them individually.
18:43:18 <sgallagh> dgilmore: He was talking about "Note: we have got feedback from stack holders, that any complicated process that would go through FESCo, would discourage packagers from using this mechanism."
18:44:12 <sgallagh> I'm not about to let arbitrary packagers decide what constitutes a Fedora or Fedora Edition default. That pretty much defeats the purpose of having a FESCo and WGs.
18:44:13 <dgilmore> sgallagh: gahh I was looking at comment 3
18:45:12 <paragan> #topic Next week's chair
18:45:48 <thozza> someone who will be still in FESCo by that time :D
18:45:50 * dgilmore can not chair a meeting until DST starts as I have a conflict at the start of the meeting every week
18:46:08 <jwb> i have possible jury duty next week, so i cannot commit to it
18:46:16 <dgilmore> unless we started later
18:46:17 <sgallagh> I'll take it
18:46:22 * nirik could do it, but I'm also on the election block. ;)
18:46:36 <paragan> sgallagh, thanks
18:46:49 <sgallagh> /me loves how often this #topic turns into a game of "Not-it"
18:46:54 <paragan> #info sgallagh to chair next week
18:47:09 <paragan> #topic Open Floor
18:47:14 <dgilmore> sgallagh: if we followed day light saving I could do it
18:47:35 <jwb> i have one thing for open floor
18:47:40 <sgallagh> OK, open floor topic: should we move to an hour later?
18:47:42 <nirik> dgilmore: likely when new fesco is seated we will pick a new time anyhow
18:47:51 <sgallagh> That's also a good point. Withdrawn.
18:48:04 <jwb> https://fedorahosted.org/fesco/ticket/1469
18:48:07 <dgilmore> nirik: that is fair
18:48:13 <jwb> so f24 is off and running now.
18:48:18 <thozza> if it will be like last couple of time, you won't find any time :)
18:48:21 <jwb> and i686 images are no longer blocking
18:48:29 <nirik> thozza: sadly, probibly true.
18:48:41 <jwb> nirik asks if we should announce that again (i think so) and if people should stop creating those images (i think so but others might not agree)
18:48:46 <dgilmore> jwb: they are blocking in the sense that if they fail to compose the compose fails
18:48:56 <jwb> dgilmore: then we should stop making them
18:49:03 <jwb> because we decided i686 images do not block the release
18:49:05 <nirik> and testing them
18:49:13 <dgilmore> the compose tooling has no way to differenciate other than to not make them
18:49:22 <jwb> great.  so let's stop making them
18:49:31 <nirik> +1\
18:49:32 <sgallagh> Proposal: Stop generating i686 media
18:49:42 <sgallagh> +1
18:49:47 <jwb> +1
18:49:51 * dgilmore will implement if thats teh desirte
18:50:02 <dgilmore> jwb: does that mean no 32 bit repo at all
18:50:12 <dgilmore> because that is what will happen
18:50:18 <jwb> what?
18:50:32 <dgilmore> jwb: the switch is all or nothing
18:50:51 <jwb> that makes no sense.  we compose updates.  they don't have media/images attached to their repos
18:50:52 <paragan> +1
18:51:08 <thozza> +1
18:51:10 <jwb> if you have to make code changes, then make code changes that make sense
18:51:21 <dgilmore> jwb: not sure that the compsoe tooling can make the x86 Everything repo but nothing else
18:51:24 <nirik> boot.iso is made as part of that. I'd be ok with still making that if needed to make the repo
18:51:33 <dgilmore> gahh I cna not type
18:51:52 <jwb> nirik: if i686 boot.iso fails to create, the whole thing fails according to what dgilmore said
18:52:04 <dgilmore> it does
18:52:18 <jwb> so ... perhaps we need code changes to not create any .iso/.vbox/.img/.whatever
18:52:35 <nirik> well, what do you mean by fails there?
18:52:49 <dgilmore> I am in the middle of major compose tooling changes
18:52:58 <dgilmore> we will have to see what is possible at teh end
18:53:11 <dgilmore> I am not going to make any promises about any of it right now
18:53:41 <dgilmore> nirik: new pungi fails the compose if any of the tasks in it fails
18:53:51 <nirik> ok, but thats not actually what we use yet right?
18:53:54 <dgilmore> which includes failing to make boot media for any arch
18:54:04 <dgilmore> nirik: its what we will be using for f24
18:54:12 <jwb> fesco decided this 3 months ago.  is there a reason this decision wasn't taken into account?
18:54:22 <dgilmore> I plan to have rawhide changed before christmas
18:54:35 <dgilmore> jwb: it was not on the radar
18:54:51 <nirik> ok. with the current stuff I think we can drop i686 pungify and live/appliance/cloud images...
18:54:54 <sgallagh> jwb: Strictly speaking, we decided that we were not going to treat any issue discovered only in i686 as blocking for the release. We didn't specifically talk about the compose process.
18:55:00 <nirik> I would hope the new one would be workable to do that too
18:55:39 <dgilmore> jwb: I am filing an issue in pagure now
18:55:39 <jwb> sgallagh: fine, yet if we cannot even discover issues because the compose fails, i don't see how that somehow magically makes i686 blocking
18:55:44 <jwb> dgilmore: great
18:55:45 <dgilmore> so we see what can be done
18:55:58 <nirik> "Fedora will ship no i686/32-bit x86 install media in Fedora 24 as a primary/blocking deliverable"
18:56:18 <nirik> but yeah, it's not clear fully
18:56:27 <nirik> IMHO we shouldnt make them if we aren't blocking on them.
18:56:28 <sgallagh> jwb: Well, the side-effect of i686 media not building is that no media builds
18:56:36 <sgallagh> So it's kind of fuzzy.
18:57:06 <nirik> we should make the tree so we can still do stupid multlib.
18:57:29 <jwb> sgallagh: i'm not sure what your goal here is.  if you want to debate things for arbitrary reasons, fine.  if you want to make i686 blocking again, say so.  i'd rather not debate technicalities and instead focus on what needs to happen to make the decision we made actually possible.
18:57:42 <sgallagh> I'm not debating at all.
18:57:54 <dgilmore> jwb: https://pagure.io/pungi/issue/80
18:57:59 <jwb> dgilmore: thank you
18:58:09 <sgallagh> I got the impression that we as a whole didn't agree on what "blocking" meant in this context. I was trying to clarify.
18:58:30 <nirik> dgilmore: should we have another one for 'no images on a specified arch' ?
18:58:46 <sgallagh> I meant that i686 compose failures were *effectively* blocking the release because of the current technical implementation
18:58:48 <dgilmore> nirik: maybe
18:58:56 <sgallagh> And that the original ruling was for what constituted a blocker *bug*
18:59:36 <nirik> because if we aren't blocking on them, or testing them or anything I think we do people a big disservice creating them in the first place.
19:00:33 <jwb> sgallagh: this sounds very much like debating technicalities.  we have no definition of blocker other than bugs but it doesn't matter if there is a magical bug filed or not if the entire compose fails if one arch does.
19:00:49 <jwb> therefore, image creation itself is blocking the release when it shouldn't
19:01:54 <jwb> nirik: correct
19:02:41 <nirik> https://pagure.io/pungi/issue/81
19:02:49 <sgallagh> jwb: I don't think we were actually disagreeing on those points.
19:03:46 <nirik> anyhow, I don't know that there's more for us to do here, unless there's something more to clarify
19:05:32 <paragan> If there is nothing to discuss more, I will close the meeting in a minute
19:06:31 <paragan> #endmeeting