18:00:09 <paragan> #startmeeting FESCO (2015-08-05)
18:00:09 <zodbot> Meeting started Wed Aug  5 18:00:09 2015 UTC.  The chair is paragan. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:09 <paragan> #meetingname fesco
18:00:09 <paragan> #chair ajax dgilmore number80 jwb nirik paragan rishi thozza sgallagh
18:00:09 <paragan> #topic init process
18:00:09 <zodbot> The meeting name has been set to 'fesco'
18:00:09 <zodbot> Current chairs: ajax dgilmore jwb nirik number80 paragan rishi sgallagh thozza
18:00:18 <nirik> morning.
18:00:23 <rishi`> evening
18:00:25 <paragan> Hi
18:00:38 <ajax> howdy
18:00:38 <sgallagh> Guten tag
18:01:21 <jwb> hell
18:01:22 <jwb> er
18:01:23 <jwb> hello
18:01:42 <sgallagh> jwb: Either way, really
18:01:56 <jkurik> hi
18:02:20 <paragan> okay let's start
18:02:20 <paragan> #topic 1455 F23 System Wide Change: Standardized Passphrase Policy
18:02:20 <paragan> .fesco 1455
18:02:20 <paragan> https://fedorahosted.org/fesco/ticket/1455
18:02:22 <nirik> so I wrote this up...
18:02:22 <zodbot> paragan: #1455 (F23 System Wide Change: Standardized Passphrase Policy) – FESCo - https://fedorahosted.org/fesco/ticket/1455
18:02:36 <nirik> but wanted folks to look it over again (since I changed some wording)
18:02:49 <nirik> and also to talk about luks passwords (which I didn't address).
18:03:11 <number80> o/
18:03:12 <nirik> https://fedoraproject.org/wiki/Passphrase_policy
18:03:19 <nirik> anyone find anything they would prefer to change there?
18:03:33 <dgilmore> hi
18:04:05 <paragan> luks uses libpwquality so the new proposed rules for libpwquality will also applied to luks?
18:04:42 <sgallagh> nirik: I might explicitly state that the "score" must not be used as a decision-making factor
18:04:43 <nirik> paragan: nope... it doesn't. anaconda calls pwquality directly for it
18:04:47 <nirik> +pwpolicy luks --strict --minlen=8 --minquality=50 --nochanges --emptyok
18:05:12 <nirik> sgallagh: good idea.
18:05:35 <ajax> looks sane enough to me
18:05:43 * nirik edits
18:06:41 <nirik> ok, cryptsetup is linked to libpwquality. cool. .
18:07:19 <paragan> wording looks good to me
18:07:27 <jkurik> nirik: are we still aiming with the Change to F23 ?
18:07:30 <nirik> anyhow, I guess we can ask that luks use the same policy for now and adjust if we want it to be different later?
18:07:44 <nirik> jkurik: yeah, but it will have to be after alpha now. ;(
18:08:17 <jkurik> will not be better to postpone it to F24 ?
18:08:20 <nirik> I think thats better than defering it.
18:08:40 <paragan> yes good to have it in F23
18:08:41 <nirik> well, we could, but I personally don't want to read all the flames.
18:08:58 <nirik> so I am for getting it into f23. The anaconda changes shouldn't be too major.
18:09:06 <nirik> and gnome-intial-setup will need a few
18:09:08 <nirik> and thats it.
18:09:55 <rishi`> Sounds reasonable to me, but I don't work on anaconda. :)
18:10:02 <rishi`> Did we run this past the anaconda team?
18:10:17 <nirik> rishi`: I have been talking with dcantrell yes
18:11:02 <sgallagh> Yeah, from what dcantrell has said to me, they're prepared to run with it once it's approved.
18:11:18 <dgilmore> I am good with what is propossed
18:11:20 <paragan> proposal: Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also
18:11:24 <dgilmore> +!
18:11:25 <dgilmore> +1
18:11:29 <sgallagh> They just mostly want to have something to point at the next time someone complains about their favorite pet-peeve not being addressed by the current implementation
18:11:31 <nirik> +1, sounds good to me.
18:11:37 <ajax> +1
18:11:37 <sgallagh> +1
18:11:39 <paragan> +1
18:11:42 <jwb> +1
18:11:42 <nirik> sgallagh: yes, and that will be us. :) we have to be good for something.
18:12:50 <paragan> #agreed: Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+6, 0, 0)
18:12:52 <rishi`> +1
18:12:57 <paragan> #undo
18:12:58 <zodbot> Removing item from minutes: AGREED by paragan at 18:12:50 : : Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+6, 0, 0)
18:13:07 <paragan> #agreed: Accept https://fedoraproject.org/wiki/Passphrase_policy and use this for luks passwords also (+7, 0, 0)
18:13:14 <nirik> I'll file the bugs and move things forward. Thanks.
18:13:31 <paragan> nirik, thanks
18:13:35 <paragan> #topic 1463 upgrades for F23 and beyond
18:13:35 <paragan> .fesco 1463
18:13:35 <paragan> https://fedorahosted.org/fesco/ticket/1463
18:13:36 <zodbot> paragan: #1463 (upgrades for F23 and beyond) – FESCo - https://fedorahosted.org/fesco/ticket/1463
18:14:30 <nirik> this was posted to the devel-announce list last week...
18:14:32 <dgilmore> I am +1 the devs are willing to support this and not the old way
18:14:34 <nirik> and got 0 replies. ;)
18:14:42 <nirik> +1 to the change
18:15:01 <number80> +1
18:15:02 <paragan> I think we already approved this but for the process let's vote again
18:15:10 <paragan> +1
18:15:29 <number80> I don't think there are any other alternative :)
18:15:46 <rishi`> +1
18:16:13 <ajax> i can't imagine what good it would do to reject this
18:16:14 <ajax> +!
18:16:36 <paragan> nirik, I see discussion happening on rpm-ecosystem list for this fedup change
18:16:46 <nirik> some yeah.
18:16:49 <sgallagh> Yeah this is moving ahead
18:17:08 <sgallagh> And likely will regardless of our vote, so might as well support it (since it makes sense and is a good approach as well): +1
18:17:17 <rishi`> Do we need to decide whether to deprecate fedup or entirely remove it?
18:17:46 <dgilmore> rishi`: I think wwoods wants it taken out back and shot
18:18:07 <rishi`> Yes that was my assumption from the "indentify maintainer" part.
18:18:16 <dgilmore> rishi`: he was talking about sending in patches so we no longer make the upgrade.img initramfs
18:19:04 <paragan> #agreed: Accepted https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades (+7, 0, 0)
18:19:14 <rishi`> Ok
18:19:34 <paragan> #topic #1466 non-responsive maintainer exception process for skottler
18:19:35 <paragan> .fesco 1466
18:19:35 <paragan> https://fedorahosted.org/fesco/ticket/1466
18:19:36 <zodbot> paragan: #1466 (non-responsive maintainer exception process for skottler) – FESCo - https://fedorahosted.org/fesco/ticket/1466
18:19:49 <paragan> Looks like this is in progress and will take some more time.
18:19:53 <jwb> well, sort of
18:19:58 <jwb> here's an update
18:20:26 <jwb> i contacted sam.  he replied saying that he likely doesn't have time to maintain most of his packages and will begin the orphan process for them at some point
18:20:49 <jwb> however, he implied that he would still maintain the packages he uses, nagios-plugins being explicitly listed
18:21:13 <jwb> for nagios-plugins, there is the on-going upstream debate that i think we should frankly avoid at this point
18:21:28 <jwb> the CVE fixes, afaik, are all fixed in the 2.0.3 release
18:21:42 <jwb> i have a local build of that, but i have no realistic way to test
18:21:50 <jwb> so the options seem to be:
18:21:56 <jwb> 1) wait longer
18:22:08 <jwb> 2) have me commit and build the 2.0.3 update to fix the CVEs
18:22:23 <jwb> 3) proceed with non-responsive maintainer despite sam's reply
18:22:34 <jwb> <end of update>
18:22:48 <dgilmore> I do not think we shoudl wait longer
18:22:56 <ajax> 2
18:22:58 <rishi`> I prefer (2).
18:23:03 <paragan> option 2
18:23:13 <sgallagh> I'm of the opinion that the upstream debate should run its course and if monitoring-plugins wants in, it should have its own named package as the fork it is
18:23:16 <rishi`> If something breaks, then either they will fix your build, or revert it.
18:23:17 <number80> I suggest 4) allow infra sysadmins to grant ACLs requests on skottler packages
18:23:19 <sgallagh> I'm for 2) as well
18:23:24 <jwb> it's worth pointing out that solution 2 is only a temporary fix to the on-going MIA problem
18:23:27 <number80> we did that recently for kanarip
18:23:30 <rishi`> Hopefully, a revert would come with an explanation.
18:23:35 <jwb> sgallagh, there is actually a package review for it already done
18:23:37 <nirik> I would also go for 2 and add that we have a nagios setup and would be happy to test your package before it goes in.
18:24:06 <jwb> number80, to whom?  i already have the needed ACLs
18:24:31 <dgilmore> jwb: we need to get the CVE's fixed. so its a good bandaid, however we need something else long term. I do not think waiting is a good option for very long.
18:24:33 <number80> jwb: to any people who requested it, there must be someone who started the non-responsive process
18:24:59 <number80> if their goal is to maintain some packages, let's give them acls directly
18:25:21 <swilkerson> that would be me,, I have already offered to take the package
18:25:25 <jwb> number80, nb started it but suggesting reassigning to upstream nagios.  which is where the upstream debate comes in
18:25:50 <number80> swilkerson: did you request ACLs?
18:26:00 <jwb> no
18:26:11 <number80> then,  I would say 2.
18:26:20 <swilkerson> It was proposed here https://bugzilla.redhat.com/show_bug.cgi?id=1098548#c14
18:26:32 <rishi`> number80: My understanding was that Sam doesn't want swilkerson to be a co-maintainer.
18:27:05 <number80> rishi`: then, he has to choose: maintain it and let swilkerson do it
18:27:17 <nirik> (co)maintainers that don't get along don't seem like a very good idea. Longer term it seems like sam should take monitoring-plugins and swilkerson could take over nagios-plugins... but we aren't there yet?
18:27:39 <jwb> nirik, yes and tbh i'm not sure we'll get there
18:27:53 <nirik> that makes me sad, but ok
18:28:04 <swilkerson> nirik: I agree with that
18:28:49 <paragan> I think for now option 2 is good and all are voted +1 for it
18:28:50 <number80> nirik: I prefer a maintainer that is responsive than one who is not, though I appreciate skottler, if I had to chose, I'd reassign it to swilkerson in these conditions
18:28:55 <sgallagh> In general, I'd much rather side with giving upstream control over the nagios-plugins package than let a fork take over the name
18:29:07 <sgallagh> That seems disingenuous to our users
18:29:14 <number80> *nods*
18:29:16 <jwb> nobody is talking about doing taht here
18:29:32 <ajax> in the meantime, yes, let's nmu the thing and play politics later.
18:29:35 <sgallagh> jwb: It sounds like that's exactly what skottler is doing
18:29:41 <nirik> so, lets do 2 now and keep trying to come to some arrangement?
18:29:55 <jwb> sgallagh, skottler isn't _doing_ anything which is the whole point of this conversation
18:30:05 <jwb> we'd be having a different conversation if he was
18:30:38 <sgallagh> I'm fine with 2) as a stopgap measuer
18:31:12 <jwb> ok.  i'll commit it and file an update.  i will also inform skottler that we did so
18:31:12 <number80> yes, we need to move forward with 2. but I'd rather have a long-term solution quickly
18:32:13 <paragan> let's approve option 2 then
18:32:42 <number80> *nods*
18:32:56 <paragan> #agreed: jwb to commit and build the 2.0.3 update to fix the CVEs (+8, 0, 0)
18:33:47 <paragan> we done with the Agenda topics
18:34:09 <paragan> Should we discuss https://fedorahosted.org/fesco/ticket/1467?
18:34:20 <paragan> jkurik, is there any update on ^^?
18:34:27 <paragan> .fesco 1467
18:34:29 <zodbot> paragan: #1467 (F23 Changes - Progress at Change Checkpoint: Completion deadline (testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1467
18:35:37 <paragan> I don't know how the next process is for Changes remained in NEW/ASSIGNED state
18:35:47 * rishi` has to run now
18:36:01 <rishi`> Need to pack for GUADEC.
18:36:08 <paragan> no problem
18:36:20 <number80> rishi`: travel safe to sweden :)
18:37:14 <sgallagh> Happy trails
18:37:24 <nirik> safe travels rishi`
18:37:32 <sgallagh> paragan: At this point, FESCo really should rule on whether these features must be deferred to F24
18:38:00 <paragan> I am already in favor to move them to F24
18:38:11 <jkurik> paragan: I am going to update the ticket, give me a while
18:38:41 <number80> as for atomic and layered docker image, as they don't impact release, we should allow them to remain for F23
18:39:37 <paragan> I think that will be considered as an exception to Changes process
18:40:06 <dgilmore> number80: we plan to have both of those in place for BEta
18:40:10 <number80> yes, but deferring these would not do a favour to the atomic host
18:40:26 <number80> dgilmore: all the more a reason, not to defer them to F24
18:40:32 <dgilmore> we are still figuring out all teh tooling
18:41:46 <number80> dgilmore: what's the best course in your opinion? deferring to F24 or keeping it for F23? I'm know aware of all the infra discussions for atomic
18:41:53 <number80> s/know/not/
18:42:20 <dgilmore> number80: I would keep for f23 at this point and evaluate at Beta Freeze
18:42:33 <number80> dgilmore: thanks for your feedback
18:43:15 <number80> proposal: reevaluate 2 weeks atomic + layered docker image for inclusion in F23 at beta freeze
18:43:29 <dgilmore> +1
18:43:34 <number80> (implicit: all remaining features should be deferred to F24)
18:43:36 <number80> +1
18:43:38 <nirik> are we going to go over each item? or were we waiting for jkurik to update things?
18:43:45 <nirik> but sure, +1 on that
18:43:57 <jkurik> Except the following two Changes:
18:43:58 <number80> nirik: yeah, not reevaluating each of them :)
18:43:58 <paragan> I am fine with number80 proposal
18:43:58 <jkurik> 1238411 Two Week Atomic
18:44:00 <jkurik> 1243736 Layered Docker Image Build Service
18:44:02 <jkurik> I would recommend to defer these Changes to F24.
18:44:12 <number80> jkurik: thanks :)
18:44:16 <sgallagh> Which is I think the exact proposal.
18:44:19 <sgallagh> I agree; +1
18:44:26 * nirik looks at the rest of the list.
18:45:11 <nirik> there's a lot of them
18:45:13 <number80> as far as I know, other cloud proposals are not ready
18:45:31 <sgallagh> The Node.js stuff is nowhere near ready
18:45:33 <paragan> there is no update on nodejs changes
18:45:33 <number80> especially networkd one
18:45:56 <sgallagh> ditto io.js
18:46:05 <roshi> we've still got a long discussion for networkd
18:46:11 <roshi> to be talked about at flock
18:46:12 <sgallagh> The dnssec and glibc ones are the only ones I'm unsure about
18:46:14 <paragan> we have then Local DNF Resolver Change
18:46:27 <number80> roshi: which means it has to be deferred to F24 ;)
18:46:30 <roshi> the cloud WG knows it'll be F24 at the soonest
18:46:51 <nirik> sgallagh: me too I think.
18:47:15 <paragan> I talked with mfabian and moved glibc Change bug to F24
18:47:21 <nirik> paragan: ah, ok.
18:47:28 <sgallagh> paragan: OK great
18:47:49 <number80> so we continue voting the current proposal or amend it?
18:47:57 <sgallagh> So last I heard, the DNSSEC thing was in a bit of a confused state because the Workstation folks and DNS folks only came to agreement very recently
18:48:29 <nirik> I'm +1 to moving all them to f24 except those two (two week atomic/layered docker images)
18:48:39 <paragan> nirik, +1
18:48:54 <nirik> and then if some of them turn out to be ready, the change owners can come tell us and we can revisit next week.
18:49:02 <number80> nirik: good point
18:49:04 <sgallagh> Reasonable, I guess
18:50:52 * nirik goes to get more coffee while others vote.
18:50:56 <paragan> votes please?
18:51:15 <sgallagh> +1 (again)
18:51:53 <number80> still +1
18:52:20 <paragan> looking back I count 5 +1's
18:53:29 <paragan> #agreed: moving all them to f24 except these (two week atomic/layered docker images) Changes, (+5, 0, 0)
18:53:41 <paragan> #topic Next week's chair
18:53:50 <sgallagh> Are we meeting next week?
18:53:50 <paragan> Next week is Flock!!
18:53:54 <number80> next week will be flock :)
18:54:03 <sgallagh> So probably not
18:54:05 <paragan> I think most people are attending Flock next week so I propose the cancel the meeting next week.
18:54:11 <sgallagh> Seconded
18:54:21 <number80> +1
18:54:33 <jwb> yes
18:54:49 <nirik> yeah, no meeting next week... there was a ticket for a 'meet your fesco' wasn't there?
18:54:53 <paragan> #info no meeting next week
18:54:57 <jwb> yes
18:55:05 <paragan> .fesco 1431
18:55:07 <zodbot> paragan: #1431 (Meet Your FESCo at Flock) – FESCo - https://fedorahosted.org/fesco/ticket/1431
18:56:18 <nirik> 4:30pm on thursday
18:56:27 <nirik> http://flock2015.sched.org/event/85fbdf579fa91c49ba13d45a9c1774eb
18:58:07 <paragan> while we discuss this...
18:58:10 <paragan> Who want to chair for 19th August meeting?
18:58:32 <number80> I'll be flying home on 19th
18:58:51 <jwb> i will miss the 19th as i'll be at LPC
18:59:07 * nirik may be busy rolling out bodhi2 then...
18:59:21 <sgallagh> I can do it, I guess
18:59:29 <sgallagh> If we even have quorum that day...
18:59:30 <number80> sgallagh: thanks
18:59:43 <paragan> sgallagh, thanks
19:00:06 <paragan> #info sgallagh to chair next meeting
19:00:35 <paragan> #topic Open Floor
19:00:39 <jwb> FYI, updates for nagios-plugins filed
19:00:45 <sgallagh> jwb++
19:00:57 <adamw> did the fedup stuff get discussed/decided yet?
19:00:58 <sgallagh> Do we want to discuss i686 in any capacity today?
19:00:58 <paragan> jwb, thanks for quick update on ticket also :)
19:01:05 * dgilmore has one thing
19:01:08 <adamw> sgallagh: i certainly do, but i also had fedup
19:01:12 <sgallagh> adamw: Yes, we approved the Change
19:01:14 <adamw> rgr
19:01:22 <adamw> dgilmore: your thing is probably same as mine?
19:01:44 <nirik> I'd like to note #fedora-flock is open for flock related discussions and remote folks who want to see whats going on at flock. ;)
19:02:02 <dgilmore> 32 bit x86 cloud image is failing to install, anaconda is some kind of special pain.
19:02:16 <dgilmore> the cloud sig has said they do not want to build i386 images
19:02:29 <adamw> ref: https://fedorahosted.org/cloud/ticket/106
19:02:50 <dgilmore> can we consider it non blocking?
19:03:00 <dgilmore> adamw: I think we are on the same page
19:03:26 <dgilmore> since we do not have a list of deliverables and their blocking status its a bit up in teh air
19:03:27 <nirik> +1 to 32bit cloud image being non blocking for f23.
19:03:29 <dgilmore> the air
19:03:44 <nirik> dgilmore: so, an image isn't even made right now? or ?
19:03:48 <dgilmore> if it is blocking then we will have to slip Alpha as we debug the issue
19:04:02 <number80> +1
19:04:04 <dgilmore> nirik: I will have to turn off attempting it
19:04:12 <dgilmore> but it fails to install
19:04:24 <dgilmore> and the output from imagefactory is not at all helpful
19:04:31 <nirik> well, my question is because I'm fine with not shipping it if it's broken, but I don't think we should ship a broken iso out.
19:04:44 <paragan> +1 consider 32bit cloud image as non blocking
19:04:46 <adamw> for the record, cloud images are built by running an install in a somewhat special mode, so what the means is basically 'the image doesn't build'.
19:04:48 <nirik> s/iso/qcow2 or raw/
19:05:00 <nirik> thats fine. :)
19:05:11 <dgilmore> nirik: well if it is non blocking because we know it is not working I will disable its generation
19:05:17 <dgilmore> it will not be made or ship
19:05:27 <jwb> if cloud doesn't want a 32-bit image, then why are we even attempting to ship one?
19:05:43 <nirik> fine also. I just wanted to make sure we didn't say it was non blocking and shipped the broken thing.
19:05:55 <dgilmore> jwb: I only know they don't because I follow their list
19:06:09 <dgilmore> they have not done anything to actually make it happen
19:06:15 <jwb> sigh
19:06:22 <jwb> well, this seems pretty easy to 'make it happen'
19:06:26 <dgilmore> they have not filed any tickets, updated their PRD etc
19:06:49 <number80> damnit
19:07:23 <number80> PRD was updated, but likely not submitted for review ...
19:07:33 <dgilmore> https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD
19:07:36 <adamw> dgilmore: well, per earlier discussion they didn't really know what the process was.
19:07:50 <dgilmore> it says "we will target 32 and 64-bit x86"
19:08:08 <sgallagh> I'm fine with not blocking on 32-bit images if Cloud WG isn't keen on it.
19:08:34 <number80> sigh, ok, I'll put it in cloud SIG meeting agenda next week
19:08:37 <adamw> from a process POV, so far as I'm concerned all that needs to change to make this policy is the Cloud PRD
19:09:01 <dgilmore> adamw: and make sure that releng knows about teh change
19:09:04 <dgilmore> the
19:09:13 <adamw> the criteria already allow for flavor WGs to not deliver images for particular arches at their discretion (though i'm not sure how many people are aware of that)
19:09:15 <adamw> dgilmore: right.
19:09:59 <nirik> right, make it so... next?
19:10:14 <adamw> assuming fesco +1s it we'll consider it 'done' for 23 Alpha, i.e. we're not gonna block Alpha on the missing image.
19:10:31 <jwb> fesco doesn't need to +1 a WGs decision
19:10:37 <jwb> particularly not on their own output
19:10:38 <adamw> OK, i think that was the part that wasn't clear
19:11:06 <adamw> since there's a sort of overlap between the flavor WGs' 'autonomy' or whatever and the distro-wide concept of primary arches
19:11:21 <adamw> i think that's why cloud wasn't sure they could just go ahead and say 'no more i686'
19:11:28 <jwb> fair, but they can
19:11:38 <jwb> now if we can get workstation and server to do the same, i would be so happy
19:11:42 <adamw> =)
19:12:30 <sgallagh> jwb: I'd be thrilled to drop i686 install media, but every time it comes up, the "I have a 30-year-old server in my closet" people show up
19:13:09 <jwb> i don't think carrying something along for the benefit of people that have 0 interest in creating and maintaining that something is a good idea
19:13:32 <jwb> i686 limps along because it isn't terribly broken.  not because someone is invested in its success
19:13:46 <jwb> and that is a model for failure in a number of ways
19:13:56 * dgilmore does not care much either way. my main concern would be OLPC, but that is kinda almost dead,  at least on i686
19:13:59 <adamw> sgallagh: there doesn't seem to be a pile of enthusiasm in the current devel@ thread. maybe dinosaurs are finally dead?
19:14:35 <sgallagh> adamw: roshi just pestered me about hit 45 minutes ago :-P
19:14:38 <nirik> adamw: give them time, it takes a while to load the mail reader on i686. ;)
19:14:48 <adamw> heh.
19:15:02 <adamw> 'i'm still inflating the airbags, damnit'
19:16:35 <paragan> If there's nothing else to discuss, I will close the meeting in 2 minutes
19:18:04 <paragan> #endmeeting