16:00:31 <maxamillion> #startmeeting FESCO (2017-05-19)
16:00:31 <zodbot> Meeting started Fri May 19 16:00:31 2017 UTC.  The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:31 <zodbot> The meeting name has been set to 'fesco_(2017-05-19)'
16:00:32 <maxamillion> #meetingname fesco
16:00:32 <zodbot> The meeting name has been set to 'fesco'
16:00:32 <maxamillion> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:00:32 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:00:34 <maxamillion> #topic init process
16:00:39 <maxamillion> .hello maxamillion
16:00:39 <sgallagh> .hello sgallagh
16:00:40 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:00:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:45 <nirik> morning
16:00:50 <jforbes> .hello jforbes
16:00:51 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:01:47 <mprahl> .hello mprahl
16:01:49 <zodbot> mprahl: mprahl 'Matt Prahl' <mprahl@redhat.com>
16:02:53 <jkaluza> mprahl: don't you know if ralph or langdon join this meeting?
16:02:58 * threebean waves
16:03:00 <jkaluza> ok
16:03:04 <jkaluza> me can leave then :)
16:03:12 <jkaluza> threebean: sent you PM some minutes ago
16:03:22 <langdon> I just joined.. More stable in 10 though
16:03:27 <langdon> So
16:03:47 <langdon> Other topics first would be appreciated
16:04:14 <maxamillion> topics other than .... ?
16:04:17 <jkaluza> langdon: received the PMs I sent you?
16:04:30 <sgallagh> maxamillion: Status of Boltron, I assume
16:04:50 <maxamillion> sgallagh: that's not on the meeting agenda
16:04:55 <jkaluza> or we can start with that, I can wait here for 10-15 minutes
16:05:01 <sgallagh> maxamillion: It's part of the "incomplete Changes" topic
16:05:02 <jkaluza> maxamillion: it is part of non-complete changes
16:05:05 <maxamillion> ah ok
16:05:20 <maxamillion> I thought they were talking about the boltron specific ticket from last week
16:05:59 <maxamillion> still need one more for quorum ...
16:06:15 <dgilmore> hi all
16:06:22 <maxamillion> and there it is
16:06:35 <maxamillion> let's get rolling ...
16:06:35 <dgilmore> sorry I am late
16:06:35 <maxamillion> #topic #1707 Firefox on non-x86 architectures
16:06:36 <maxamillion> .fesco 1707
16:06:36 <maxamillion> https://pagure.io/fesco/issue/1707
16:06:38 <zodbot> maxamillion: Issue #1707: Firefox on non-x86 architectures - fesco - Pagure - https://pagure.io/fesco/issue/1707
16:06:55 * nirik is not sure he actually follows this one.
16:06:59 * jkaluza leaves then, threebean and langdon should know about the boltron stuff :)
16:07:17 <langdon> Sorry.. Ones that need me :)
16:08:21 <nirik> sgallagh: can you summarize what you want us to decide here?
16:09:13 <sgallagh> nirik: So the context is that for a time, we had a blocking install medium that couldn't compose because the FF maintainer ceased building for that architecture.
16:09:22 <nirik> right.
16:09:50 <sgallagh> That specific issue was fixed by re-enabling only the build for that arch (armv7hl), but not re-enabling any of the other arches.
16:10:19 <nirik> right
16:10:26 <sgallagh> Thus the situation is that all media that would ship Firefox either cannot compose for those arches or else has to drop Firefox from their composes.
16:11:11 * langdon was in wall of meetings all morning so was not really caught up.. ok. paying real attention now
16:11:20 <nirik> well, it's not out of spite. My understanding is some big change landed upstream and it's not working yet on those arches.
16:11:31 <langdon> .hello langdon
16:11:32 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
16:11:59 <maxamillion> yeah, the big upstream change breaking things makes it difficult
16:12:13 <sgallagh> nirik: I am aware that it's not out of spite, but there's an argument to be made that we shouldn't be taking changes that disable major software.
16:13:11 <dgilmore> rock meet hard place
16:13:30 <sgallagh> Well, one middle-ground I suggested was carrying the ESR version
16:14:00 <maxamillion> sgallagh: would it be a separate package? firefox-esr or $similar?
16:14:03 <dgilmore> in this case without a functional esr build there is no fallback path, and we have locked ourselves into rapidly following upstream
16:14:11 <dgilmore> something we have no control over
16:14:25 * nirik nods.
16:14:29 <dgilmore> our and upstreams requirements, desires and support paths do not match
16:14:30 <sgallagh> Well, there's a functional ESR build for RHEL 7 that we could probably adapt.
16:15:00 <dgilmore> sgallagh: ESR is something that only makes sense in this case
16:15:02 <nirik> I think a case could be made to switch to ESR for default... but it would be up to spins/workstation what they want to do
16:15:03 <maxamillion> dgilmore: we ship icecat in Fedora and that's ESR based
16:15:16 <sgallagh> I guess what I'd like to suggest is that we package and ship the ESR version and use that as the default browser and also permit the rapid-update version in the repo for those arches that it supports.
16:15:25 <dgilmore> say some other upstream makes some other change, say libreoffice
16:15:37 <dgilmore> I do not think we have a built in backup there
16:15:51 <nirik> yeah, this is a firefox only solution to this issue...
16:16:07 <sgallagh> Right, but I'm not prepared to offer up a general solution at this meeting.
16:16:28 <nirik> just to note it in the minutes: "ppc64 (and s390x) fails due lack of big endian support in the skia gpu library, skia has been made mandatory in FF 53"
16:16:49 <dgilmore> sgallagh: a soultion here may just be we change the package set to require browser
16:17:05 <dgilmore> and make some changes so firefox is the prefered browser
16:17:21 <sgallagh> dgilmore: But then we're back to not offering the same experience across the portfolio
16:17:22 <dgilmore> but midori or some other browser can fill in
16:17:36 <dgilmore> sgallagh: we do not offer that even with esr
16:17:48 <jwb> i don't think ESR solves anything
16:17:50 <sgallagh> Which is something I'd like to avoid (if only because it sends the message that non-x86 architectures are unimportant)
16:17:50 <maxamillion> I'm not against that but I do want to point out mattdm's comment in the ticket about how that's a difficult thing to deal with from a project standpoint because then we lack uniformity in our user facing offerings
16:17:59 <dgilmore> the different versions of firefox have different functionality
16:18:26 <sgallagh> dgilmore: Which is why I suggested making the ESR the universal default and offering the faster update version as an option
16:18:31 <nirik> somewhat, but for many people they wouldn't care too much I don't think... between ESR and non ESR firefox
16:18:34 <sgallagh> Not the default on any media, if that was unclear
16:18:42 <jwb> one sec
16:19:07 <jwb> ESR is a workaround.  eventually the ESR version will be updated to something newer and if we haven't fixed the actual upstream issues, then even ESR will fail
16:19:21 <jwb> i don't want us thinking ESR is a solution long term, because it isn't
16:19:22 <dgilmore> jwb: indeed
16:19:36 <nirik> right
16:19:53 <dgilmore> all the release criteria for desktops says is a working browser
16:19:57 <nirik> it would just 'smooth out' the issues.
16:19:59 <dgilmore> it does not say what on e
16:20:01 <maxamillion> jwb: it does give a longer runway for solving the actual problem upstream though
16:20:03 <sgallagh> jwb: True, but ESR gives us 1) more time and 2) more likelihood that someone like Red Hat will be helping make sure it works on the arches they ship
16:20:11 <maxamillion> sgallagh: +1
16:20:17 <jwb> maxamillion: sgallagh: yes, agreed completely
16:20:55 <jwb> just making sure we're clear on what ESR buys us
16:21:02 <jwb> there's one other problem with ESR
16:21:05 <maxamillion> jwb: however, you're also not wrong
16:21:18 <sgallagh> Yeah, it's not a solution. I agree. But it's a workable band-aid in this case IMHO
16:21:32 <jwb> who packages and maintains it?  because i believe Martin said in the ticket that the firefox maintainers weren't interested in doing that
16:21:48 <jwb> and if we're now talking about making esr the default across all arches, that's a large problem
16:22:00 <sgallagh> jwb: A very valid point.
16:22:05 <maxamillion> oh actually, wouldn't ESR effectively be a downgrade? wouldn't this break people doing a fedup to the new release that defaults to ESR? (I've never had a firefox downgrade go well)
16:22:06 <nirik> well, FESCo just takes it's budget and hires... oh wait.
16:22:18 <maxamillion> nirik: ;)
16:22:21 <nirik> maxamillion: if it's a seperate package that wouldn't matter
16:22:27 <sgallagh> maxamillion: If it's a new package name, that wouldn't happen
16:22:32 <maxamillion> how wouldn't it?
16:22:34 <nirik> it would just install firefox-esr and make it default
16:22:41 <nirik> you would still have firefox installed
16:22:47 <sgallagh> They'd just end up stuck on the old one until if and when we started building on that arch again
16:22:59 <maxamillion> I'm talking about firefox hitting different metadata formats in ~/.mozilla
16:23:30 <sgallagh> maxamillion: OK, that's an interesting point :-/
16:23:41 <nirik> make it use ~/.mozilla/firefox-esr/
16:23:45 <sgallagh> We could make sure that didn't happen on upgrades easily enough
16:23:50 <maxamillion> nirik: ah, true
16:23:54 <nirik> icecat does it's own dir
16:23:56 <sgallagh> nirik: But then they lose their profile on upgrade, which isn't great either
16:23:59 <maxamillion> nirik: but then on an upgrade, people lose their profiles and such
16:24:12 <nirik> right. or perhaps don't switch default on upgrade only new installs.
16:24:13 <maxamillion> hrmmm ... :/
16:24:20 <sgallagh> But like I said, we can avoid switching defaults, exactly
16:24:32 <sgallagh> And document the manual steps to migrate
16:24:37 <maxamillion> fair
16:24:38 <nirik> in any case, without a packaged ESR, I don't know that we can decide to switch to it. ;)
16:24:41 <dgilmore> or we could just install the best available browser
16:25:19 <sgallagh> dgilmore: That doesn't address this specific problem. (But it's a valid point for the wider discussion)
16:25:45 <maxamillion> nirik: I mean, if we were to just crib the RHEL Firefox ESR SRPM with some edits to handle default profile dir and handle upgrade scenarios, then I'd like to think the maintenance work would be minimal
16:26:24 <nirik> I'm not sure that would be the case... if they have any patches they may not build on all arches we have, etc.
16:26:30 <nirik> but I don't know.
16:26:37 <dgilmore> sgallagh: yes it does
16:26:37 <sgallagh> Yeah, there's a lot of unknowns there, unfortunately
16:26:51 <nirik> could we even call it firefox-esr?
16:26:52 <dgilmore> sgallagh: we only require a working browser
16:26:53 <jforbes> They don't build on everything, so we have no clue
16:27:00 <dgilmore> no where does it say it has to be firefox
16:27:12 <sgallagh> maxamillion: It's also possible that the ESR release might require a dep that has seen a soname bump since then in Fedora, etc.
16:27:33 <maxamillion> sgallagh: I think what dgilmore is saying is that we could change things so that his suggestion could solve this problem, so maybe the default browser that satisfies xdg-browser (or whatever) on alt-arches doesn't *have* to be the same as x86_64
16:27:41 <maxamillion> sgallagh: ah, good point
16:27:43 <maxamillion> damn
16:27:45 <sgallagh> OK, so the level of uncertainty here is convincing me to waver on my suggested proposal
16:28:17 <sgallagh> maxamillion: Right, I was saying that's a general solution to the problem, not a specific solution to the ~/.mozilla issue
16:28:20 <sgallagh> I think we're agreeing
16:28:27 <dgilmore> sgallagh: there is nothing to change for my suggestion to be true
16:28:36 <maxamillion> sgallagh: ohhhhhh, gotchya
16:28:40 * maxamillion misundersood
16:28:40 <sgallagh> dgilmore: What do you mean "nothing to change"?
16:28:44 <dgilmore> sgallagh: release criteria all says a working browser
16:28:44 <maxamillion> and I can't type
16:28:52 <dgilmore> it does not say a working firefox
16:29:05 <sgallagh> dgilmore: Yes, I know. Otherwise this would be a clear-cut situation.
16:29:56 <dgilmore> sgallagh: there coul dbe changes in comps, kickstarts and possibly dnf to make it all work transparently
16:30:02 <dgilmore> and possibly in packages also
16:30:07 <sgallagh> dgilmore: The initial question boils down to "is it okay to have non-x86 platforms have a different default browser or should we mandate common behavior?"
16:30:13 <dgilmore> to make sure they all provide browser
16:30:35 <dgilmore> sgallagh: we can not mandate common behaviour
16:30:44 <jforbes> dgilmore: +1
16:30:49 <dgilmore> there is disparate functionality today on different arches
16:31:22 <nirik> again tho someone would have to do the work...
16:32:26 <jwb> dgilmore: i think the focus on firefox/firefox-esr is because the other browsers are also known to be broken
16:32:39 <jwb> dgilmore: e.g. midori has (had?) issues on arm
16:32:50 <sgallagh> That's a piece of it, yes.
16:33:03 <nirik> midori is kinda on life support... no upstream activity in quite a long time.
16:33:07 <maxamillion> :(
16:33:15 <sgallagh> I suppose we could at least define a set of functionality a browser has to have in order to be the default on any arch?
16:33:17 <dgilmore> jwb: firefox has issues on arm
16:33:18 <jwb> and then if you bring in something like konqueror, you start exploding deps into KDE land
16:33:20 <nirik> epiphany should work I would think
16:33:35 <dgilmore> but thats more to do with things outside of our control
16:34:00 <jwb> dgilmore: yes, but saying "we just need a browser" when there's no browser that works is kind of going in circles
16:34:18 <sgallagh> e.g. "In order to be default, a browser must support TLS v1.2+, HTML 5 video and ..."
16:34:18 <dgilmore> google for instance detects firefox on arm as a old school mobile device and gives you the most basic experience
16:34:31 <jwb> so that's why people are focusing on solving the issue on one browser vs. playing the "which browser works where"
16:34:42 <maxamillion> epiphany, otter, qupzilla, chromium(?), etc etc ...
16:34:47 <jwb> sgallagh: jebus.  setting the bar pretty high there
16:34:57 <dgilmore> maxamillion: chromium is x86 only
16:35:04 <maxamillion> dgilmore: really?
16:35:07 <jwb> really
16:35:20 <maxamillion> dgilmore: how the hell do they build ChromiumOS for all these ARM chips then?
16:35:21 <dgilmore> sgallagh: that functionality is a bit high
16:35:27 <maxamillion> actually ... nvm, off topic
16:35:36 <jwb> i don't even want to entertain chromium.  it's more work than firefox/firefox-esr
16:35:43 <dgilmore> maxamillion: its all cross built and clunky afaik
16:35:44 <jwb> also, spot may kill me
16:36:03 <dgilmore> maxamillion: in fedora we have not enabled building on arm
16:36:12 <dgilmore> jwb: likely :)
16:36:18 <maxamillion> dgilmore: ahhhh ok
16:36:46 <nirik> I think the arm build needs binary stuff to build.
16:36:53 <maxamillion> rgr
16:36:58 <nirik> ie, some executables that have no source.
16:36:58 <dgilmore> if we wanted to ensure that there is one browser for everywhere, the best bet is firefox-esr
16:37:11 <dgilmore> but that would need someone to work on it
16:37:18 <maxamillion> right
16:37:38 <maxamillion> and there's always the possibility of it needing older libs/sonames (as sgallagh pointed out)
16:38:01 <nirik> it may well be that the issues with firefox are fixed by the time we get to release... it's just the timing of this change was unfortunate.
16:38:49 <jforbes> Is anyone actively working on the fix?
16:40:05 <sgallagh> DIdn't sound like it from Martin's messages, but I'm not sure about upstream
16:40:23 <dgilmore> i think jwb would be the best to answer that
16:40:39 * nirik notes again how much he hates cloned bugs. ;)
16:41:00 <jwb> i think sharkcz is looking into it and discussing with IBM.  not sure there is much progress as of yet
16:41:22 <jwb> i have another crazy solution
16:41:40 <jwb> actually, you know what, that's not going to work.  nevermind
16:41:51 <jforbes> lynx!
16:42:12 <langdon> elinks is the new lynx!
16:42:35 <jforbes> I still can't be bothered to type vim, I have to alias vi
16:42:46 <sgallagh> jwb: I'd still like to hear it, crazy or not
16:43:09 <nirik> so, the immediate concern here is beta for ppc64/s390x?
16:43:25 <jwb> sgallagh: ship a flatpak of a working firefox
16:43:31 <jwb> nirik: and aarch64
16:43:59 <sgallagh> But as I said above, I guess I'll be satisfied by defining a minimum functionality requirement for default browser and letting the media satisfy it however works for them.
16:44:03 <maxamillion> jwb: this might be an ignorant question, but how would that solve the issue?
16:44:40 <jwb> maxamillion: you'd be able to take an existing, older, working firefox, containerize it, and provide that as the browser.  like i said, it's crazy
16:44:43 <sgallagh> maxamillion: He said it wouldn't
16:45:14 <dgilmore> we still have no support for making flatpaks and discussions have tappered off
16:45:28 <langdon> dgilmore, they are likely coming back
16:45:29 <dgilmore> but in the future it could be an option
16:45:38 <langdon> i have been talking to some people..
16:45:44 <dgilmore> langdon: sure. just not doable in f26
16:45:51 <nirik> https://bugzilla.mozilla.org/show_bug.cgi?id=1323303 has some interesting comments
16:45:51 <langdon> ohh no.. def not
16:45:54 <langdon> f27 maybe
16:46:35 <sgallagh> Proposal: Install media may select any browser as default, differing between architectures, provided that they support TLSv1.2+
16:46:39 <sgallagh> (straw-man)
16:47:22 <nirik> I don't think we should detail it with TLSv1.2+ or anything... whoever is making the selection should take that kind of thing into account
16:47:48 <dgilmore> i don't think that needs to be taken into account either
16:48:12 <maxamillion> jwb: ah
16:48:15 <nirik> I guess I am not against that, but again it would need work... in anaconda or other places to make it work...
16:49:54 <maxamillion> I'm kind of for the TLSv1.2+ requirement, that shouldn't be an unreasonable bar to meet in order to ship the default browser
16:50:00 <maxamillion> sgallagh: +1
16:50:31 <dgilmore> maxamillion: at some point it will not matter or even be relevant
16:50:45 <dgilmore> TLSv1.2+
16:50:58 <maxamillion> dgilmore: right, but then we can update the guideline
16:51:02 <sgallagh> dgilmore: I did a poor job of explaining that.
16:51:03 <dgilmore> TLS.12 will be obsolete
16:51:18 <maxamillion> so will sha256 and sha512, etc etc
16:51:19 <sgallagh> I meant for that to be the guideline today, with it written somewhere and updated appropriately for each release.
16:51:31 <sgallagh> I'll rephrase.
16:51:31 <jforbes> That makes more sense
16:51:45 <maxamillion> eventually with quantum computing and quantum factorial machines, all of RSA will be obsolete ... we'll adapt when that time comes
16:51:57 <sgallagh> Proposal: Install media may select any browser as default, differing between architectures, provided that they support a FESCo-approved set of minimal requirements (TLSv1.2+ as of today)
16:52:07 <maxamillion> sgallagh: +1
16:52:12 <jforbes> sgallagh: +1
16:52:13 <nirik> yes, but there's about 10,000 things a browser can do, micromanging some specific crypto version seems like a very bad idea to me.
16:52:38 <nirik> why don't we trust whoever is deciding this on the install media?
16:52:44 <maxamillion> nirik: at least maintaining a certain level of security features should be a requirement, yes?
16:52:49 <nirik> do we really think someone is going to choose dillo?
16:52:57 <dgilmore> nirik: that is my thought
16:53:09 <dgilmore> I feel like its unnecessary noise
16:53:23 <maxamillion> nirik: yes, I absolutely think there is the potential for someone would do something that silly
16:53:32 <maxamillion> that someone would*
16:54:03 <nirik> why on earth? who would use that install media then? no one.
16:54:20 <maxamillion> nirik: hell, I might have if I was a spins maintainer in college just because I thought it would be comical
16:54:52 <maxamillion> is it a good idea? no, not even a little bit
16:55:01 <maxamillion> would I have done it? ... ehhh, maybe?
16:55:14 <jforbes> nirik: you assume people using the media would understand the risks.  I don't think that is always the case
16:55:29 <sgallagh> jforbes: +1
16:55:33 <maxamillion> jforbes: +1
16:55:45 <nirik> you all are assuming maintainers hate all their users and don't want anyone to use their spin?
16:55:54 <nirik> it boggles my mind.
16:56:11 <sgallagh> I certainly hate all my users :-P
16:56:20 <jforbes> most simple path forward possibly?
16:56:26 <nirik> and if so, why didn't someone do this in the past?
16:56:49 <sgallagh> OK, we have been on this topic for an hour. If the conclusion is "assert nothing", then let's have done.
16:56:51 <maxamillion> nirik: I am not assuming that at all, what if whomever is maintaining the spin also lacks the knowledge to make the choice? it could be inexperience and nothing more
16:57:18 <nirik> maxamillion: a guideline to them of "supports TLSv1.2+" isnt much of one.
16:57:36 <nirik> Id support it without the requirements, otherwise I guess +0
16:57:53 <maxamillion> nirik: we have to start somewhere, we can have other guidelines if we like but I do think having a good baseline is a good idea
16:58:03 <dgilmore> 0 also here
16:58:06 <dgilmore> same reasons
16:58:17 <maxamillion> we have all sorts of guidelines all over the distro, why is this where you draw the line?
16:58:21 <sgallagh> OK, so the motion fails.
16:58:26 * nirik notes we could also very easily tell someone they are being dumb if they try to be
16:59:14 <nirik> sgallagh: note though that we have no guideline against the proposal either... if someone did the work to make it work.
16:59:33 <maxamillion> we have a text book worth of rpm packaging guidelines and compiler flag guidelines and requirements on all sorts of stuff, but we can't enforce a base line of crypto in the browser? am I missing something?
17:00:46 <nirik> maxamillion: the folks who maintain spins and our default media are not just starting out packaging and need guidence. Also changes to kickstarts and the like all need review by another person.
17:02:18 <nirik> and one thing like TLSv1.2+ seems an odd thing to call out. How about requiring websockets support? javascript support? html5? no ability to load flash?
17:02:20 <maxamillion> nirik: true, but I don't think a proficiency in packaging or knowing how to make a kickstart inherently means they know their way around crypto or web technologies
17:02:45 <sgallagh> nirik: I tried that above and got yelled at for being too specific.
17:02:51 <maxamillion> nirik: I think we should do all of that, define a baseline list of things and say "if the browser supports these, then go for it"
17:03:54 <nirik> but there's abotu 1,000... html5 storage, h624 plugin support, css support, http/2, cookie handling, sandboxing, I could probibly go on and on
17:04:27 <maxamillion> probably
17:04:37 <dgilmore> to me it seems like it was just a year or two back that TLS1 was needed and sslV3 was bad, the progression is moving fast, I just think that encoding it is something that will need constant maintainenece, and that we have to assume that things will keep up with modern standards
17:04:52 <dgilmore> thatus encoding it will also have no real impact
17:05:04 <maxamillion> I just don't see how this is any different than things like packaging guidelines
17:05:29 <jforbes> It's not, a spin is basically a meta package
17:05:43 <sgallagh> Look, this topic is going nowhere. Can we move on if we're just going to keep talking in circles?
17:05:46 <dgilmore> maxamillion: we do not have a guideline that says openssh has to support RSA
17:05:51 <nirik> maxamillion: should we have these for all default apps?
17:06:09 <maxamillion> nirik: I don't see why not
17:06:33 <maxamillion> alright, we've been on this for an hour and there is no clear majority opinion that's leadin ghte conversation ... can we table this?
17:06:36 <dgilmore> anyway we should move on, we are an hour in
17:06:40 <nirik> then fesco wants to get in the business of defining all the defaults for the media? based on criteria we make up?
17:06:50 <nirik> yeah, lets move on.
17:07:04 <maxamillion> nirik: oh no, I don't mean fesco specifically ... I mean as the Fedora Project
17:07:17 <maxamillion> alright
17:07:26 <maxamillion> #info FESCo to table this issue for future discussion
17:07:35 <maxamillion> #topic #1708 F27 System Wide Change: Arbitrary Branching
17:07:36 <maxamillion> .fesco 1708
17:07:36 <maxamillion> https://pagure.io/fesco/issue/1708
17:07:37 <zodbot> maxamillion: Issue #1708: F27 System Wide Change: Arbitrary Branching - fesco - Pagure - https://pagure.io/fesco/issue/1708
17:08:02 <sgallagh> This is a critical dependency of Modularity, which in turn is a top-level Council Objective. +1
17:08:58 <maxamillion> I'm concerned about the decomissioning of pkgdb2 on that short of notice, I'm under the impression there's various things in releng and the infra that use it's REST API
17:09:28 <nirik> I'm +1 with it, but I would love to hear more about branch naming and SLA info for branches. Using the version seems poor, but not sure what works better.
17:09:28 <dgilmore> while on the whol I am okay with it
17:10:03 <threebean> maxamillion: in the Focus/ doc, we list everything we're aware of that uses the API and how to deal with those.
17:10:04 <dgilmore> I think until we are doing things only as modules we should allow arbitory branches for modules, but keep the existing functionality
17:10:33 <dgilmore> at the least wwe have to keep the f27 f28 etc branches until we are doing only modules
17:10:35 <maxamillion> I'm not against the branching itself, but it is mentioned that part of this (or a pre-req) is that we decomission pkgdb and one month is kind of aggressive when people are already knee deep in other work to now have to pivot and port software away from that API
17:10:47 <langdon> dgilmore, +1 to that
17:11:15 <maxamillion> threebean: where might I find the Focus/ doc? I don't see that linked in this ticket
17:11:27 <threebean> ticket links to Change/ and the Change/ links to the Focus/
17:11:33 <threebean> https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching
17:12:01 <threebean> near the bottom is the "work plan".
17:12:35 <threebean> one item we forgot, for instance, is that some client tools use the pkgdb api to query for the list of latest releases.
17:12:55 <threebean> our plan there is to generate a static json file from the data we'll store in pdc, and put it on the proxies for client tools to consume (as if pkgdb were still there).
17:12:57 <maxamillion> threebean: the container release automation I've been working on for a while now heavily leverages pkgdb's rest api ...
17:13:03 <threebean> oh?
17:13:05 <maxamillion> threebean: I'm concerned how many other things are "unknown"
17:13:06 <maxamillion> threebean: yeah
17:13:57 <threebean> maxamillion: can you link me to it, either here or afterwards?
17:14:03 <maxamillion> threebean: we can follow up off list though, that shouldn't be a blocker for this thing, it's just going to hose my timeline a little
17:14:25 <maxamillion> I'm +1 to the change
17:14:27 <threebean> there's no way we'll catch every use case... but we want to handle as many of them up front, as we can.
17:14:47 <maxamillion> dgilmore: jwb: jforbes: ?
17:14:59 <dgilmore> threebean: I am concerned about making sure that we can make critpath useful, and that we do not lose important data
17:15:02 <mprahl> We will definitely need to continue to broadcast this change to the community to try and uses of the PkgDB API that we missed.
17:15:18 * threebean nods
17:15:29 <mprahl> *try and find uses
17:15:30 <dgilmore> I am +1 to arbitory branching, I think I am -1 to removing pkgdb at this point in time
17:15:43 <jforbes> +1 I suppose if we understand the risk well enough
17:15:52 <threebean> dgilmore: at very least, we'll archive the pkgdb db and keep a copy so we can mine it later.
17:15:57 <jwb> doesn't arbitrary branching break pkgdb?
17:16:03 <dgilmore> jwb: no
17:16:19 <threebean> dgilmore: beyond that, we'll be migrating specific portions of the pkgdb data to other systems.
17:16:25 <mprahl> jwb: PkgDB is written on the notion of one branch per Fedora release, so sort of.
17:16:49 <threebean> yeah, our current plan and pkgdb are pretty incompatible.
17:16:59 <dgilmore> we still need the fedora branch until we only do modular things
17:17:01 <jwb> maybe put another way: if pkgdb keeps running, will it just ignore those other branches?
17:17:10 <dgilmore> jwb: it will
17:17:11 <threebean> for them to coexist will require either major code changes to pkgdb, or some new clever approach.
17:17:22 <dgilmore> threebean: please explain that more?
17:17:26 <threebean> ah, but the dist-git gitolite config can't.
17:17:48 <threebean> the thing that actually imposes acls on dist-git is gitolite.  it's config is auto-generated from pkgdb's API by a cronjob/fedmsg-trigger.
17:18:05 <mprahl> FYI, in case it isn't clear from the Focus Doc, we are planning to migrate the data in PkgDB, not just the functionality.
17:18:48 <threebean> I guess we could change that auto-generation to derive the ACLs from pkgdb and other sources?  but that gets messy real fast.
17:19:40 <threebean> we have this need to introduce EOL metadata on a per-branch basis, and splitting that across multiple systems will be confusing.
17:22:24 <threebean> (I bet people are reading.  will wait.)
17:23:37 <jwb> i'm generally OK, but the concern is making sure we get in front of explaining to contributors how to use whatever is replacing pkgdb
17:23:40 <dgilmore> threebean: so people today can make arbitory branches themselves
17:23:56 <maxamillion> jwb: +1
17:24:34 <nirik> jwb: +1
17:24:44 <threebean> can fesco advise on how best to advertise it?
17:24:58 <nirik> a nice faq of "I used to do X in pkgdb, what do I do now" would be good...
17:25:04 <threebean> we have a baseline plan for education, which is that the old pkgdb url we want to replace with a redirect to a wiki page explaining the change and new tools to use.
17:25:14 <threebean> we sent out the Change
17:25:23 <threebean> what else should we do?
17:25:41 <dgilmore> jwb: indeed
17:25:47 <nirik> perhaps a small note to devel-announce with the timeline / pointer to docs again?
17:26:09 <dgilmore> my biggest concern is that things will break and we wount have the time or resources to fix things
17:26:26 <dgilmore> and at this point I am not 100% sure of all the implications
17:26:42 <maxamillion> same
17:27:23 <threebean> there's a risk on two sides, right?
17:27:29 <maxamillion> the lack of advertisement to the packagers to use pkgdb as part of their workflow and the lack of understanding implications concern me ... I'm in support of the arbitrary branching, but losing pkgdb in about 4-ish weeks concerns me
17:27:34 <threebean> on one we decomission pkgdb too early, without enough notice.
17:27:43 <jwb> i'd also say that RIGHT NOW we want to put big fat warnings on pkgdb that show up any time someone logs in
17:27:50 <threebean> on the other, we do it too late with no time for people to experiment with the new abilities for the f27 cycle.
17:27:54 <maxamillion> jwb: +1
17:27:59 <jwb> that redirect to explanations on what to do
17:28:00 <jforbes> jwb: +1
17:28:05 <maxamillion> big red banner with links to info
17:28:16 <dgilmore> threebean: sure
17:28:40 <dgilmore> jwb: that would help some
17:29:08 <dgilmore> jwb: we probably want to put a big fat warning on koji and pkgs.fp.o also
17:29:15 <dgilmore> and people will still miss it
17:29:42 <jwb> they will, but all of that is better than relying on the Change, which 0 people read
17:29:54 <nirik> as long as we do fix everything using it to use some other process and document that we should be ok... there will always be people who need to look at the docs
17:30:29 <dgilmore> nirik: yep. we still get the odd question over the kerberos change
17:30:55 <dgilmore> people had missed that in the last 6 months
17:31:10 <nirik> yep
17:32:00 <maxamillion> dgilmore: yeah, that's and unfortunately good example
17:33:32 <nirik> anyhow, I'm for it and we should try and advertirze as best we can
17:33:34 <dgilmore> so where are we
17:33:51 <maxamillion> Proposal: FESCo Approves F27 Change for Arbitrary Branching but would like to have a separate Proposal and Plan to decomission pkgdb2 submitted to FESCo
17:34:14 <maxamillion> or is the latter part of that too "red tape-y" ?
17:34:36 <dgilmore> +1
17:35:13 <threebean> hm.  I think our F27 Change already contains the proposal and plan to decomission pkgdb?
17:35:47 <threebean> what kind of further specifics would fesco want to see in such a proposal?
17:35:54 <maxamillion> threebean: right, but do you want those things married to one another? because it seems as though there's a lot of -1 around pkgdb decomission as it's currently proposed
17:36:19 <threebean> hm.
17:36:40 <maxamillion> threebean: there's a plan for the technical side, but nothing in the docs address the community aspect of this problem
17:36:40 <nirik> well, they kind of have to be... without work on pkgdb to make it work with the new branches right?
17:37:02 <mprahl> nirik: Yes, exactly
17:37:28 <mprahl> maxamilli: I have taken down notes on the suggestions FESCo has made for advertising.
17:37:29 <maxamillion> in that case, I'm switching to -1 until we can address the pkgdb stuff
17:37:34 <threebean> maxamillion: can we agree to amend the Change to include 1) the big fat banner ad in pkgdb, 2) email to devel-announce, 3) anything else?
17:37:39 <dgilmore> nirik: mprahl: in what way?
17:38:07 <maxamillion> threebean: need a migration guide
17:38:11 <mprahl> dgilmore: PkgDB does not support Arbitrary Branches, so we would need to either have a plan to heavily modify PkgDB or decommission it
17:38:22 <nirik> dgilmore: pkgdb generates acls... it will not work with arbitrary branches.
17:38:32 <dgilmore> nirik: it does though
17:38:34 <dgilmore> http://pkgs.fedoraproject.org/cgit/rpms/koji.git/log/?h=1.12.0
17:38:44 <threebean> maxamillion: migration guide for users/community?  you need it written beforehand?  (just trying to clarify..)
17:39:12 <dgilmore> the acls are not as fine grained as pkgdbs but as i understand it they are not going to be as fine grained anyway
17:39:31 <maxamillion> threebean: yes, I didn't realize the plan was to kill pkgdb in ~4 weeks
17:39:49 <nirik> dgilmore: it would default to the master branch for aclls there?
17:40:06 <maxamillion> threebean: I'm going to wager less that 2% of the fedora packagers at large know that is happening or what the implications of it are
17:40:09 <nirik> and no way to change them/etc....
17:40:10 <dgilmore> nirik: need to double check
17:40:31 <nirik> yeah, looking at it, thats what it does for any of the branches we don't care about.
17:40:50 <nirik> it would also not show any of those anywhere, so it would be like they were invisible.
17:41:39 <threebean> (and those branches don't have any metadata associated with them..)
17:41:45 <maxamillion> threebean: something like this but for how packagers are going to get things done that they currently do in pkgdb -> https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
17:42:04 <threebean> maxamillion: agreed on the 2% estimate.
17:42:15 <threebean> we can write such a page next week (it's already in our sprint)
17:42:23 <maxamillion> threebean: cool
17:43:02 <mprahl> What would be the earliest that we can present the amendments to the Change Proposal? Is next week too early for FESCo?
17:43:24 <maxamillion> mprahl: I think next week would be fine
17:43:42 <threebean> yeah, I'm worried about kicking the can down the road here.  if we write it, then write a new change proposal.. we're supposed to wait 7 days before fesco reviews it which would really be 2 weeks from now.
17:43:55 <threebean> (assuming we can't get that all written up by the end of the day today)
17:44:27 <maxamillion> threebean: wait, why can't the writing be worked on Mon-Thu of next week? or did I misunderstand?
17:44:39 <threebean> that's when we'll do it.
17:44:56 <dgilmore> maxamillion: the week of review on devel@ first
17:45:00 <dgilmore> for a new change
17:45:01 <maxamillion> dgilmore: ohhhh ok
17:45:01 <threebean> but, I thought the rule was that if we write it during the week, fesco won't review it until the week after.
17:45:02 <maxamillion> right
17:45:06 <maxamillion> gotchya
17:45:26 <jforbes> but this is more continued business, seems we could make an exception
17:45:28 <nirik> but this isn't a new change, its some additions to an existing change
17:46:02 <maxamillion> Proposal: Current F27 System Wide Change: Arbitrary Branching will make changes based on FESCo feedback and be back on the FESCo meeting agenda next week
17:46:15 <sgallagh> +1
17:46:16 <maxamillion> nirik: my proposal suggested a new change
17:46:23 <maxamillion> nirik: well, my other proposal
17:46:24 <jforbes> +1
17:46:25 <threebean> (+1)
17:46:28 <maxamillion> threebean: does that work?
17:46:34 <nirik> mprahl / threebean: is that too long? or ?
17:46:47 <maxamillion> +1 (for posterity)
17:46:53 <threebean> we'll keep working on stuff as if it will be approved so we don't lose time.
17:47:01 <threebean> and we'll have the docs ready for you guys next week.
17:47:04 <nirik> ok, great. +1
17:47:17 <mprahl> Thank you for your time and feedback everyone.
17:47:35 <jwb> +1
17:47:45 <maxamillion> threebean: yeah, I htink that's a good plan ... it doesn't seem that there's any harsh objection to everything, just some details on implementation and rollout (at least that's my opinion and the impression I get)
17:48:05 <maxamillion> dgilmore: jforbes: ?
17:48:11 <maxamillion> jforbes: errr, sorry
17:48:53 <dgilmore> +1
17:48:54 <maxamillion> #agreed Proposal: Current F27 System Wide Change: Arbitrary Branching will make changes based on FESCo feedback and be back on the FESCo meeting agenda next week (+1: 6, -1: 0, +0: 0)
17:49:03 <maxamillion> #topic #1709 Review of release blocking deliverables for F26
17:49:03 <maxamillion> .fesco 1709
17:49:04 <maxamillion> https://pagure.io/fesco/issue/1709
17:49:05 <zodbot> maxamillion: Issue #1709: Review of release blocking deliverables for F26 - fesco - Pagure - https://pagure.io/fesco/issue/1709
17:49:38 <dgilmore> I never finished my update to the issue
17:50:01 <maxamillion> would it mess anything up to table this one to next week to allow updates to come in?
17:50:12 <dgilmore> We are making power and aarch64 cloud and docker images, due to anaconda bugs things had been failing to compose
17:50:33 <jforbes> Are those bugs being fixed?
17:50:41 <dgilmore> jforbes: yeah
17:51:06 <maxamillion> Proposal: Table Review of release blocking deliverables for F26 until next week to allow updates to the issue to be made
17:51:14 <jforbes> +1
17:51:30 <sgallagh> +1
17:51:32 <maxamillion> +1
17:51:49 <jwb> +1
17:51:52 <nirik> sure, +1
17:51:59 <dgilmore> there is a bug in koji and some bugs in the anaconda runtime
17:52:04 <dgilmore> +1
17:52:24 <maxamillion> #agreed Proposal: Table Review of release blocking deliverables for F26 until next week to allow updates to the issue to be made (+1: 6, -1: 0, +0: 0)
17:52:32 <maxamillion> #topic #1710 F26 Changes not in ON_QA status (<100% completed)
17:52:32 <maxamillion> .fesco 1710
17:52:32 <maxamillion> https://pagure.io/fesco/issue/1710
17:52:33 <zodbot> maxamillion: Issue #1710: F26 Changes not in ON_QA status (<100% completed) - fesco - Pagure - https://pagure.io/fesco/issue/1710
17:52:47 <maxamillion> I'm honestly not sure what's being asked of us in this ticket
17:53:33 <nirik> well, those changes are not showing ready, so we should drop them or find out what else to do.
17:54:18 <nirik> some of those are landed, just maintainers not responding
17:54:20 <maxamillion> the Docker Overlay2 is done, I know folks in the Atomic WG had worked to get that in and I don't think anyone realized that the change hadn't been updated
17:54:24 <maxamillion> yeah
17:55:02 <dgilmore> outside of modular server preview and automated testing and release of cloud images I think the rest are actually all done
17:55:25 <dgilmore> koji latest-build f26 ruby
17:55:25 <dgilmore> Build                                     Tag                   Built by
17:55:25 <dgilmore> ----------------------------------------  --------------------  ----------------
17:55:28 <dgilmore> ruby-2.4.1-79.fc26                        f26                   vondruch
17:55:34 <dgilmore> for instance
17:55:35 <maxamillion> +1
17:55:48 <dgilmore> I have seen python fall back to C.UTF8
17:56:03 <maxamillion> what's the "drop dead date" for FESCo to make the call on what to include and what not to?
17:56:16 <dgilmore> we made sure that what could be done of the c flags was done prior to the mass rebuild
17:56:31 <dgilmore> same for aarhc64 48 bit va
17:56:46 <dgilmore> not sure on the crypto for openjdk
17:57:24 <maxamillion> I *think* that's done, I seem to remember it being discussed previously in a FESCo meeting
17:57:39 <dgilmore> thats my thought also
17:57:54 <dgilmore> so this week is the drop dead date
17:58:03 <cstratak> python3 c.utf8 locale is already implemented (also the owner can be changed to me)
17:58:13 <dgilmore> but if things are done and just need marked as so we should get them marked as done
17:58:31 <maxamillion> dgilmore: +1
17:58:44 <maxamillion> dgilmore: want to make a proposal about how to move forward?
18:01:25 <dgilmore> proposal #agreed we give everyone a week to update the change staus. If the change is not updated or complete we will enact contigency plans.
18:02:13 <maxamillion> +1
18:02:22 <nirik> +1
18:02:37 <jforbes> +1
18:02:57 <dgilmore> +1
18:03:19 <sgallagh> +1
18:03:50 <maxamillion> jwb: ?
18:04:07 <jwb> +1
18:04:13 <jwb> sorry, multiple meetings at this point
18:04:14 <maxamillion> #agreed proposal #agreed we give everyone a week to update the change staus. If the change is not updated or complete we will enact contigency plans. (+1: 6, -1: 0, +0: 0)
18:04:17 <maxamillion> jwb: no worries
18:04:24 <dgilmore> #undo
18:04:24 <zodbot> Removing item from minutes: AGREED by maxamillion at 18:04:14 : proposal #agreed we give everyone a week to update the change staus. If the change is not updated or complete we will enact contigency plans. (+1: 6, -1: 0, +0: 0)
18:04:25 <maxamillion> jwb: this one has gone pretty long
18:04:37 <jwb> we likely need to put a more forceful time limit on topics or the meeting as a whole
18:04:38 <dgilmore> #agreed we give everyone a week to update the change staus. If the change is not updated or complete we will enact contigency plans. (+1: 6, -1: 0  )
18:04:45 <maxamillion> dgilmore: +1 thanks
18:04:50 <jwb> two hours is killing me
18:04:57 <dgilmore> yeah
18:04:57 <maxamillion> last one!
18:04:59 <maxamillion> #topic #1712 F27 System Wide Change: Perl 5.26
18:04:59 <maxamillion> .fesco 1712
18:04:59 <maxamillion> https://pagure.io/fesco/issue/1712
18:05:00 <zodbot> maxamillion: Issue #1712: F27 System Wide Change: Perl 5.26 - fesco - Pagure - https://pagure.io/fesco/issue/1712
18:05:01 <dgilmore> lets wrap up
18:05:05 <dgilmore> gahh
18:05:07 <dgilmore> :D
18:05:08 <jkaluza> :)
18:05:09 <maxamillion> +1
18:05:30 <sgallagh> +1
18:05:34 <dgilmore> +1 to perl
18:05:35 <nirik> +1
18:05:36 <jforbes> +1
18:06:19 <jwb> i would like to forever +1 this so i don't have to keep +1ing it every release
18:06:38 <dgilmore> jwb: indeed
18:07:21 <maxamillion> #agreed F27 System Wide Change: Perl 5.26 (+1: 6, -1: 0, +0: 0)
18:07:47 <maxamillion> #topic Next week's chair
18:08:56 <maxamillion> who's up?
18:09:22 * dgilmore did last week
18:09:49 <nirik> I can do it.
18:09:58 <maxamillion> #info nirik to chair next week's meeting
18:10:04 <dgilmore> thanks nirik
18:10:09 <maxamillion> thanks nirik
18:10:11 <maxamillion> #topic Open Floor
18:10:28 <maxamillion> I'll give this 2 minutes and if there's nothing I'll close up shop
18:12:03 <maxamillion> #endmeeting