18:00:57 <mitr> #startmeeting FESCO (2014-03-26)
18:00:57 <zodbot> Meeting started Wed Mar 26 18:00:57 2014 UTC.  The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:59 <mitr> #meetingname fesco
18:00:59 <zodbot> The meeting name has been set to 'fesco'
18:01:01 <mitr> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
18:01:01 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:01:03 <mitr> #topic init process
18:01:06 <mitr> Hello everyone
18:01:08 <sgallagh> #info sgallagh is here
18:01:11 <abadger1999> Greetings
18:01:13 <dgilmore> hola amigos
18:01:19 * jreznik is lurking, cooking dinner
18:01:27 <mattdm> hello
18:01:45 <nirik> morning
18:01:53 * notting is here
18:02:55 <t8m> hi
18:03:45 <mitr> OK, let's start
18:03:51 <dgilmore> /me needs to leav in an hour
18:04:05 <ltinkl> hi
18:04:18 <mitr> Based on devel discussion, I have dropped #1178 from the agenda.
18:04:22 <dgilmore> I have to pick up my daughter and take her to get registered for kindergarten
18:04:42 <pjones> (hi)
18:05:14 <mitr> I think it would make sense to discuss #1243 (KDE release blocking) and #1265 (Fedora Plasma) together, and closer to the end to make sure other things get done.  Any objections?
18:05:18 <sgallagh> mitr: Ack on dropping the schedule piece
18:05:22 <pjones> mitr: yep
18:05:30 <mitr> #topic #1253 requesting exception for linking cscppc and cswrap with glibc-static
18:05:31 <dgilmore> mitr: that is fine
18:05:32 <mitr> .fesco 1253
18:05:33 <zodbot> mitr: #1253 (requesting exception for linking cscppc and cswrap with glibc-static) – FESCo - https://fedorahosted.org/fesco/ticket/1253
18:05:34 <pjones> mitr: by which I mean I agree
18:05:34 <mitr> https://fedorahosted.org/fesco/ticket/1253
18:05:45 * pjones is (still/again) +1 to the exception
18:06:01 <mitr> +1
18:06:11 <nirik> The use cases still seem weird to me, but I guess I can be +1
18:06:21 <dgilmore> im not opposed to teh exception, but its really trivial to not need it
18:06:23 <t8m> +1 as I said in the ticket
18:06:45 <t8m> dgilmore, I don't think it is so trivial
18:06:47 <nirik> requestor isn't around are they?
18:06:55 <dgilmore> t8m: it really is
18:06:57 * kdudka is here
18:06:57 <nirik> kdudka: you around?
18:07:36 <kdudka> as I already summarized in the ticket, it is hard to make it work for mock profiles that are not under our control
18:07:44 <nirik> kdudka: so the case you need static for is: rhel5 mock chroot where you don't want to get the package from epel? or some rpm based mock chroot thats not rhel or fedora? or ?
18:07:47 <sgallagh> I'm 0 for this vote, primarily because I don't trust that I understand the problem well enough to rule on it
18:08:19 <dgilmore> kdudka: not true.
18:08:27 <kdudka> nirik, yes, rhel-5 mock profile is one of the cases where it would cause problems
18:08:46 <nirik> why? download epel5 rpm, mock --copy-in ?
18:08:55 <t8m> dgilmore, can you be more verbose?
18:08:57 <nirik> which is what you would do with the static one anyhow?
18:09:17 <dgilmore> kdudka: theres no such thing as a rhel-5 profile.  but given someone made one up. you can trivially  inject a repo that provides the metadata pointing to epel as the source
18:09:32 <kdudka> nirik, how would csmock figure out that epel5 yum repo provides working binaries for the chroot that _user_ selected?
18:10:05 <dgilmore> kdudka: where the metadata just includes the rpms needed
18:10:11 <kdudka> dgilmore, you mean me as a user, or me as a developer of csmock?
18:10:20 <dgilmore> kdudka: either
18:10:45 <pjones> I don't think the developer of csmock is in the position to do that (since by definition he's not the one with the mock repo it's trying to be used in)
18:10:58 <kdudka> dgilmore, I am saying there is no fully automatic solution I would know of to download the appropriate binary RPMs for a mock profile of user's choice
18:10:59 <t8m> to me it seems clear that the triviality of this trivial solution is fairly non-trivial otherwise it would be trivial to understand it :)
18:11:05 <nirik> kdudka: well, you could document that you need epel enabled for rhel mock chroots? (there's no rhel mock configs by default btw, they point to centos and have epel enabled)
18:11:19 <pjones> dgilmore: as for the user, your argument is that finding all the right packages, createrepo, and then providing that repo to mock is "trivial".  It seems a lot less trivial than just running the thing.
18:11:27 <dgilmore> pjones: i disagree, as I said I am not opposed, I just think its really not needed
18:11:28 <pjones> t8m: indeed
18:11:36 <kdudka> nirik, this just shifts the responsibility to the user, does not it?
18:11:40 <mitr> nirik: That makes it even more difficutl to recognize builds against el5, doesn't it?
18:11:42 <Kevin_Kofler> As I pointed out in the ticket, it would just work for our mock profiles, why is that not good enough?
18:11:57 <pjones> dgilmore: it would be interesting if your disagreement included more words than "I disagree", such as the actual disagreement... ;)
18:11:59 <nirik> mitr: not sure what you mean?
18:12:05 <Kevin_Kofler> (it = shipping the binaries properly in EPEL instead of dropping them in statically-linked)
18:12:20 <mitr> nirik: If there is no standard RHEL5 repo, how would the caller of mock know to add epel _5_?
18:12:29 <nirik> kdudka: well, if a user makes a custom mock config, wouldn't it be their responsibility?
18:12:46 <nirik> mitr: there are mock configs with epel5.
18:12:50 <dgilmore> pjones: detecting that your on rhel and adding a repo to the chroot is simple to do
18:13:06 <mitr> nirik: How does that help determining whether to use epel 5 or epel 6?
18:13:10 <nirik> there's not any for rhel5, because... rhn/subscriptions.
18:13:11 <pjones> sure, but what repo?  hosted where?
18:13:29 <dgilmore> pjones: as is to use mock with rhel without epel is not trivial
18:13:35 <t8m> it really seems to me this is an exercise of how to be as pure as possibe in expense of making life of an user harder
18:13:36 <kdudka> nirik, the solution with statically linked tiny compiler wrappers works out-of-the-box, no matter what configuration the user comes with
18:13:38 <nirik> mitr: if you make a custom mock.cfg wouldn't you know that as the user?
18:13:50 <sgallagh> nirik: One of the places where hopefully the CentOS/RHT merge will help things
18:14:01 <mitr> nirik: yes, but then it's no longer automatic
18:14:01 <dgilmore> pjones: as the rhel comps doesnt include buildsys-build, so to get the minimal buildroot involves some manual intervestion
18:14:20 * abadger1999 thinks he's -1 right now.  it sounds like it just works on fedora and epel which are the projects we build and support.
18:14:25 <pjones> nirik: seems like making it three things instead of two that we're concerned about doesn't make it /less/ simple, but in any case I think we can agree we don't understand the ramifications of that yet?
18:14:36 <dgilmore> I think that the people setting up such environments can setup things so that the few packages they want outside rhel are available
18:14:48 <t8m> abadger1999, maybe it sounds "it just works" but apparently it does not really
18:15:01 <mitr> So we are at +4-1  0x1.  Other votes?
18:15:08 <dgilmore> 0
18:15:17 <abadger1999> t8m: right.. I could be convinced.. but I'd have to know what I'm missing.
18:15:21 <notting> i'm +1 to the exception - don't see why pushing making it work down to the user makes sense
18:15:38 <nirik> it seems to me like it's pandering to corner cases... but I agree it shouldn't be too harmfull to allow it.
18:15:39 <t8m> and why shouldn't the tool support any third party mock configs which do not want to ship the binaries work<
18:15:55 <mattdm> yeah, that last thing nirik said :)
18:15:59 <mattdm> so... I guess +1
18:16:11 <dgilmore> nirik: its completely pandering to corner cases where you have to go out of your way to make them work today
18:16:12 <abadger1999> Where's csmock coming from?  epel and fedora repos?
18:16:12 <pjones> nirik: "pandering to corner cases" is a fair analogy for "why exceptions exist"
18:16:21 <pjones> abadger1999: yes
18:16:23 <mitr> #agreed Static linking exception for cscppc and cswrap approved (+6-1 0x2)
18:16:32 <nirik> so, they would have at least have those repos for csmock
18:16:39 <abadger1999> <nod>
18:16:46 <mitr> This wasn't on the agenda, but since we have updates:
18:16:47 <nirik> but on the host only
18:16:48 <mitr> #topic #1221 Product working group activity reports
18:16:50 <mitr> .fesco 1221
18:16:52 <mitr> https://fedorahosted.org/fesco/ticket/1221
18:16:52 <zodbot> mitr: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
18:16:54 <mitr> Is there anything we want to discuss this week?
18:16:58 <kdudka> abadger1999, csmock is now going to fedora and already has fedora-review+, it is now waiting for cscppc and cswrap to be approved
18:17:30 * kdudka thanks to all who voted!
18:17:41 <sgallagh> mitr: Perhaps a general reminder to get Changes filed ASAP?
18:18:23 <mitr> #info Please file Changes (Product-related and others) ASAP, proposal submission deadline is on April 8th.
18:18:56 <mitr> If nothing else...
18:19:05 <mitr> #topic #1250 F21 Self Contained Changes
18:19:07 <mitr> .fesco 1250
18:19:08 <zodbot> mitr: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250
18:19:09 <mitr> https://fedorahosted.org/fesco/ticket/1250
18:19:11 <mitr> There's only one, Security Policy In The Installer - https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller
18:19:30 <jreznik> and it was somehow hot topic in the devel list...
18:19:47 <notting> i'm -1 to this, for reasons explained on the devel list
18:20:10 <sgallagh> I'm -1 on the grounds that I don't think it's possible to sanely represent this to a user in the installer
18:20:21 <mattdm> I am -1 to the proposal with a gui. i think it's fine/good in kickstart
18:20:29 <sgallagh> Where "sanely" means "without scaring them off or getting incorrect results"
18:20:35 * pjones also -1
18:20:38 <nirik> yeah, I think it's good for ks, but as presented not good for the gui installer. -1
18:20:43 <mitr> I think it would be useful to have in kickstart.  As for the GUI—I see useful use cases, but not policies that can be shipped within the distribution (organization-specific ones)
18:21:04 <dgilmore> im -1 I do think its a good thing to be set in a ks but not in the gui by default
18:21:05 <notting> i am fine with it being available in kickstart, though
18:21:20 <t8m> -1 as well for the same reasons
18:21:25 <pjones> mitr: AFAICS it's entirely possible to do this in kickstart without anaconda/pykickstart really being involved
18:21:29 <abadger1999> for people submitting similar Changes in the future -- if this affects the default configuration of the installed system it should probably be a system wide change.
18:21:44 <dgilmore> id be okay with it in the gui if triggered by adding a flag to the boot line
18:21:46 <pingou> +#info abadger1999 ?
18:21:47 <abadger1999> I agree with mattdm's split of kickstart vs gui
18:21:47 <mitr> pjones: There is a little interaction with anaconda features (partitioning, password policy)
18:21:54 <pjones> mitr: through %packages choices and %post, that is.  which I realize /somewhat/ defeats the purpose.
18:21:55 <abadger1999> So -1 overall, +1 to just kickstart
18:22:03 <dgilmore> abadger1999: I was thinking its really a system wide change
18:22:18 <pjones> my point being the place to best do this would be in things like ansible and puppet that generate kickstarts.
18:22:30 <mattdm> # for people submitting similar Changes in the future -- if this affects the default configuration of the installed system it should probably be a system wide
18:22:33 <mattdm> gahl
18:22:36 <sgallagh> If kickstart-only is a counter-proposal, I'm +1 to that (provided of course that it is a non-mandatory option and the defaults match what we have today)
18:22:37 <mitr> pjones: that is reasonable
18:22:38 <mattdm> #info for people submitting similar Changes in the future -- if this affects the default configuration of the installed system it should probably be a system wide change
18:22:47 <jreznik> in this case it probably does not make sense to change it to system wide as it was clear, it would not pass
18:23:14 <mitr> #agreed Security Policy In The Installer  was not accepted (-7)
18:23:32 <mitr> Do we want to separately vote on kickstart now, or leave this up to the owners to re-propose if they want to do it?
18:23:49 <sgallagh> mitr: I'd suggest sending a recommendation that they re-file as kickstart-only
18:23:52 <nirik> I'd say ask them to repropose since there is time?
18:23:56 <abadger1999> <nod>
18:24:08 <mitr> #info Please consider re-proposing as a kickstart-only feature
18:24:19 <sgallagh> Noting that there is reasonably-strong likelihood of that passing
18:24:22 <mitr> #topic #1262 F21 System Wide Change: Modular Kernel Packaging for Cloud - https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
18:24:24 <mitr> .fesco 1262
18:24:25 <zodbot> mitr: #1262 (F21 System Wide Change: Modular Kernel Packaging for Cloud - https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud) – FESCo - https://fedorahosted.org/fesco/ticket/1262
18:24:26 <mitr> https://fedorahosted.org/fesco/ticket/1262
18:24:31 <mattdm> +1 yaya
18:24:34 <mattdm> yay
18:24:37 <mattdm> not yaya.
18:24:58 <nirik> this doesn't seem worth it to me, but given kernel folks have already done the work and such, +1
18:25:03 <sgallagh> +1 to modularization
18:25:09 <notting> *shrug* +1
18:25:10 <mitr> +1
18:25:11 <jwb> i'll note this still needs to be reviewed by more kernel peoples
18:25:18 <pjones> I was about to say what jwb said
18:25:21 <t8m> +1 if kernel folks are OK
18:25:22 <abadger1999> +1
18:25:29 <pjones> I'm vaguely for it, but I'd like more kernel weigh-in.
18:25:36 <mattdm> also thanks to jwb for the work.
18:25:48 <dgilmore> +1 seems there might be a lot of corner cases we could hit with different arches and standard hardware that are masked today
18:25:50 <jwb> so far it's me doing the work, and zickus has helpfully reviewed without any major objections
18:26:07 <jwb> dgilmore, the content list is per-arch
18:26:26 <mitr> #agreed Modular Kernel Packaging for Cloud approved (+7)
18:26:32 <dgilmore> jwb: okay, I remeber that there was some contention over some things
18:26:38 <dgilmore> jwb: if thats changed great
18:26:41 <mitr> #1263 F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs
18:26:43 <mitr> .fesco 1263
18:26:44 <zodbot> mitr: #1263 (F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs) – FESCo - https://fedorahosted.org/fesco/ticket/1263
18:26:45 <mitr> https://fedorahosted.org/fesco/ticket/1263
18:26:51 <dgilmore> jwb: it can all be resolved somehow :)
18:27:52 <sgallagh> I might be wrong, but this feels more like an FPC-level decision
18:28:18 <mattdm> proposal: send to fpc with a recommendation in favor
18:28:26 <sgallagh> And in general, I'd rather we had a better way for RPM/yum/dnf to avoid installing %docs and allow adding them later
18:28:44 <mattdm> i think the reason for the change is to make sure it gets in the release notes
18:28:46 <sgallagh> But that's obviously a larger problem
18:28:50 <tibbs> I think this is more about problems with actually building the javadocs.
18:29:12 <tibbs> But if it came to FPC, I'd probably support it from my quick reading of the proposal.
18:29:35 * abadger1999 puts on FPC hat and echoes tibbs' sentiment
18:29:42 <notting> i'm tentatively OK with it. would be great to talk to real-world java devs on whether they use the ones we build anyway
18:29:44 <jreznik> btw. take a look on discussion on Java 8 - maybe they will be able to solve it by config option in Java 8
18:29:46 <nirik> yeah, java8 is a lot more strict on javadocs.
18:29:54 <mitr> sgallagh: It's not pure packaging, javadocs going away is fairly user-visible.  We have sufficient precedent for Changes that have a packaging guideline modification as an essential component.
18:30:07 <sgallagh> mitr: Fair point
18:30:17 <abadger1999> mattdm: I agree that a Change is good so that it gets release noted.
18:30:35 <t8m> so I am +1 anyway
18:30:52 <mitr> #topic 1263 F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs
18:30:54 * nirik is +1
18:30:56 <sgallagh> +1, but I'd still like it to go to FPC, at least for the guideline changes
18:31:13 <mattdm> so, okay, +1 with same basic caveats
18:31:20 <mitr> The owners have already committed to update the packaging guidelines in the Scope sesction
18:31:28 <mitr> +1
18:32:00 * pjones +1 as well
18:32:03 <t8m> +1 to the change again, and +1 to forwarding to FPC for guideline changes
18:32:06 <dgilmore> +1 to the change assuming that the FPC approves the needed packaging guidelines
18:32:06 <abadger1999> So +1 -- if FPC doesn't pass the new guidelien then contingency plan would be invoked (which accoring to the change page is "just don't perform package changes")
18:32:19 * mattdm nods
18:32:20 <sgallagh> abadger1999: ack
18:32:25 <mitr> #agreed Optional Javadocs change approved (+8)
18:32:35 <mitr> #topic 1264 F21 System Wide Change: Ruby on Rails 4.1
18:32:37 <mitr> .fesco 1264
18:32:38 <zodbot> mitr: #1264 (F21 System Wide Change: Ruby on Rails 4.1 - https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.1) – FESCo - https://fedorahosted.org/fesco/ticket/1264
18:32:39 <mitr> https://fedorahosted.org/fesco/ticket/1264
18:33:09 <mitr> +1
18:33:11 <sgallagh> +1 rubber stamp
18:33:14 <dgilmore> +1
18:33:19 <nirik> sure, +1
18:33:20 <pjones> +1
18:33:40 <t8m> +1
18:33:44 <mattdm> +1
18:33:47 <sgallagh> Looks like this will require scheduling a mass rebuild?
18:33:48 <notting> +1. although would love to know how much always-latest rails affects developer uptake on Fedora rails vs. rubygems.org rails
18:34:06 <sgallagh> Or a side-tag? (Unclear to me)
18:34:12 <mattdm> notting as far as I can tell, "severely".
18:34:18 <abadger1999> +1
18:34:21 <dgilmore> sgallagh: i suspect that we will soon have a system wide mass rebuild that we need to plan
18:34:34 <mitr> notting: or how much never-latest rails would affect it... We really need many versions I guess.
18:34:41 <mitr> #agreed Ruby on Rails 4.1 approved (+9)
18:34:43 <sgallagh> dgilmore: Sure, but I'm not clear on whether a trivial rebuild will work or if all packages will need tweaks
18:34:51 <mattdm> but to do anything else we need a strong commitment from someone to maintain the older stacks
18:35:03 <sgallagh> It's not really my problem to solve, except making sure that a mass rebuild is coordinated with any others we need to do
18:35:07 <mitr> sgallagh: Rails incompatibilties tend to be source-level
18:35:10 <pjones> mitr: we really do, yes
18:35:45 <mitr> #topic 1265 Fedora Plasma Product
18:35:47 <mitr> .fesco 1265
18:35:48 <zodbot> mitr: #1265 (Fedora Plasma Product) – FESCo - https://fedorahosted.org/fesco/ticket/1265
18:35:49 <dgilmore> sgallagh: usually something like a ruby on rails bump etc is a build done in a side tag
18:35:49 <mitr> https://fedorahosted.org/fesco/ticket/1265
18:36:40 <jwb> (HINT STILL NEED TO FILE BOARD TICKET)
18:36:55 <mattdm> jwb hint taken -- was planning to talk about that... now
18:37:07 <dgilmore> I think there is little to discuss here until the board says okay
18:37:07 <jreznik> jwb: before fesco discussion or after? I wasn't sure from the FESCo ticket
18:37:08 <mattdm> We should discuss this and then file a board ticket.
18:37:10 <dgilmore> but I could be wrong
18:37:36 <pjones> I'm still against adding more products before we know if this product thing is even working.
18:37:41 <jwb> jreznik, imo they can be done in parallel.  i would prefer fesco to discuss it first from a technical point of view though
18:37:42 <sgallagh> dgilmore: The valid point was made in the ticket that the other three Products went to the Board as FESCo recommendations
18:37:54 <sgallagh> It seems only fair to do the same for Plasma
18:37:59 <dgilmore> sgallagh: fair enough
18:38:04 <nirik> so, my worry here is that it's not that different from the workstation product, and we will be back to giving peopel a list of things they don't know what to choose from.
18:38:20 <notting> nirik: as stated in the ticket, the name doesn't help with that
18:38:21 <mattdm> nirik yes, I have the exact same concern.
18:38:30 <mattdm> #insert stuff I said in ticket
18:38:47 <nirik> right.
18:38:52 <ltinkl> notting: so your worry is mainly about the name, or the contents?
18:39:00 * Kevin_Kofler does not understand why people hate choice that much…
18:39:07 <sgallagh> There's certainly some overlap, but I think there's also a pretty clear space outside of it
18:39:11 <t8m> I don't have problem with the name but the product purpose differentiation from the Workstation is crucial
18:39:38 <ltinkl> it's written clearly in the mission statements
18:39:40 * abadger1999 is +1 for the KDE product.  also agrees with pjones's desire to maybe push new product decision to F22 even though he wants there to be a KDE Product then.
18:39:49 <sgallagh> I really like the idea of a Fedora Product targeting the Scientific/Educational constituency
18:39:58 <abadger1999> But with that in mind, I'd also want the KDE spin in F21 to be release blocking.
18:40:01 <ltinkl> we target a completely different audience
18:40:02 <t8m> sgallagh, +1 me too
18:40:08 <nirik> picture yourself as not a linux savvy person. You want to try out this fedora thing you have heard about, you go to the site and get asked if you want 'server' or 'cloud' or 'workstation' ok, those are use cases, you want a workstation. If you are asked then 'gnome' or 'kde', you go... what?
18:40:10 <sgallagh> Particularly because we have a *very* popular downstream distribution that will benefit directly from this as well (Scientific Linux)
18:40:14 <Kevin_Kofler> sgallagh: And KDE Plasma is a great platform for that because of all the work done by the kdeedu team.
18:40:22 <rdieter> ltinkl: not completely, both mention developers, but largely true
18:40:24 <notting> ltinkl: that was just the initial impression, haven't read the full spec yet. just that if we're naming the products by what you do with them, you don't install a machine as a 'plasma'
18:40:26 <jwb> abadger1999, i... don't think pjones actually said to push products to f22
18:40:38 <dgilmore> sgallagh: we are a pretty popular KDE developer distribution
18:40:43 <ltinkl> the Workstation is mainly aimed at developers, we focus on scientists/teachers/students, generally power users
18:40:55 <abadger1999> jwb: true... he didn't put a timeline on it.  F22 was my interpretation of the soonest we'd know if it was working.
18:40:56 <Kevin_Kofler> That alone already covers things at all ages from little children (e.g. KTuberling) up to the practicing scientist (e.g. Cantor).
18:41:01 <dgilmore> sgallagh: as in upstream folks run fedora
18:41:05 <notting> i... don't know that the SL people are a crossover with the kdeedu people
18:41:12 <rdieter> ltinkl: oh, and both mention students
18:41:22 <Kevin_Kofler> Then there are the other KDE and Qt science and education apps listed on the PRD.
18:41:26 <pjones> abadger1999: I think I'm behind that interpretation, though it is yours not mine ;)
18:41:33 <ltinkl> Plasma is just a fancy name, we thought it nicely links the "science" aspect with the underlying technology
18:41:46 <sgallagh> dgilmore: Right, I didn't mean to suggest otherwise, but focusing on a *technology* doesn't make a product in my mind.
18:42:01 <sgallagh> But addressing a pristine problem space certainly does
18:42:03 <Kevin_Kofler> rdieter: But we actually give students app to do serious work with, Workstation focuses on the full-time-gaming student. ^^
18:42:20 <Kevin_Kofler> *apps
18:42:38 <sgallagh> Kevin_Kofler: I think that's an oversimplification, but as I said I like the focus
18:42:49 <mattdm> I still have the worry that the main basis for the proposal is fear that Fedora KDE will not be treated well if it does not somehow get product status, and that's the _initial_ reason with scientific/education retrofited
18:43:09 <mattdm> that is, this *didn't* come out of the scitech sig -- why not?
18:43:36 <sgallagh> mattdm: Well, the SciTech SIG and KDE SIG have most of the same members, last I checked
18:43:37 * nirik will be right back
18:43:47 <Kevin_Kofler> nirik: I'm a bit fed up of that "If you are asked then 'gnome' or 'kde', you go... what?" argument. Many other distros give their users exactly this choice and don't have any problem with that. But there are other differentiating factors anyway.
18:43:59 <mattdm> And the logical step is -- if that is the real worry, can we solve that in a different way?
18:44:10 <dgilmore> mattdm: I think that upstream support, broad user support, overall popularity of KDE we should have a KDE based product
18:44:35 * abadger1999 notes that he does not agree with mattdm and nirik's desire that new products be Use-case dependent.  So is probably not going to say useful things that relate to evaluating a new Product on that basis.
18:44:41 <sgallagh> I think with the product distinction, we can ask people "Do you want a general-purpose workstation" or "A higher-education and scientific platform"
18:44:45 <ltinkl> mattdm: agree with dgilmore there, KDE is the single most popular desktop environment, and should get the same treatment
18:44:51 <mitr> dgilmore: "with the upstream support and overall popularity we should have a C++-based product"
18:44:52 <mattdm> dgilmore I think that those things are excellent reasons for having a KDE *spin*
18:44:57 <ltinkl> if we are to attract actually more users/developers
18:45:20 <dgilmore> mattdm: we can agree to disagree
18:45:35 <nirik> Kevin_Kofler: I'm not convinced by 'other distros do it' either. ;)
18:45:36 <notting> mitr: nah, if we're going by upstream usage popularity we should have a java/ruby/objc based product
18:45:37 <rdieter> mattdm: to be honest, the lack of inclusion of qt/kde runtime bits into workstation tech specs so far is one motivation (for me at least).  I'm still working on improving that (hopefully)
18:45:41 <mattdm> dgilmore yes; I think you are basically agreeing with abadger1999 :)
18:45:44 <mitr> notting: of course :)
18:45:49 <nirik> abadger1999: how then do we present them?
18:45:53 <rdieter> mattdm: (then desktop shells is another of course)
18:45:59 <mitr> mattdm: I was thinking spin as well, but then if there really are 11 people willing to sign up working on a product, that's not to be taken lightly
18:46:05 <jwb> ltinkl, rdieter: is the KDE SIG still willing to work with Workstation on making KDE a block desktop in the manner Workstation is persuing?
18:46:17 <abadger1999> nirik: If you mean market them, then the main thing is we stop marketing "Fedora" as a Product.
18:46:22 <mattdm> mitr agreed, that is absolutely also important.
18:46:28 <abadger1999> nirik: We start marketing the individul Products as products.
18:46:29 <pjones> mitr: I'm still thinking "spin for F21, see how products go, and possibly promote it to a product for F22" frame of mind
18:46:38 <nirik> abadger1999: so, we say: here's a list of desktops, try them all and use the one you like best?
18:46:39 <rdieter> jwb: I think so (not sure exactly what "in the manner Workstation is persuing" means, but it's probably ok)
18:46:50 <ltinkl> jwb: sure, and this will be also reinforced (internally in RH) by something I can't quite speak in public yet :)
18:46:54 <abadger1999> nirik: We said that the Fedora Project might be more like apache's incubator project in the future.
18:46:54 <pjones> because TBH I think we're only barely going to have products figured out enough to do them for F21 as is, and complicating it further /during/ that is not a particularly stellar plan.
18:47:09 <mattdm> I also agree with pjones here
18:47:23 <Kevin_Kofler> jwb: Last I checked, what Workstation was persuing was to let just some KDE applications running under GNOME be blocking. That's clearly not enough.
18:47:24 <abadger1999> nirik: If you model after them, then they don't emphasis "incubator" as a Solution for end users.
18:47:35 <t8m> pjones, I could be +1 to that
18:47:35 <jwb> rdieter, gdm is the login manager, you install KDE through software-installer
18:47:37 <abadger1999> incubator is the brand for what they want people creating Products to use.
18:47:39 <jwb> rdieter, to get to the short of it
18:47:48 <Kevin_Kofler> Surely they won't even treat our display manager (SDDM or the old KDM) as blocking, will they?
18:47:48 <nirik> abadger1999: I guess, but what does apache do with things that overlap? ie, if they had apache and another httpd came along would they accept it?
18:47:51 <pjones> And right now, though the plan here is pretty good, how it works with everything else seems to mostly still be hand-waving.
18:47:51 <abadger1999> The individual Products have their own identity that they market to end users.
18:47:57 <abadger1999> nirik: yes.
18:48:14 <rdieter> jwb: yeah, pretty sure thats not good enough to satisfy a majority of our group
18:48:17 <abadger1999> nirik: I don't think they have a competing web server but they have had things like competing search solutions.
18:48:28 <notting> abadger1999: if we're doing that, i prefer going the ubuntu/kubuntu/whatever route, to the point of potentially even separate repos
18:48:38 <jwb> rdieter, satisfy in what way?  i asked if you're willing to work with Workstation on that
18:49:01 <rdieter> jwb: the details matter.  and it's not just *me* you have to satisfy
18:49:08 <abadger1999> notting: I think I agree with you.
18:49:27 <nirik> seperate repos would be a big nightmare. ;)
18:49:27 <abadger1999> notting: I kinda hope we could have a main repo and a repo that overlays it with things that are replacements.
18:49:38 <ltinkl> separate repos... oh pls not
18:49:42 <abadger1999> notting: rather than full disjoint repos.
18:49:46 <jwb> rdieter, yes, i understand.  i'm trying to figure out whether the creation of a KDE Plasma Product means the entire KDE community abandons Workstation entirely, or whether there is still cooperation possible
18:49:47 <mitr> pjones: So one option would be a "provisional product" status for F21, shipping as a "spin" for F21, but expecting to see the product-like development for specific end- user cases, and then deciding on product status for F22 based on whether ssuch product-specific development happened?  But that is rather close to just kicking the can down 9 months
18:50:04 <ltinkl> jwb: no, not abandoning at all
18:50:07 <pjones> mitr: I think that's just rewording what I said, mostly?
18:50:11 <abadger1999> but I think we're going to eventually have packages that must differ between the products so we'll have to solve it somehow anyway.
18:50:14 <jwb> ltinkl, ok.  that's great to hear
18:50:17 <pjones> mitr: I mean, it doesn't answer the question: what does it look like on the web page?
18:50:32 <rdieter> jwb: speaking for myself, I'm committed to continued cooperation with workstation.
18:50:36 <Kevin_Kofler> jwb: I'm personally not interested in having anything to do with Workstation, but that's just me.
18:50:39 <mattdm> jwb the PRD does talk about cooperation with workstation wg
18:50:42 <pjones> mitr: but, I mean, I'm not opposed to other isomorphic plans that are worded more friendly ;)
18:50:45 <jwb> rdieter, excellent, thank you
18:50:49 <jwb> mattdm, i missed that!
18:51:01 <jwb> i will have to re-read
18:51:02 <notting> abadger1999: but that also means cloud/server/workstation get their own brand/separate web sites. so maybe you don't ever 'go to a web page to pick one'
18:51:39 <ltinkl> one page with the Products Overview (or Showcase) would be nice
18:51:54 <ltinkl> then separate pages where the individual products present themselves
18:51:58 <Kevin_Kofler> Oh, and if popularity is of interest to you:
18:52:09 <Kevin_Kofler> http://www.linuxquestions.org/questions/2013-linuxquestions-org-members-choice-awards-109/desktop-environment-of-the-year-4175488210/ 2013 LinuxQuestions.org Members Choice Awards (Dec 2013 - Feb 2014): KDE Plasma 35.77%, Xfce 25.77%, GNOME 9.86%
18:52:11 <mjg59> whois fedoraworkstation.org
18:52:15 <mjg59> NOT FOUND
18:52:17 <rdieter> Kevin_Kofler: I doubt it
18:52:20 <Kevin_Kofler> http://www.linux-magazin.de/NEWS/Cebit-2014-KDE-Tor-Bitcoin-und-Git-gewinnen-Preise Linux New Media Awards 2014 (German) (Jan 2014 - Mar 2014): KDE Plasma 46%, GNOME 18%, Xfce 13%
18:52:24 <mitr> pjones: I was thinking this would give specific criteria ("if you want to be called a product, behave like one") ... and seeing such behavior should also help with the question of "what does this do differently so, what do we put on the web page"
18:52:32 * dgilmore needs to run. will be back hopefully before the end
18:53:25 <pjones> mitr: that might be a fair point.
18:53:56 <mitr> pjones: OTOH we have not actually placed such requirements on the first three products (though we strongly expect they will deliver)
18:54:21 <abadger1999> notting: Correct.  We want to avoid the "go to web page to pick one" in this scenario.
18:54:36 <pjones> mitr: I'm not going to sit here and argue that things would be different had the path to be here been different.  Of course it would have, but that's not what happened.
18:54:52 <abadger1999> notting: instead, people promote the Product(s) that they're interested in.
18:55:19 <Kevin_Kofler> That's what we've already been doing with http://kde.fedoraproject.org/
18:55:38 <nirik> abadger1999: downside is that people would have no central place like they are used to, so some might just wander off... (which may be fine, but worth noting)
18:55:43 <pjones> abadger1999: that seems to reduce to having a web page that doesn't help you figure out how to download our software? ;)
18:55:46 <mitr> abadger1999: I don't think that's a practical difference.  fedoraproject.org still needs to list all of them, we can't so easily have 3-6 times the number of press releases and release dates, etc.  We will be forced to offer a "menu" of current products in any case.
18:56:23 <sgallagh> Folks who have reservations about this becoming a Product: What should the proposers add or change to make it more palatable? (Let's try taking a positive approach here, rather than listing issues)
18:56:45 <abadger1999> nirik: True in the sense that we no longer have 1 Fedora that we're tryign to get people to install... but isn't that part of the Fedora Productsanyways?
18:57:01 <abadger1999> pjones: Different viewpoint I think.
18:57:03 <nirik> not entirely, if we have spins still.
18:57:34 <mitr> sgallagh: I'm not sure we all actually think of Products the same way.  Based on _my_ understanding:  So, this is the Scientific/Education spin: what activities does the WG plan to improve the Scientific/Education use case, beyond shipping an ISO of packages that already exist upstream?
18:57:37 <abadger1999> pjones: I'm reading what you're saying as We no longer have a website that helps people download Fedora.
18:57:51 <abadger1999> pjones: But I think in the Product world, we don't really have a "Fedora" anymore.
18:58:18 <abadger1999> pjones: We have something called "Workstation", something called "Cloud" and somthing called "Server".
18:58:28 <jwb> and we have spins
18:58:32 <abadger1999> pjones: We most certainly should have websites that help users download those.
18:59:10 <abadger1999> pjones: We just stop conflating fedora-the-incubator-for-these-products with the products themselves.
18:59:13 <sgallagh> abadger1999: We will still have the non-Product Fedora bucket-o-bits as well that can be used for spins and remixes
18:59:30 <mattdm> sgallagh +1
18:59:43 <mitr> We are well over 15 minutes, shall we continue?
19:00:04 <abadger1999> mitr: I think what I'm getting at with pjones is the same for your comment.  As we move further down a Product path, we'd have less product-oriented Fedora press releases, etc.
19:00:11 <sgallagh> mitr: +1 to continue (I think this is an important topic)
19:00:15 <pjones> abadger1999: but if people go to www.fedoraproject.org and can't figure out either a) which thing they want or b) how to get it, then we're in 1997 again and we may as well tell people to go to Book Barn and get a CD out the back of a 300 page book about writing modelines in X86Config, for all the good it's going to do them.
19:00:30 <mattdm> +1 to continue
19:00:39 <t8m> +1 to continue as well
19:00:47 <pjones> XF86Config even ;)
19:00:54 <mattdm> *bookbarn giggle*
19:01:00 <abadger1999> pjones: the question is why are people going to fedoraproject.org to find a product to download?  Do we want to continue to have them do that?
19:01:13 <ltinkl> pjones: isn't that a job better suited for people actually doing/designing the web? :)
19:01:23 <abadger1999> pjones: Do you go to incubator.apache.org in order to download software that makes search engines?
19:01:28 * jreznik (personally) would be ok with blocking spin for f21 as incubation for full featured product in f22 timeframe
19:01:32 <ltinkl> pjones: you can have 30 products and still present it in a sane and attractive way
19:01:42 <mattdm> entering into the record: the current mockup for new getfedora web site
19:01:44 <mattdm> http://ryanlerch.fedorapeople.org/getfedora/
19:01:53 <abadger1999> pjones: or do you go to the website for the product that they provide the hosting and infratructure for that actually does that thing.
19:01:55 <t8m> I am not really sure we have to solve the problem of single all-product page vs. separate pages here
19:02:14 <jreznik> well, I'd say - let's have that three main generic products on the main page and bellow it - hey, we have use case specific products... no hiding is needed
19:02:25 <pjones> abadger1999: no, but clearly somebody does?  Also that website is terrible, and their model is so good you had to explain it to everybody here.
19:03:17 <jwb> mattdm, cloud wasn't important enough to make the mockup.  HAHA
19:03:18 <abadger1999> pjones: Right -- incubator.apache.org is not what you'd want to use to market the Products.  It's use is to market the incubator service to people who want to make Products.
19:03:22 <notting> sgallagh: as for the submitters? not sure. but we have 'Fedora' that has decided we need to focus in specific areas in order to progress, 'Fedora' that has clamored for the same spins as always in order to move forward, 'Fedora' that has advocated for the same big pile'o'bits repo as what's needed, and 'Fedora' that has stated what we need is multiple products that are 80-90% overlapping because they don't like the base technology project of the
19:03:22 <notting> proposed one and prefer something different. as long as all these 'Fedoras' exist, how *do* you progress?
19:03:37 <pjones> abadger1999: and that's ignoring the actual point (which ltinkl has also ignored), which is that I'm still not convinced we have enough time from now to F21 release to figure all this stuff out as is, much less /changing/ it again.
19:03:50 <abadger1999> pjones: and htat's what I'm saying the direction is that we're driving the fedora project in.  So we have to figure out how to adapt our assets to meet that.
19:03:51 <mattdm> jwb :)
19:04:09 <abadger1999> pjones: On that count, I'm more than willing to +1 you.
19:04:11 <rdieter> jreznik: +1 (pragmatic)
19:04:20 * rdieter has to go pick up kids from school
19:04:33 * Kevin_Kofler doesn't like that mockup, it just does not scale.
19:04:34 <jreznik> pjones: as I said - we are ok being pragmatic and stay blocking spin by F22
19:04:49 <pjones> mitr: okay, let's try to make some proposal based on what you and I were saying earlier?  Because people appear to vaguely for it in various ways
19:04:54 <jreznik> even ltinkl is as far as I know
19:04:58 <abadger1999> pjones: We should maybe propose to put off KDE Plasma as a Product until F22 planning and move onto how we treat the KDE spin for F21.
19:05:02 <Kevin_Kofler> Designing the mockup to hardcode 3 Products is a poor argument for only having those 3.
19:05:18 <mitr> pjones: wfm
19:05:38 <Kevin_Kofler> The design should be purely a vertical scrollable list, that scales to as many products as get approved, it's future-proof.
19:05:39 <pjones> abadger1999: right, so I'm vaguely for that.  But it leaves the question, which we can discuss after a vote on that, of what to do about blocker status for KDE spins.
19:06:13 * mattdm imagines an infinitely scrollable list....
19:06:19 <ltinkl> well, it's imho simple, if the Plasma product decision gets postponed for F22, the status quo stays the same (KDE spin lives on)
19:06:30 <jreznik> for blocking spin, I'd say the only question is QA and we are willing to provide workforce to help with QA (same for product)
19:06:42 <abadger1999> pjones: yeah..
19:06:45 <pjones> alright, so: Proposal: we go ahead and /broadly/ recommend to the board that they consider this product for F22, and we commit to establishing milestones for it being on target for that in the mean time.
19:07:05 <pjones> (and then we discuss F21 blocking as a separate item)
19:07:05 <mitr> pre-proposal: Plasma (not "KDE") will be considered a release-blocking spin for F21, with appropriate visibility.  Before F22, we will decide on Product status, based on product differentiation from Workstation, and specific work on features for the Engineering/Scientific community
19:07:21 <t8m> mitr, +1
19:07:36 <pjones> mitr: I can get behind that phrasing
19:07:42 <mitr> t8m:  this is a _pre_proposal because I want to hear the Plasma WG's opinion
19:07:55 <Kevin_Kofler> So what are you expecting us to do for the Engineering/Scientific community?
19:07:56 <abadger1999> +1 to those as a pair.  we need to figure out appropriate visibility before making a final decision.
19:07:57 <mattdm> mitr I can be +1 to that, although I think the web people and documentation writers would like a little more time to know which way it's going to go
19:08:00 <Kevin_Kofler> Is Fedora now about upstream development?
19:08:18 <jreznik> with some guidance on what Kevin_Kofler asked, I'll be ok with it
19:08:21 <abadger1999> err.. although we should have a vote on product differentiation.
19:08:31 <mitr> Kevin_Kofler: This is me basically saying "I'm not quite sure what the differentiation between Workstation and Plasma is, and I'd like you to show me"
19:09:05 <mitr> But this is a starting point for a discussion, to a Requirement That Has Been Imposed on You
19:09:15 <abadger1999> I mean, I'll shut up about incubator.apache.org and Products vs Project if dgilmore and I are the only ones who think that way.
19:09:18 <ltinkl> mitr: wait, wait, so you want the KDE spin renamed to Plasma spin?
19:09:50 <mitr> ltinkl: If you wanted a KDE spin in addition to a pre-Plasma-product spin, I wouldn't object; I just thought you wouldn't want to.
19:09:56 <jreznik> mitr: it's in PRD - a lot of scientific and edu stuff is mentioned there, we'd like to cover also electric engineering spin as suggested by martix etc.
19:10:10 <mitr> Kevin_Kofler: And yes, I personally think that Products are specifically focused on Fedora-led development (but that's not been a voted position of FESCo or the board)
19:10:10 <nirik> abadger1999: I could be convinced... would need to ponder on it some more.
19:10:14 <pjones> mitr: I think the SIG is telling you you had it right earlier when you said "provisional product" instead of "spin"
19:10:23 <mattdm> abadger1999 I like the idea, although I think in order to do that we should introduce tiers of incubating levels, and I think that is a next-step kind of thing
19:10:42 <Martix> jreznik: electronic engineering and robotics spins
19:10:48 <pjones> mitr: as much as I hate making new terms for categories on the fly, we do have to admit this is clearly not the traditional spin concept.
19:11:22 <mitr> pjones: naming kind of presupposes defaults for decisions—but in a strictly technical way it doesn't matter to me
19:11:25 <Martix> jreznik: but this need to be communicated with those spins first
19:11:26 <mattdm> it's basically what I said a while ago about "secondary products"
19:11:45 <mattdm> although "provisional" might be construed as more positive than 'secondary'
19:11:50 <pjones> mattdm: indeed.
19:11:54 <ltinkl> mattdm: yup
19:12:20 * mattdm mumbles something about 'probationary products', hides around corner
19:12:57 <abadger1999> provisional better as probationary can either be a probationary period on the road to promotion or on the road to demotion. :-)
19:13:26 <jwb> mattdm, you mean spins?
19:13:33 <mattdm> abadger1999 yeah I wasn't serious
19:13:40 <pjones> abadger1999: which, to be fair, isn't the worst message in the world to send.
19:13:59 <jwb> i see no point in inventing new words for spins
19:14:08 <mattdm> jwb well, as pjones says, it's something a little different.
19:14:21 <mattdm> a spin with certain aspirations.
19:14:26 <abadger1999> yeah... not all spins are desiring to become products.
19:14:32 <jwb> so's fedora.next.  just repurpose the damn word and save the websites team some work
19:14:45 <mitr> Yeah, a provisional product would probably want a FESCo liaison right now for example
19:14:49 <nirik> FWIW, (and not speaking for all the Xfce maintainers), I don't have any desire for the Xfce spin to be a 'product'. Packages available yes, spin, yes... but it's there for people who know/want it...
19:15:11 <jwb> nirik, and i don't see why the lack of product desire would mean you spin should no longer exist
19:15:16 <jreznik> mitr: rdieter volunteered to be liasson
19:15:21 <nirik> right. agree
19:15:31 <mitr> So... next steps?
19:15:51 <ltinkl> agree on something? :)
19:15:56 <pjones> I think we combine my thing and your thing together into one proposal and vote on it, and if it passes, we talk about what blocks or doesn't block in f21.
19:16:05 <mattdm> yes do that :)
19:16:06 <mitr> We seem to have a vague agreement from the FESCo side for a possible, not necessarily required, path forward.  I'm not sure about the WGs position.
19:16:09 <notting> mitr: time machine, go back to 1997 and get trolltech and miguel in a room to talk licensing
19:16:17 <pjones> I'm going to let you do that, so we don't have two things again.
19:16:19 <nirik> notting: +1 ;)
19:16:23 <pjones> notting: no kidding ;)
19:16:28 <mitr> notting: with the orbital lasers, no budget left for time machine this week
19:16:43 <t8m> :D
19:17:00 <mitr> pjones: I suppose we could get something passed; would that be OK with the WG?
19:17:21 <sgallagh> mitr: Please rephrase the proposal
19:17:42 <mitr> I'll just go ahead and:
19:17:44 <mitr> Proposal: Defer for a week for more discussion, ask all parties to try to agree on a polished proposal to vote on _before_ the next meeting.
19:18:12 <jreznik> mitr: "and specific work on features for the Engineering/Scientific community" is something I'd say Kevin_Kofler and me do not understand clearly and if you take a look on the PRD, a lot is there, libs used in this environment (Tcl/Tlk) etc. (not sure it was already added there, Kevin_Kofler suggested it)
19:18:13 <mitr> (Feel free to re-propose the provisionary product alternative, right now I'd rather give this a little more time.)
19:18:15 <abadger1999> mitr: -1
19:18:51 <abadger1999> I think we've established that's not something we're going to approve next week.
19:18:52 * nirik is ok with defering, but I think we might get to a proposal today
19:19:03 <mitr> jreznik: <mitr>: Kevin_Kofler: And yes, I personally think that Products are specifically focused on Fedora-led development (but that's not been a voted position of FESCo or the board)
19:19:04 <sgallagh> mitr: -1 please no more deferring
19:19:20 <abadger1999> at least in terms of "Here's the proposal for a Product we'd like to have for F21".
19:20:03 <jreznik> mitr: well, WS product aims more on development not of fedora but 3rd party on top of fedora
19:20:24 <mattdm> I just want to note.... I think there _is_ a broad strategic question about the number of different products and their possible overlap in scope, and I think that reasonable people have different but strong positions on that. So, I don't think it's passing the buck for FESCo to ask the board for guidance.
19:20:49 <mattdm> jreznik and developers _using_ fedora
19:21:12 <jwb> mattdm, that is an entirely reasonable question.  it is also entirely different than "hey board, should this KDE thing be a product"
19:21:20 <pjones> mattdm: and I definitely think that's the board's purview...
19:21:28 <ltinkl> mattdm: we managed to attract _many_ upstream KDE developers to Fedora lately
19:21:29 <abadger1999> Proposal: recommend to the board that they consider this product for F22, and we commit to establishing milestones for it being on target for that in the mean time.  For F21 we continue to consider the KDE Spin (or a renamed version) as release blocking.  KDE Spin will continue to have a place on the download page for the Fedora Products.
19:21:37 <jreznik> jwb: s/KDE/Plasma but I'd be ok asking Board if pure KDE product would be allowed
19:21:51 <notting> mattdm: jwb: i'd agree to some extent, although i can't off the top of my head think of a place other than 'desktops' where this sort of overlap would come up
19:21:55 <jwb> jreznik, .... that's what i was saying isn't really productive at teh Board level
19:21:58 <pjones> jreznik: please no
19:22:33 <nirik> abadger1999: not sure that last part... 'here's our 3 featured products and KDE Spin' ? or you just mean continune to be on spins.fp.o?
19:22:54 <abadger1999> nirik: So that's the piece I threw in there but we and KDE SIG need to discuss.
19:22:57 <jwb> notting, default editor spin.  postfix vs. sendmail.  kvm vs. xen for a virt product.
19:23:01 <pjones> jreznik: we've got a specific proposal.  Please either a) ask them about a higher level /concept/, like "do we really want more products and if so when/why" or ask them about this specific one.  Don't go to /would you accept a specific prd that isn't this one and also hasn't been written/.
19:23:03 <jwb> notting, you clearly are not thinking hard enough.
19:23:05 <mitr> nirik: 3 products + a spin, why not?
19:23:20 <abadger1999> ltinkl: you said, something I interpreted as roughly "KDE Spin hsould continue to get the status quo treatment".
19:23:22 <notting> jwb: i'm saying those would get dismissed out of hand. at least, i HOPE they would
19:23:46 <jwb> notting, by whom?
19:23:48 <jwb> the Board?
19:23:49 <Kevin_Kofler> mattdm: It's a bit OT, but IMHO Workstation is a very bad environment for a developer to develop on.
19:23:51 <abadger1999> ltinkl: fesco has discussed that in terms of blocking the F21 release but not about website presentation.  How do you/KDE IG feel about that changing?
19:24:12 <nirik> mitr: because then we have the problems of differentation and mixed messaging added to.
19:24:15 <mitr> Could we ... not talk HTML in this meeting?
19:24:18 <Kevin_Kofler> GNOME Shell is not configurable enough, and GTK+ is also not as nice a platform to develop for as Qt.
19:24:19 <jreznik> nirik: well just I'd like to avoid having kde spin hidden in 100 levels links on Alpha Centaury server but real visibility once it's approved product
19:24:36 <notting> jwb: saner minds, i guess.
19:24:40 <Kevin_Kofler> (and yes, I've worked with both)
19:24:43 <ltinkl> abadger1999: what jreznik said
19:24:44 <nirik> jreznik: once it's a product it should be presented liek the others. while it's a spin it should be presented like the other spins?
19:24:57 <jwb> notting, sanity is not required to participate in Fedora.
19:25:08 <jwb> (some would argue it's detrimental)
19:25:11 <notting> Kevin_Kofler: well, if when asked how your proposed product is different, you argue by saying "it's not, i just think it's better for the exact case of the existing product", that... doesn't help.
19:25:15 <jreznik> nirik: I'm ok with that but I'd like to have direct link to spins from the main product page
19:25:15 <pjones> Kevin_Kofler: sort of an entirely different discussion than the one we're actually having.
19:25:19 <abadger1999> ltinkl, jreznikSo that's what you don't want.  But what do you want?
19:25:45 <mattdm> nirik, jreznik I think we can have a special category for spins with aspirations
19:25:56 <abadger1999> Would it or would it not be okay for the F21 KDE spin to not be mentioned on get.fedoraproject.org for instance.
19:25:57 <jreznik> mattdm: works for me
19:26:10 <nirik> I personally don't object to a 'I want a big list of everything' on the main page... but thats up to websites.
19:26:18 <sgallagh> abadger1999: I'd really rather leave specific questions of websites to the websites team
19:26:19 <jreznik> abadger1999: I'd go with similar way we have now - there's GNOME spin + links to other spins
19:26:21 <ltinkl> abadger1999: presented along side with the current 3 products, as a specially purposed (aspiring) product/spin
19:26:28 <sgallagh> get.fedoraproject.org *might* conceivably go away. I'm not sure
19:26:57 * pjones goes to get another cup of tea.
19:27:23 <abadger1999> sgallagh: I think F21 is a transitional release.  And so we have to make compromises for this release.
19:27:24 <mattdm> as I understand the plan, the idea is to make the _main_ fedora website be "get fedora" for non-contributors, with a different hub for contributors and logged-in users
19:27:26 <nirik> abadger1999: I am +1 to your proposal, if we strike the last sentence. ;)
19:27:28 <jreznik> even for products I'll be ok with more prominent position for generic products and less prominent for use case products - on the same page
19:27:31 <ltinkl> otoh, I don't really think Fedora will ever get more than a couple of products, ceartainly not more than 3-5
19:28:09 <ltinkl> jreznik: ye but in that case, Cloud is a _very_ specific product :)
19:28:12 <Kevin_Kofler> I think we definitely want a link somewhere on the front page.
19:28:21 <abadger1999> nirik: Well, I don't think I can strike the last sentence until we vote on it with the last sentence in -- both ltinkl and jreznik appear to want it to remain on the page.
19:28:32 <Kevin_Kofler> We also definitely need kde.fedoraproject.org to keep working, many people are using that link.
19:28:39 <jreznik> abadger1999: well, I'm ok with link
19:28:43 <jreznik> same as it's now
19:28:46 <abadger1999> (although jreznik, I think you said "yes" to both having it on the page and having it removed fro mthe page)
19:28:47 <jreznik> so status quo
19:29:02 <Kevin_Kofler> (could be a redirect to a new plasma.fedoraproject.org, of course)
19:29:29 <jreznik> abadger1999: as I said - status quo for f21 - blocking spin, link from get.fpo
19:29:29 <nirik> kde doesn't appear now on the 'main page' that I see
19:29:37 <jreznik> nirik: yep, see above
19:29:56 <abadger1999> http://fedoraproject.org/get-fedora#desktops
19:29:56 <nirik> jreznik: not seeing? repeat please?
19:30:06 <sgallagh> Are we seriously attempting to micro-manage the website design?
19:30:17 <nirik> sgallagh: seems so.
19:30:34 <pjones> sgallagh: no, we're seriously kibbitzing about irrelevant details since we haven't agreed on the things that would or wouldn't matter to website designers yet.
19:30:41 <nirik> How about we let websites work with kde spin folks and if people are unhappy we can revisit?
19:30:42 <Kevin_Kofler> We (KDE SIG) have seen what happens if the Websites team get free reign.
19:30:48 <sgallagh> nirik: I was just typing that
19:31:03 <mitr> sgallagh: We have the precedent of the Board doing that ;-|
19:31:15 <jreznik> nirik: status quo for F21 - release blocking, link from get.fpo as it's now (but seems ltinkl does not agree with me ;-)
19:31:17 <mitr> Lets try this once again... votes on abadger1999's proposal?
19:31:18 <abadger1999> sgallagh: no -- we're determining the requirements to hand to the websites team.
19:31:22 <Kevin_Kofler> Whether our product/spin/pre-product/whatever will be actually visible to users is not an irrelevant detail.
19:31:24 <sgallagh> mitr: We haven't overthrown the Board yet, so let's please just stop this
19:31:44 <jreznik> nirik: +1 to work with websites guys
19:31:44 <abadger1999> mitr: thanks.  and if it doesn't pass, then we can vote on it with the last sentence struck/modified/etc.
19:31:54 <jwb> sgallagh, yet!  there is still hope!
19:32:00 <nirik> jreznik: well, it's not really directly on there, it's hidden under a desktops tab
19:32:10 <mattdm> um, could we have a repeat of the proposal? (abadger1999)
19:32:28 <mitr> abadger1999: 0 at this point, mainly because "establish milestones" doesn't actually say what we want the product to do / be.
19:32:32 <abadger1999> Proposal: recommend to the board that they consider this product for F22, and we commit to establishing milestones for it being on target for that in the mean time.  For F21 we continue to consider the KDE Spin (or a renamed version) as release blocking.  KDE Spin will continue to have a place on the download page for the Fedora Products.
19:32:35 <nirik> -1
19:32:36 * ltinkl scrolls back for the proposal, getting lost a bit
19:32:45 <mitr> ... And I still think that the WG should have some time to discuss this
19:32:49 <sgallagh> abadger1999: +1
19:32:49 <abadger1999> pjones: Do you want to expand on "establishing milestones" ?
19:33:12 <pjones> abadger1999: I was thinking that'd be an action item /after/ we agree on that as a general course
19:33:30 <pjones> abadger1999: but mitr's wording about product differentiation from Workstation, and specific work on features for the Engineering/Scientific community is a good start
19:33:37 <t8m> abadger1999, +1
19:33:40 <pjones> (the milestones need not be temporal)
19:33:41 <abadger1999> mitr: Would that satisfy you?  It's similar with the way we handled promoting arm to primary arch.
19:33:56 <mattdm> I guess I'm -1 on that; I'd like the board to weigh in on the bigger question first
19:33:57 <abadger1999> +1
19:33:59 <mitr> pjones, abadger1999: that would work I suppose
19:34:25 <pjones> and again, this is all still contingent on the board being okay with it as a product, or with more products as a whole.
19:35:08 <nirik> to clarify, I don't think the kde spin should be given priority on the websites with products, but I think it should definitely be offered along with other spins or possibly above other spins. Just as a direction to websites folks and IMHO.
19:35:27 <mitr> I'll change my vote to +1
19:35:30 * jreznik as Board member that time always understood this vision as multi product initiative and voted as for multi product distro (even other products were not stated there)
19:35:33 <mitr> So we are at +4-2
19:35:50 <mitr> More votes?
19:35:54 <mattdm> I am perfectly fine going on the record in favor of putting kde visibly on the web page in whatever form, and also about not taking away kde.fp.o
19:36:32 <Kevin_Kofler> jreznik: That's what it originally was, before mjg59 came up with that hardcoded list of 3 Products.
19:36:34 <mitr> mattdm: +1 (but not going so far as requiring that ATM)
19:36:59 <sgallagh> Kevin_Kofler: Just to be fair, the "hardcoded list" came first, as that was the output of discussions at Flock
19:37:13 <notting> Kevin_Kofler: wasn't mjg59
19:37:18 <Kevin_Kofler> So I was misled by the chronology of blog posts.
19:37:22 <mattdm> So, my proposal is to first ask the board for the board view on number of products and overlap in scope (and sure, particualrly with desktops)
19:37:25 * pjones +1
19:37:39 <pjones> with the caveat that we still need a board decision, of course.
19:37:39 <sgallagh> Kevin_Kofler: Making it a permanent list was never stated at that time, though
19:37:47 <mitr> pjones: to abadger1999's proposal?
19:37:53 <pjones> yes
19:37:58 <mattdm> and to abadger1999's proposal can be attached to that as a followup
19:38:14 <Kevin_Kofler> notting: He was the first to argue for only 3 Products on Planet Fedora, if my memory doesn't fail me really badly. But it doesn't really matter now…
19:38:22 <mitr> #agreed recommend to the board that they consider this product for F22, and we commit to establishing milestones for it being on target for that in the mean time.  For F21 we continue to consider the KDE Spin (or a renamed version) as release blocking.  KDE Spin will continue to have a place on the download page for the Fedora Products. (+5-2)
19:38:23 <abadger1999> mattdm:  yeah, I'm trying to write your broader question into a second proposal now.
19:38:26 <pjones> mattdm: we can just say it's provisional and we'll consider re-affirming it when the board votes? ;)
19:38:27 <mattdm> or alternately, since abadger1999's proposal passes, to attach the broader question to that :)
19:38:44 <notting> abadger1999: -1 as it's written. i think the project as a whole needs to decide how focusing on specific areas meshes with overlapping products distinguished at first glance by tech choice.
19:39:01 <abadger1999> mattdm: How's this look?  Proposal: Informationally, inform the Board that FESCo is split on a strategic vision of Products.  Do we want to position Fedora as the producer and promoter of a few Products that address specific target markets or do we want to position Fedora as a Project that makes it possible for contributors to produce Products that are promoted separately.
19:39:23 <mattdm> abadger1999 yes but oooh put some of notting's wording into it :)
19:39:29 <pjones> abadger1999: do you think we could ask anything more broad and open ended?
19:39:44 <pjones> because in the past, that has worked great with the board.
19:39:51 <pjones> We always get back coherent, helpful answers when we do that ;)
19:40:08 <mattdm> pjones Board: meaning of life? please advice.
19:40:09 <abadger1999> pjones: Yeah, good point there.
19:40:13 <jreznik> notting: well, Board can overrule this agreement and say "no, we don't want it"
19:40:15 <mitr> abadger1999: Why does this question even matter to FESCo?
19:41:05 <abadger1999> mitr: it informs *a lot* of the decisions we need to make and coordinate.
19:41:15 * mattdm agrees
19:41:18 <pjones> the answers we need from the board are a) are they actually okay with a Plasma product in F22, and b) what non-technical criteria should constrain whether we even see fit to bring more product proposals to them in the future?
19:41:40 * mattdm agrees more
19:42:02 <sgallagh> pjones: +1
19:42:05 <pjones> and those are nice questions, because they're questions you can tell if have been answered or not ;)
19:42:08 <mitr> abadger1999: what pjones asks makes sense; re: promoting, that's not FESCo's area of responsibility and wouldn't even affect any FESCo's decisions whether to support new products (if it is only about "promotion")
19:42:41 <ltinkl> those questions should have been asked right from the start, even for the current 3 products
19:42:49 <ltinkl> were they?
19:43:14 <abadger1999> mitr: fesco's interactions with websites and marketing affect that.
19:43:23 <jreznik> ltinkl: they were somehow
19:43:26 <mitr> ltinkl: Because the Board has approved the first 3 products as a set, we didn't need criteria for adding the products one at a time
19:43:27 <abadger1999> mitr: for isntance, fesco weighed in on multi-desktop dvds.
19:43:40 <ltinkl> did the Board decide on the e.g. Cloud product?
19:43:46 <jreznik> ltinkl: yep
19:43:57 <ltinkl> ok
19:43:57 <jreznik> it did
19:44:01 <jreznik> proposed as part of all three products
19:44:20 <mitr> So, next steps?  1) ask the board, 2) establish goals/milestones, something else?
19:44:21 <mattdm> but they did consider each one individually
19:44:47 * mitr is +1 to question wording by pjones
19:45:10 <ltinkl> mitr: 1) I'd rather see this worded as "recommend to the board", based on the proposal that had been aproved earlier
19:45:23 <mattdm> do we need to elaborate on "b"?
19:45:35 <mitr> ltinkl: well the original proposal was "recommend to consider" i.e. "ask"
19:46:01 <mitr> mattdm: We do need to agree on what the goals are IMHO.  Not necessarily today.
19:46:11 <ltinkl> mitr: "that they consider", notice the use of conjunctive there
19:46:26 <pjones> okay, let me try this again:
19:46:28 <abadger1999> pjones: so .. the are they okay with the plasma product seems to be wrapped up in the previous proposal (we recommend that the board consider this for f22)
19:46:29 * nirik can be +1 to pjones's questions... but also could be ok with abadger1999's (perhaps expanded). Perhaps we should ask for discussion on the board list and revisit next week?
19:46:51 <abadger1999> pjones: the second part perhaps is even more general than what I had written?
19:46:56 <mattdm> I'd like to actually file a ticket with the board this week.
19:47:13 <pjones> abadger1999: yes, but it also helpfully demands a list of specific things as its output.  In my eyes, that's more important.
19:47:38 <pjones> abadger1999: the board needs to limit us here.  We need constraints from them as guidance.
19:48:15 <pjones> abadger1999: which is also a nice framework because it's additive - if they miss something, they can add it later without changing our whole thinking process.
19:48:29 <mattdm> I'm okay with delegating someone (abadger1999, pjones, both?) to file that ticket
19:48:47 <mattdm> because I think we *basically* agree on what it should say
19:49:14 <mattdm> and I have been in meetings since early yesterday morning and don't think we need to hash out the exact wording here
19:49:16 <abadger1999> Second Proposal: Inform the Board: FESCo is requesting guidance on non-technical criteria that for adding new products.  In particular we wish to know whether Products should be added based on whether they address an audience that is not targetted by an existing Product or whether the criteria should be based on the Product having sufficient manpower to reasonably ensure a good Product.
19:49:33 <pjones> I really don't think that's better.
19:49:37 <abadger1999> k
19:49:43 <mitr> We are at +3 for the questions by pjones, +4 with pjones implied.  So let's ask those and move on?
19:49:55 <mattdm> is that counting me?
19:49:57 <mattdm> +1 if not
19:49:57 <sgallagh> mitr: Am I counted there? If not, +1
19:50:06 <mitr> mattdm: it wasn't.
19:50:09 <abadger1999> I oculd be +1 for pjones if we add something specific about the constraint we're talking about.
19:50:33 <mattdm> proposal -- add us all to cc for the board ticket and we can clarify as needed
19:50:33 <abadger1999> Something along the lines of the "In particular[..]" that I wrote above.
19:50:36 <mitr> #agreed Ask the board  a) are they actually okay with a Plasma product in F22, and b) what non-technical criteria should constrain whether we even see fit to bring more product proposals to them in the future? (+5)
19:50:50 <nirik> could that be rephrased as: what should new product proposals to the board contain before we submit them?
19:50:57 <sgallagh> I'm reasonably willing to trust that the Board is sufficiently competent to understand what "constraint" means.
19:50:58 <pjones> mattdm: +1 to that
19:50:59 <mitr> abadger1999: Those "in particular" are really non-obvious to be the only reasonable alternatives
19:51:25 <abadger1999> mattdm: +1 no matter what else we decide.
19:51:31 <nirik> mattdm: +1
19:51:34 <sgallagh> mattdm: +1
19:51:38 <abadger1999> mitr: sure.  but do they sum up the only ones that were mentioned today
19:51:40 <abadger1999> ?
19:51:45 <mitr> mattdm: +1
19:51:51 <notting> mattdm: yes
19:51:54 <notting> mattdm: +1
19:51:57 <mitr> mattdm: Will you file the ticket then?
19:52:09 <ltinkl> I'm a bit confused here :)
19:52:21 <mattdm> aw crap :)
19:52:24 <t8m> mattdm, +1
19:52:26 <mattdm> i mean, sure :)
19:52:29 <ltinkl> [20:51] <ltinkl> [20:38] <mitr> agreed recommend to the board that they consider this product for F22
19:52:35 <mitr> #action mattd to file the board ticket
19:52:40 <abadger1999> ltinkl: For KDE in particular, (1) in F21 we do not expect to ship a Plasma Product.
19:52:40 <ltinkl> [20:50] <mitr> agreed Ask the board  a) are they actually okay with a Plasma product in F22
19:52:46 <mattdm> #undo
19:52:46 <zodbot> Removing item from minutes: ACTION by mitr at 19:52:35 : mattd to file the board ticket
19:52:53 <mattdm> #action mattdm to file the board ticket
19:52:53 <abadger1999> (2) We want the board to consider it for F22
19:53:17 <abadger1999> (3) We are going to ship a KDE Spin that blocks the release and is listed on the download page.
19:53:20 <nirik> and this last part has been higher level talk about any new products, not kde in particular
19:53:50 <pjones> (though the wording on (3) left some wiggle room; it could be a Plasma spin instead.)
19:53:51 <abadger1999> ltinkl: These latest proposals to take to the Board are only indirectly related to kde.  and likely will not affect F21.
19:53:55 <mitr> ltinkl: AFAICS the two parts are actually asking the same thing
19:54:13 <ltinkl> mitr: but they kinda contradict each other in wording
19:54:30 <abadger1999> pjones: Correct.  KDE Spin could be renamed.
19:54:37 <mitr> ltinkl: No, they don't imply FESCo's position on the matter.
19:55:14 <mitr> Proposal: Leave the ticket open, discuss goals/milestones on devel@, to be voted on next week.
19:55:30 <pjones> mitr: +1
19:55:37 * mitr is +1 for the record
19:55:39 <abadger1999> also -- (3) is for F21 only.  F22 will have new information from the Board and from how successful F21 was so we'll make new decisions then.
19:55:42 <ltinkl> mitr: they do, in the first "agreed" item you tell Board to consider Plasma product, in the second "agreed" item you again ask them whether they are ok with it
19:55:48 <sgallagh> mitr: -1 Please don't make us go through this again next week
19:56:14 <mitr> sgallagh: do you have a counter-proposal to get those goals established?
19:56:16 <pjones> sgallagh: well, we're already on the hook for some form of setting milestones.  he's really just formalizing that AFAICS
19:56:33 <pjones> though that could reasonably be a different, specifically worded ticket.
19:56:35 <sgallagh> mitr: I think sending this to the Board as discussed is enough to close it...
19:56:38 <abadger1999> sgallagh: sorta agree -- I'd say we discuss it when the Board comes back to us with some guidance.
19:56:44 <mattdm> ltinkl that's redundant, not contradictory.
19:56:47 <sgallagh> abadger1999: Yes
19:56:52 <nirik> abadger1999: +1
19:57:11 <pjones> ltinkl: I kind of think you're splitting the hairs a bit fine here ...
19:57:15 <mattdm> I am assuming we want *one* board ticket for these two proposals? or do we want two?
19:57:20 <mitr> sgallagh, abadger1999: OK.  I'm withdrawing that, and let's keep the ticket open until the board comes back.
19:57:28 <abadger1999> wfm
19:57:29 <sgallagh> ok
19:57:30 <pjones> mattdm: I'm okay with one, I guess.
19:57:37 <mitr> #topic #1266 Updates to the non-responsive policy
19:57:39 <mitr> .fesco 1266
19:57:40 <zodbot> mitr: #1266 (Updates to the non-responsive policy) – FESCo - https://fedorahosted.org/fesco/ticket/1266
19:57:41 <mitr> https://fedorahosted.org/fesco/ticket/1266
19:58:03 <pjones> I agree with everything mitr said in the tickets.
19:58:41 <mitr> Generally I agree with the invalid e-mail fasttrack; without the extra FESCo ticket I could be +1
19:59:20 <nirik> so, it would be a bugzilla bug?
19:59:23 <mitr> For orphaning everything as the result, undecided leaning towards +1
19:59:24 <nirik> or just email to devel list?
19:59:44 <mitr> nirik: The current process is just email to devel, followed by FESCo action at the _end_ of that process.
20:00:17 <mitr> Separately, we probably _should_ modify the process to result in fesco tickets instead of a post on devel that is "silently" waiting for an ack from a FESCo member.
20:00:21 <t8m> I am +1 to orphaning everything in case of invalid e-mail however we shouldn't amend the normal single-package process
20:00:42 <pjones> mitr: the nice thing about an email instead of a ticket is that it makes for a much shorter barrier
20:00:45 * nirik thinks the entire process needs a revamp, but it's not an easy process to come up with
20:00:46 <abadger1999> mitr: So the fesco ticket is there to tell how long things have been going on.  I wouldn't mind striking it, though.
20:00:55 <pjones> mitr: ... the not nice thing is it's easy to ignore
20:01:00 <mitr> pjones: yes to both
20:01:08 <t8m> mitr, +1 to that too
20:01:29 * nirik is fine striking the ticket... or striking it from new part and making the regular process require a ticket for the fesco ack
20:01:32 <mitr> t8m: Wellll how often is it actually useful to non-responsive-maint a single package instead of all of them?
20:01:58 <abadger1999> mitr: the mass oprhaning piece -- I'm amenable -- where do you want it mentioned (in the invalid email section or in the orphaning process section?)
20:02:14 <t8m> mitr, I suppose there might be a case where maintainer does not care about some package but works on others?
20:02:35 <mitr> abadger1999: I read this as suggesting mass orphaning as the last step of the process (currently in Outline); if so, the Outline should actually say that all packages will be orphaned, not only the single one
20:02:37 <nirik> sure, although if thats the case you would think they would just orphan it and hand it off.
20:02:55 <pjones> t8m: there's certainly asymmetry of workload within individual maintainers.
20:03:08 <pjones> (please don't look at my packages for examples ;)
20:03:10 <abadger1999> mitr: ah -- my intention was to coninute to leave that separate (it's a problem but a spearate problem)
20:03:16 <t8m> nirik, yeah, maybe that would be incentive to orphan things that you do not care about at all
20:03:20 <abadger1999> I just wanted to mass orphan for invalid email.
20:03:57 <pjones> nirik: I think "does not care" is phrasing it too strongly, and makes it seem like handing it off is the obvious choice where it needn't be.
20:04:01 <nirik> all the timeouts in the process mean that many people don't bother, or just go part way and forget
20:04:07 <mitr> abadger1999: Ah, OK; as two section headers  on the same level I viewed them as independent
20:04:07 <abadger1999> mitr: In invalid email, I can add "we'll mass orphan all packages for this maintainer since we're unable to contact them".
20:04:30 <abadger1999> mitr: they are independent -- It seems I probably need to change the wording in the second section?
20:04:39 <pjones> abadger1999: yes
20:04:45 <nirik> pjones: sure. Could be a number of other reasons too...
20:05:05 <nirik> it's a package they do care about, but they don't care about whatever specific bug the person wanting to take it over is for example.
20:05:25 <pjones> sure.
20:06:39 <abadger1999> Does this read better now: https://fedoraproject.org/wiki/User:Toshio/Nonresponsive_maintainers_policy#Orphaning_Process
20:08:27 <mitr> wordsmithing over IRC...
20:08:29 <mitr> Proposal: 1) invalid email addresses section approved, with the requirement to create a fesco ticket removed; 2) proposed Orphaning Process paragraph to be moved into the "Notes for Mass Orphaning" section and approved
20:08:35 <notting> reads ok to me
20:08:38 <nirik> sure, +1
20:08:51 <pjones> mitr: +1
20:08:55 <pjones> on both counts.
20:09:06 <t8m> mitr, +1
20:09:08 <abadger1999> and invalid email updated to (1) not file ticket, (2) mass orphan after the process is followed from step #4 https://fedoraproject.org/wiki/User:Toshio/Nonresponsive_maintainers_policy#Notes_for_invalid_email_addresses
20:09:17 <mattdm> is ready to +1 anything at this point :)
20:09:25 <dgilmore> +!
20:09:27 <dgilmore> +1
20:09:43 <sgallagh> mattdm: Proposal: mattdm takes over all non-responsive maintainer packages :)
20:09:50 <abadger1999> +1 but note -- as applied to a single package, that's the orphaning process that we'd follow as well.
20:09:56 <dgilmore> sgallagh: sold
20:10:15 <mitr> abadger1999: good point
20:10:17 <sgallagh> mitr: +1, in all seriousness
20:10:54 <mitr> With all the edits...
20:10:56 <mitr> Proposal: changes as made on Toshios' page approved
20:11:05 <pjones> also +1
20:11:08 <abadger1999> +1
20:11:12 <nirik> +1
20:11:14 <mitr> +1
20:11:28 <mitr> abadger1999: will you update the page?
20:11:36 <t8m> +1
20:11:40 <abadger1999> mitr: yeah, make it my action.
20:11:41 <mitr> #agreed Proposal: changes as made on Toshios' page approved (+6)
20:11:53 <mitr> #action abadger1999 to update the nonresponsive maintainer policy page
20:11:55 <mitr> thanks
20:12:05 <mitr> #topic Next week's chair
20:12:17 * dgilmore has not done it yet so will
20:12:33 * sgallagh had volunteered last week for this, but is happy to let dgilmore do it
20:12:46 <mitr> #info dgilmore will chair next week's meeting
20:12:51 <dgilmore> sgallagh: if you want I can do the week after
20:12:57 <dgilmore> done :)
20:12:58 <sgallagh> dgilmore: I think that's Summit.
20:13:14 <mitr> #topic Open Floor
20:13:15 <dgilmore> sgallagh: okay, not something ive ever been to
20:13:16 <sgallagh> Ah no, that would be one after that
20:13:22 <mitr> Anything for open floor?
20:13:43 <abadger1999> I fly out to a conference April 7, then vacation, won't be back until April 27th.
20:14:22 <sgallagh> abadger1999: Enjoy your vacation
20:14:41 <nirik> I had one small thing...
20:14:45 <abadger1999> I'll try thanks :-)
20:14:58 <pjones> At /some/ point I'm going to take some post-rhel-7 vacation, but it's not clear when yet.
20:15:09 <pjones> so just, you know, vague fyi
20:15:31 <nirik> On timer units change (which we approved), were we waiting on applying those until packaging guidelines are made? or did we not care if they were not done?
20:16:09 <nirik> this is re: https://bugzilla.redhat.com/show_bug.cgi?id=1064537
20:16:15 <sgallagh> I asked about guidelines and was told none were being written :-/
20:16:31 <nirik> there are at least some places where they would definitely make sense.
20:16:42 <mitr> "Adjust packaging guidelines to mention migration of cron jobs to timer units for packages that already depend on systemd " is an item in the Scope section
20:16:55 <abadger1999> :-(  There should be some.... we have socket activation and such.. is this not just "time activation"?
20:17:05 <sgallagh> Right, but I asked for a migration guide and was told that there isn't a direct analog
20:17:18 <sgallagh> That new timer units would have to be written on a case-by-case basis
20:17:26 <abadger1999> https://fedoraproject.org/wiki/Packaging:Systemd#Activation
20:18:06 <nirik> there is also the question of default running services vs not... do timer units just run always? or only packages that are approved to default run? or up to maintainer?
20:18:09 <mitr> sgallagh: If the Change owners are actually providing patches, I'm not sure we need a _migration_ guide (we might need a packaging guideline for the longer-term)
20:18:46 <t8m> nirik, the cron jobs run by default and we are not creating new ones within this Change
20:18:50 <mitr> nirik: It... can't get worse than it was with cron?
20:18:53 <nirik> also, if you aren't to add timer units to things that don't already depend on systemd (which the change isn't going to do), should there be a guideline saying that?
20:19:16 <abadger1999> mitr: <nod>  I don't need a migration guide, just a packaging guideline
20:19:34 <mitr> nirik: These detailed questions fall under the general umbrella of "have packaging guidelines" IMHO
20:19:35 <sgallagh> ok
20:20:06 <nirik> mitr: right. Just wanted to make sure I didn't misunderstand and should be applying these now without those guidelines existing.
20:20:44 <mitr> Generally.... this is a non-blocking Change with a trivial contingency mechanism, not a huge deal.  Do we want to remind the Change owners about guidelines anyway?
20:21:28 <mitr> ... about writing the guidelines they have already planned to, that is
20:21:41 <nirik> well, IMHO, guidelines should exist before things are commited. I don't want us doing things one way, then finding out it's wrong and needs redoing.
20:22:40 <nirik> so sure, if someone would remind them that would be great.
20:23:37 <mitr> #info for cron-to-systemd-time-units, please make sure the necessary packaging guidelines are approved before commiting the patches.
20:23:39 <mitr> Sufficient?
20:23:56 <nirik> sounds great to me.
20:24:02 <sgallagh> worksforme
20:24:10 <mitr> Anything else for open floor?
20:24:39 <mitr> I'll close the meeting in 2 minutes if not...
20:26:47 <mitr> Thanks everyone!
20:26:48 <sgallagh> mitr: Thank you for chairing this long meeting.
20:26:49 <mitr> #endmeeting