18:00:57 #startmeeting FESCO (2014-03-26) 18:00:57 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:59 #meetingname fesco 18:00:59 The meeting name has been set to 'fesco' 18:01:01 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:01:01 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:01:03 #topic init process 18:01:06 Hello everyone 18:01:08 #info sgallagh is here 18:01:11 Greetings 18:01:13 hola amigos 18:01:19 * jreznik is lurking, cooking dinner 18:01:27 hello 18:01:45 morning 18:01:53 * notting is here 18:02:55 hi 18:03:45 OK, let's start 18:03:51 /me needs to leav in an hour 18:04:05 hi 18:04:18 Based on devel discussion, I have dropped #1178 from the agenda. 18:04:22 I have to pick up my daughter and take her to get registered for kindergarten 18:04:42 (hi) 18:05:14 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 mitr: Ack on dropping the schedule piece 18:05:22 mitr: yep 18:05:30 #topic #1253 requesting exception for linking cscppc and cswrap with glibc-static 18:05:31 mitr: that is fine 18:05:32 .fesco 1253 18:05:33 mitr: #1253 (requesting exception for linking cscppc and cswrap with glibc-static) – FESCo - https://fedorahosted.org/fesco/ticket/1253 18:05:34 mitr: by which I mean I agree 18:05:34 https://fedorahosted.org/fesco/ticket/1253 18:05:45 * pjones is (still/again) +1 to the exception 18:06:01 +1 18:06:11 The use cases still seem weird to me, but I guess I can be +1 18:06:21 im not opposed to teh exception, but its really trivial to not need it 18:06:23 +1 as I said in the ticket 18:06:45 dgilmore, I don't think it is so trivial 18:06:47 requestor isn't around are they? 18:06:55 t8m: it really is 18:06:57 * kdudka is here 18:06:57 kdudka: you around? 18:07:36 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 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 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 kdudka: not true. 18:08:27 nirik, yes, rhel-5 mock profile is one of the cases where it would cause problems 18:08:46 why? download epel5 rpm, mock --copy-in ? 18:08:55 dgilmore, can you be more verbose? 18:08:57 which is what you would do with the static one anyhow? 18:09:17 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 nirik, how would csmock figure out that epel5 yum repo provides working binaries for the chroot that _user_ selected? 18:10:05 kdudka: where the metadata just includes the rpms needed 18:10:11 dgilmore, you mean me as a user, or me as a developer of csmock? 18:10:20 kdudka: either 18:10:45 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 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 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 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 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 pjones: i disagree, as I said I am not opposed, I just think its really not needed 18:11:28 t8m: indeed 18:11:36 nirik, this just shifts the responsibility to the user, does not it? 18:11:40 nirik: That makes it even more difficutl to recognize builds against el5, doesn't it? 18:11:42 As I pointed out in the ticket, it would just work for our mock profiles, why is that not good enough? 18:11:57 dgilmore: it would be interesting if your disagreement included more words than "I disagree", such as the actual disagreement... ;) 18:11:59 mitr: not sure what you mean? 18:12:05 (it = shipping the binaries properly in EPEL instead of dropping them in statically-linked) 18:12:20 nirik: If there is no standard RHEL5 repo, how would the caller of mock know to add epel _5_? 18:12:29 kdudka: well, if a user makes a custom mock config, wouldn't it be their responsibility? 18:12:46 mitr: there are mock configs with epel5. 18:12:50 pjones: detecting that your on rhel and adding a repo to the chroot is simple to do 18:13:06 nirik: How does that help determining whether to use epel 5 or epel 6? 18:13:10 there's not any for rhel5, because... rhn/subscriptions. 18:13:11 sure, but what repo? hosted where? 18:13:29 pjones: as is to use mock with rhel without epel is not trivial 18:13:35 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 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 mitr: if you make a custom mock.cfg wouldn't you know that as the user? 18:13:50 nirik: One of the places where hopefully the CentOS/RHT merge will help things 18:14:01 nirik: yes, but then it's no longer automatic 18:14:01 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 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 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 abadger1999, maybe it sounds "it just works" but apparently it does not really 18:15:01 So we are at +4-1 0x1. Other votes? 18:15:08 0 18:15:17 t8m: right.. I could be convinced.. but I'd have to know what I'm missing. 18:15:21 i'm +1 to the exception - don't see why pushing making it work down to the user makes sense 18:15:38 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 and why shouldn't the tool support any third party mock configs which do not want to ship the binaries work< 18:15:55 yeah, that last thing nirik said :) 18:15:59 so... I guess +1 18:16:11 nirik: its completely pandering to corner cases where you have to go out of your way to make them work today 18:16:12 Where's csmock coming from? epel and fedora repos? 18:16:12 nirik: "pandering to corner cases" is a fair analogy for "why exceptions exist" 18:16:21 abadger1999: yes 18:16:23 #agreed Static linking exception for cscppc and cswrap approved (+6-1 0x2) 18:16:32 so, they would have at least have those repos for csmock 18:16:39 18:16:46 This wasn't on the agenda, but since we have updates: 18:16:47 but on the host only 18:16:48 #topic #1221 Product working group activity reports 18:16:50 .fesco 1221 18:16:52 https://fedorahosted.org/fesco/ticket/1221 18:16:52 mitr: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 18:16:54 Is there anything we want to discuss this week? 18:16:58 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 mitr: Perhaps a general reminder to get Changes filed ASAP? 18:18:23 #info Please file Changes (Product-related and others) ASAP, proposal submission deadline is on April 8th. 18:18:56 If nothing else... 18:19:05 #topic #1250 F21 Self Contained Changes 18:19:07 .fesco 1250 18:19:08 mitr: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250 18:19:09 https://fedorahosted.org/fesco/ticket/1250 18:19:11 There's only one, Security Policy In The Installer - https://fedoraproject.org/wiki/Changes/SecurityPolicyInTheInstaller 18:19:30 and it was somehow hot topic in the devel list... 18:19:47 i'm -1 to this, for reasons explained on the devel list 18:20:10 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 I am -1 to the proposal with a gui. i think it's fine/good in kickstart 18:20:29 Where "sanely" means "without scaring them off or getting incorrect results" 18:20:35 * pjones also -1 18:20:38 yeah, I think it's good for ks, but as presented not good for the gui installer. -1 18:20:43 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 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 i am fine with it being available in kickstart, though 18:21:20 -1 as well for the same reasons 18:21:25 mitr: AFAICS it's entirely possible to do this in kickstart without anaconda/pykickstart really being involved 18:21:29 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 id be okay with it in the gui if triggered by adding a flag to the boot line 18:21:46 +#info abadger1999 ? 18:21:47 I agree with mattdm's split of kickstart vs gui 18:21:47 pjones: There is a little interaction with anaconda features (partitioning, password policy) 18:21:54 mitr: through %packages choices and %post, that is. which I realize /somewhat/ defeats the purpose. 18:21:55 So -1 overall, +1 to just kickstart 18:22:03 abadger1999: I was thinking its really a system wide change 18:22:18 my point being the place to best do this would be in things like ansible and puppet that generate kickstarts. 18:22:30 # 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 gahl 18:22:36 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 pjones: that is reasonable 18:22:38 #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 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 #agreed Security Policy In The Installer was not accepted (-7) 18:23:32 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 mitr: I'd suggest sending a recommendation that they re-file as kickstart-only 18:23:52 I'd say ask them to repropose since there is time? 18:23:56 18:24:08 #info Please consider re-proposing as a kickstart-only feature 18:24:19 Noting that there is reasonably-strong likelihood of that passing 18:24:22 #topic #1262 F21 System Wide Change: Modular Kernel Packaging for Cloud - https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud 18:24:24 .fesco 1262 18:24:25 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 https://fedorahosted.org/fesco/ticket/1262 18:24:31 +1 yaya 18:24:34 yay 18:24:37 not yaya. 18:24:58 this doesn't seem worth it to me, but given kernel folks have already done the work and such, +1 18:25:03 +1 to modularization 18:25:09 *shrug* +1 18:25:10 +1 18:25:11 i'll note this still needs to be reviewed by more kernel peoples 18:25:18 I was about to say what jwb said 18:25:21 +1 if kernel folks are OK 18:25:22 +1 18:25:29 I'm vaguely for it, but I'd like more kernel weigh-in. 18:25:36 also thanks to jwb for the work. 18:25:48 +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 so far it's me doing the work, and zickus has helpfully reviewed without any major objections 18:26:07 dgilmore, the content list is per-arch 18:26:26 #agreed Modular Kernel Packaging for Cloud approved (+7) 18:26:32 jwb: okay, I remeber that there was some contention over some things 18:26:38 jwb: if thats changed great 18:26:41 #1263 F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs 18:26:43 .fesco 1263 18:26:44 mitr: #1263 (F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs) – FESCo - https://fedorahosted.org/fesco/ticket/1263 18:26:45 https://fedorahosted.org/fesco/ticket/1263 18:26:51 jwb: it can all be resolved somehow :) 18:27:52 I might be wrong, but this feels more like an FPC-level decision 18:28:18 proposal: send to fpc with a recommendation in favor 18:28:26 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 i think the reason for the change is to make sure it gets in the release notes 18:28:46 But that's obviously a larger problem 18:28:50 I think this is more about problems with actually building the javadocs. 18:29:12 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 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 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 yeah, java8 is a lot more strict on javadocs. 18:29:54 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 mitr: Fair point 18:30:17 mattdm: I agree that a Change is good so that it gets release noted. 18:30:35 so I am +1 anyway 18:30:52 #topic 1263 F21 System Wide Change: Optional Javadocs - https://fedoraproject.org/wiki/Changes/OptionalJavadocs 18:30:54 * nirik is +1 18:30:56 +1, but I'd still like it to go to FPC, at least for the guideline changes 18:31:13 so, okay, +1 with same basic caveats 18:31:20 The owners have already committed to update the packaging guidelines in the Scope sesction 18:31:28 +1 18:32:00 * pjones +1 as well 18:32:03 +1 to the change again, and +1 to forwarding to FPC for guideline changes 18:32:06 +1 to the change assuming that the FPC approves the needed packaging guidelines 18:32:06 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 abadger1999: ack 18:32:25 #agreed Optional Javadocs change approved (+8) 18:32:35 #topic 1264 F21 System Wide Change: Ruby on Rails 4.1 18:32:37 .fesco 1264 18:32:38 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 https://fedorahosted.org/fesco/ticket/1264 18:33:09 +1 18:33:11 +1 rubber stamp 18:33:14 +1 18:33:19 sure, +1 18:33:20 +1 18:33:40 +1 18:33:44 +1 18:33:47 Looks like this will require scheduling a mass rebuild? 18:33:48 +1. although would love to know how much always-latest rails affects developer uptake on Fedora rails vs. rubygems.org rails 18:34:06 Or a side-tag? (Unclear to me) 18:34:12 notting as far as I can tell, "severely". 18:34:18 +1 18:34:21 sgallagh: i suspect that we will soon have a system wide mass rebuild that we need to plan 18:34:34 notting: or how much never-latest rails would affect it... We really need many versions I guess. 18:34:41 #agreed Ruby on Rails 4.1 approved (+9) 18:34:43 dgilmore: Sure, but I'm not clear on whether a trivial rebuild will work or if all packages will need tweaks 18:34:51 but to do anything else we need a strong commitment from someone to maintain the older stacks 18:35:03 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 sgallagh: Rails incompatibilties tend to be source-level 18:35:10 mitr: we really do, yes 18:35:45 #topic 1265 Fedora Plasma Product 18:35:47 .fesco 1265 18:35:48 mitr: #1265 (Fedora Plasma Product) – FESCo - https://fedorahosted.org/fesco/ticket/1265 18:35:49 sgallagh: usually something like a ruby on rails bump etc is a build done in a side tag 18:35:49 https://fedorahosted.org/fesco/ticket/1265 18:36:40 (HINT STILL NEED TO FILE BOARD TICKET) 18:36:55 jwb hint taken -- was planning to talk about that... now 18:37:07 I think there is little to discuss here until the board says okay 18:37:07 jwb: before fesco discussion or after? I wasn't sure from the FESCo ticket 18:37:08 We should discuss this and then file a board ticket. 18:37:10 but I could be wrong 18:37:36 I'm still against adding more products before we know if this product thing is even working. 18:37:41 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 dgilmore: The valid point was made in the ticket that the other three Products went to the Board as FESCo recommendations 18:37:54 It seems only fair to do the same for Plasma 18:37:59 sgallagh: fair enough 18:38:04 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 nirik: as stated in the ticket, the name doesn't help with that 18:38:21 nirik yes, I have the exact same concern. 18:38:30 #insert stuff I said in ticket 18:38:47 right. 18:38:52 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 There's certainly some overlap, but I think there's also a pretty clear space outside of it 18:39:11 I don't have problem with the name but the product purpose differentiation from the Workstation is crucial 18:39:38 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 I really like the idea of a Fedora Product targeting the Scientific/Educational constituency 18:39:58 But with that in mind, I'd also want the KDE spin in F21 to be release blocking. 18:40:01 we target a completely different audience 18:40:02 sgallagh, +1 me too 18:40:08 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 Particularly because we have a *very* popular downstream distribution that will benefit directly from this as well (Scientific Linux) 18:40:14 sgallagh: And KDE Plasma is a great platform for that because of all the work done by the kdeedu team. 18:40:22 ltinkl: not completely, both mention developers, but largely true 18:40:24 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 abadger1999, i... don't think pjones actually said to push products to f22 18:40:38 sgallagh: we are a pretty popular KDE developer distribution 18:40:43 the Workstation is mainly aimed at developers, we focus on scientists/teachers/students, generally power users 18:40:55 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 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 sgallagh: as in upstream folks run fedora 18:41:05 i... don't know that the SL people are a crossover with the kdeedu people 18:41:12 ltinkl: oh, and both mention students 18:41:22 Then there are the other KDE and Qt science and education apps listed on the PRD. 18:41:26 abadger1999: I think I'm behind that interpretation, though it is yours not mine ;) 18:41:33 Plasma is just a fancy name, we thought it nicely links the "science" aspect with the underlying technology 18:41:46 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 But addressing a pristine problem space certainly does 18:42:03 rdieter: But we actually give students app to do serious work with, Workstation focuses on the full-time-gaming student. ^^ 18:42:20 *apps 18:42:38 Kevin_Kofler: I think that's an oversimplification, but as I said I like the focus 18:42:49 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 that is, this *didn't* come out of the scitech sig -- why not? 18:43:36 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 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 And the logical step is -- if that is the real worry, can we solve that in a different way? 18:44:10 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 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 mattdm: agree with dgilmore there, KDE is the single most popular desktop environment, and should get the same treatment 18:44:51 dgilmore: "with the upstream support and overall popularity we should have a C++-based product" 18:44:52 dgilmore I think that those things are excellent reasons for having a KDE *spin* 18:44:57 if we are to attract actually more users/developers 18:45:20 mattdm: we can agree to disagree 18:45:35 Kevin_Kofler: I'm not convinced by 'other distros do it' either. ;) 18:45:36 mitr: nah, if we're going by upstream usage popularity we should have a java/ruby/objc based product 18:45:37 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 dgilmore yes; I think you are basically agreeing with abadger1999 :) 18:45:44 notting: of course :) 18:45:49 abadger1999: how then do we present them? 18:45:53 mattdm: (then desktop shells is another of course) 18:45:59 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 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 nirik: If you mean market them, then the main thing is we stop marketing "Fedora" as a Product. 18:46:22 mitr agreed, that is absolutely also important. 18:46:28 nirik: We start marketing the individul Products as products. 18:46:29 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 abadger1999: so, we say: here's a list of desktops, try them all and use the one you like best? 18:46:39 jwb: I think so (not sure exactly what "in the manner Workstation is persuing" means, but it's probably ok) 18:46:50 jwb: sure, and this will be also reinforced (internally in RH) by something I can't quite speak in public yet :) 18:46:54 nirik: We said that the Fedora Project might be more like apache's incubator project in the future. 18:46:54 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 I also agree with pjones here 18:47:23 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 nirik: If you model after them, then they don't emphasis "incubator" as a Solution for end users. 18:47:35 pjones, I could be +1 to that 18:47:35 rdieter, gdm is the login manager, you install KDE through software-installer 18:47:37 incubator is the brand for what they want people creating Products to use. 18:47:39 rdieter, to get to the short of it 18:47:48 Surely they won't even treat our display manager (SDDM or the old KDM) as blocking, will they? 18:47:48 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 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 The individual Products have their own identity that they market to end users. 18:47:57 nirik: yes. 18:48:14 jwb: yeah, pretty sure thats not good enough to satisfy a majority of our group 18:48:17 nirik: I don't think they have a competing web server but they have had things like competing search solutions. 18:48:28 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 rdieter, satisfy in what way? i asked if you're willing to work with Workstation on that 18:49:01 jwb: the details matter. and it's not just *me* you have to satisfy 18:49:08 notting: I think I agree with you. 18:49:27 seperate repos would be a big nightmare. ;) 18:49:27 notting: I kinda hope we could have a main repo and a repo that overlays it with things that are replacements. 18:49:38 separate repos... oh pls not 18:49:42 notting: rather than full disjoint repos. 18:49:46 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 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 jwb: no, not abandoning at all 18:50:07 mitr: I think that's just rewording what I said, mostly? 18:50:11 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 ltinkl, ok. that's great to hear 18:50:17 mitr: I mean, it doesn't answer the question: what does it look like on the web page? 18:50:32 jwb: speaking for myself, I'm committed to continued cooperation with workstation. 18:50:36 jwb: I'm personally not interested in having anything to do with Workstation, but that's just me. 18:50:39 jwb the PRD does talk about cooperation with workstation wg 18:50:42 mitr: but, I mean, I'm not opposed to other isomorphic plans that are worded more friendly ;) 18:50:45 rdieter, excellent, thank you 18:50:49 mattdm, i missed that! 18:51:01 i will have to re-read 18:51:02 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 one page with the Products Overview (or Showcase) would be nice 18:51:54 then separate pages where the individual products present themselves 18:51:58 Oh, and if popularity is of interest to you: 18:52:09 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 whois fedoraworkstation.org 18:52:15 NOT FOUND 18:52:17 Kevin_Kofler: I doubt it 18:52:20 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 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 mitr: that might be a fair point. 18:53:56 pjones: OTOH we have not actually placed such requirements on the first three products (though we strongly expect they will deliver) 18:54:21 notting: Correct. We want to avoid the "go to web page to pick one" in this scenario. 18:54:36 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 notting: instead, people promote the Product(s) that they're interested in. 18:55:19 That's what we've already been doing with http://kde.fedoraproject.org/ 18:55:38 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 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 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 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 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 pjones: Different viewpoint I think. 18:57:03 not entirely, if we have spins still. 18:57:34 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 pjones: I'm reading what you're saying as We no longer have a website that helps people download Fedora. 18:57:51 pjones: But I think in the Product world, we don't really have a "Fedora" anymore. 18:58:18 pjones: We have something called "Workstation", something called "Cloud" and somthing called "Server". 18:58:28 and we have spins 18:58:32 pjones: We most certainly should have websites that help users download those. 18:59:10 pjones: We just stop conflating fedora-the-incubator-for-these-products with the products themselves. 18:59:13 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 sgallagh +1 18:59:43 We are well over 15 minutes, shall we continue? 19:00:04 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 mitr: +1 to continue (I think this is an important topic) 19:00:15 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 +1 to continue 19:00:39 +1 to continue as well 19:00:47 XF86Config even ;) 19:00:54 *bookbarn giggle* 19:01:00 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 pjones: isn't that a job better suited for people actually doing/designing the web? :) 19:01:23 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 pjones: you can have 30 products and still present it in a sane and attractive way 19:01:42 entering into the record: the current mockup for new getfedora web site 19:01:44 http://ryanlerch.fedorapeople.org/getfedora/ 19:01:53 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 I am not really sure we have to solve the problem of single all-product page vs. separate pages here 19:02:14 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 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 mattdm, cloud wasn't important enough to make the mockup. HAHA 19:03:18 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 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 proposed one and prefer something different. as long as all these 'Fedoras' exist, how *do* you progress? 19:03:37 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 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 jwb :) 19:04:09 pjones: On that count, I'm more than willing to +1 you. 19:04:11 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 pjones: as I said - we are ok being pragmatic and stay blocking spin by F22 19:04:49 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 even ltinkl is as far as I know 19:04:58 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 Designing the mockup to hardcode 3 Products is a poor argument for only having those 3. 19:05:18 pjones: wfm 19:05:38 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 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 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 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 pjones: yeah.. 19:06:45 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 (and then we discuss F21 blocking as a separate item) 19:07:05 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 mitr, +1 19:07:36 mitr: I can get behind that phrasing 19:07:42 t8m: this is a _pre_proposal because I want to hear the Plasma WG's opinion 19:07:55 So what are you expecting us to do for the Engineering/Scientific community? 19:07:56 +1 to those as a pair. we need to figure out appropriate visibility before making a final decision. 19:07:57 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 Is Fedora now about upstream development? 19:08:18 with some guidance on what Kevin_Kofler asked, I'll be ok with it 19:08:21 err.. although we should have a vote on product differentiation. 19:08:31 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 But this is a starting point for a discussion, to a Requirement That Has Been Imposed on You 19:09:15 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 mitr: wait, wait, so you want the KDE spin renamed to Plasma spin? 19:09:50 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 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 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 abadger1999: I could be convinced... would need to ponder on it some more. 19:10:14 mitr: I think the SIG is telling you you had it right earlier when you said "provisional product" instead of "spin" 19:10:23 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 jreznik: electronic engineering and robotics spins 19:10:48 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 pjones: naming kind of presupposes defaults for decisions—but in a strictly technical way it doesn't matter to me 19:11:25 jreznik: but this need to be communicated with those spins first 19:11:26 it's basically what I said a while ago about "secondary products" 19:11:45 although "provisional" might be construed as more positive than 'secondary' 19:11:50 mattdm: indeed. 19:11:54 mattdm: yup 19:12:20 * mattdm mumbles something about 'probationary products', hides around corner 19:12:57 provisional better as probationary can either be a probationary period on the road to promotion or on the road to demotion. :-) 19:13:26 mattdm, you mean spins? 19:13:33 abadger1999 yeah I wasn't serious 19:13:40 abadger1999: which, to be fair, isn't the worst message in the world to send. 19:13:59 i see no point in inventing new words for spins 19:14:08 jwb well, as pjones says, it's something a little different. 19:14:21 a spin with certain aspirations. 19:14:26 yeah... not all spins are desiring to become products. 19:14:32 so's fedora.next. just repurpose the damn word and save the websites team some work 19:14:45 Yeah, a provisional product would probably want a FESCo liaison right now for example 19:14:49 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 nirik, and i don't see why the lack of product desire would mean you spin should no longer exist 19:15:16 mitr: rdieter volunteered to be liasson 19:15:21 right. agree 19:15:31 So... next steps? 19:15:51 agree on something? :) 19:15:56 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 yes do that :) 19:16:06 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 mitr: time machine, go back to 1997 and get trolltech and miguel in a room to talk licensing 19:16:17 I'm going to let you do that, so we don't have two things again. 19:16:19 notting: +1 ;) 19:16:23 notting: no kidding ;) 19:16:28 notting: with the orbital lasers, no budget left for time machine this week 19:16:43 :D 19:17:00 pjones: I suppose we could get something passed; would that be OK with the WG? 19:17:21 mitr: Please rephrase the proposal 19:17:42 I'll just go ahead and: 19:17:44 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 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 (Feel free to re-propose the provisionary product alternative, right now I'd rather give this a little more time.) 19:18:15 mitr: -1 19:18:51 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 jreznik: : 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 mitr: -1 please no more deferring 19:19:20 at least in terms of "Here's the proposal for a Product we'd like to have for F21". 19:20:03 mitr: well, WS product aims more on development not of fedora but 3rd party on top of fedora 19:20:24 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 jreznik and developers _using_ fedora 19:21:12 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 mattdm: and I definitely think that's the board's purview... 19:21:28 mattdm: we managed to attract _many_ upstream KDE developers to Fedora lately 19:21:29 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 jwb: s/KDE/Plasma but I'd be ok asking Board if pure KDE product would be allowed 19:21:51 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 jreznik, .... that's what i was saying isn't really productive at teh Board level 19:21:58 jreznik: please no 19:22:33 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 nirik: So that's the piece I threw in there but we and KDE SIG need to discuss. 19:22:57 notting, default editor spin. postfix vs. sendmail. kvm vs. xen for a virt product. 19:23:01 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 notting, you clearly are not thinking hard enough. 19:23:05 nirik: 3 products + a spin, why not? 19:23:20 ltinkl: you said, something I interpreted as roughly "KDE Spin hsould continue to get the status quo treatment". 19:23:22 jwb: i'm saying those would get dismissed out of hand. at least, i HOPE they would 19:23:46 notting, by whom? 19:23:48 the Board? 19:23:49 mattdm: It's a bit OT, but IMHO Workstation is a very bad environment for a developer to develop on. 19:23:51 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 mitr: because then we have the problems of differentation and mixed messaging added to. 19:24:15 Could we ... not talk HTML in this meeting? 19:24:18 GNOME Shell is not configurable enough, and GTK+ is also not as nice a platform to develop for as Qt. 19:24:19 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 jwb: saner minds, i guess. 19:24:40 (and yes, I've worked with both) 19:24:43 abadger1999: what jreznik said 19:24:44 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 notting, sanity is not required to participate in Fedora. 19:25:08 (some would argue it's detrimental) 19:25:11 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 nirik: I'm ok with that but I'd like to have direct link to spins from the main product page 19:25:15 Kevin_Kofler: sort of an entirely different discussion than the one we're actually having. 19:25:19 ltinkl, jreznikSo that's what you don't want. But what do you want? 19:25:45 nirik, jreznik I think we can have a special category for spins with aspirations 19:25:56 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 mattdm: works for me 19:26:10 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 abadger1999: I'd really rather leave specific questions of websites to the websites team 19:26:19 abadger1999: I'd go with similar way we have now - there's GNOME spin + links to other spins 19:26:21 abadger1999: presented along side with the current 3 products, as a specially purposed (aspiring) product/spin 19:26:28 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 sgallagh: I think F21 is a transitional release. And so we have to make compromises for this release. 19:27:24 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 abadger1999: I am +1 to your proposal, if we strike the last sentence. ;) 19:27:28 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 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 jreznik: ye but in that case, Cloud is a _very_ specific product :) 19:28:12 I think we definitely want a link somewhere on the front page. 19:28:21 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 We also definitely need kde.fedoraproject.org to keep working, many people are using that link. 19:28:39 abadger1999: well, I'm ok with link 19:28:43 same as it's now 19:28:46 (although jreznik, I think you said "yes" to both having it on the page and having it removed fro mthe page) 19:28:47 so status quo 19:29:02 (could be a redirect to a new plasma.fedoraproject.org, of course) 19:29:29 abadger1999: as I said - status quo for f21 - blocking spin, link from get.fpo 19:29:29 kde doesn't appear now on the 'main page' that I see 19:29:37 nirik: yep, see above 19:29:56 http://fedoraproject.org/get-fedora#desktops 19:29:56 jreznik: not seeing? repeat please? 19:30:06 Are we seriously attempting to micro-manage the website design? 19:30:17 sgallagh: seems so. 19:30:34 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 How about we let websites work with kde spin folks and if people are unhappy we can revisit? 19:30:42 We (KDE SIG) have seen what happens if the Websites team get free reign. 19:30:48 nirik: I was just typing that 19:31:03 sgallagh: We have the precedent of the Board doing that ;-| 19:31:15 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 Lets try this once again... votes on abadger1999's proposal? 19:31:18 sgallagh: no -- we're determining the requirements to hand to the websites team. 19:31:22 Whether our product/spin/pre-product/whatever will be actually visible to users is not an irrelevant detail. 19:31:24 mitr: We haven't overthrown the Board yet, so let's please just stop this 19:31:44 nirik: +1 to work with websites guys 19:31:44 mitr: thanks. and if it doesn't pass, then we can vote on it with the last sentence struck/modified/etc. 19:31:54 sgallagh, yet! there is still hope! 19:32:00 jreznik: well, it's not really directly on there, it's hidden under a desktops tab 19:32:10 um, could we have a repeat of the proposal? (abadger1999) 19:32:28 abadger1999: 0 at this point, mainly because "establish milestones" doesn't actually say what we want the product to do / be. 19:32:32 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 -1 19:32:36 * ltinkl scrolls back for the proposal, getting lost a bit 19:32:45 ... And I still think that the WG should have some time to discuss this 19:32:49 abadger1999: +1 19:32:49 pjones: Do you want to expand on "establishing milestones" ? 19:33:12 abadger1999: I was thinking that'd be an action item /after/ we agree on that as a general course 19:33:30 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 abadger1999, +1 19:33:40 (the milestones need not be temporal) 19:33:41 mitr: Would that satisfy you? It's similar with the way we handled promoting arm to primary arch. 19:33:56 I guess I'm -1 on that; I'd like the board to weigh in on the bigger question first 19:33:57 +1 19:33:59 pjones, abadger1999: that would work I suppose 19:34:25 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 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 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 So we are at +4-2 19:35:50 More votes? 19:35:54 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 jreznik: That's what it originally was, before mjg59 came up with that hardcoded list of 3 Products. 19:36:34 mattdm: +1 (but not going so far as requiring that ATM) 19:36:59 Kevin_Kofler: Just to be fair, the "hardcoded list" came first, as that was the output of discussions at Flock 19:37:13 Kevin_Kofler: wasn't mjg59 19:37:18 So I was misled by the chronology of blog posts. 19:37:22 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 with the caveat that we still need a board decision, of course. 19:37:39 Kevin_Kofler: Making it a permanent list was never stated at that time, though 19:37:47 pjones: to abadger1999's proposal? 19:37:53 yes 19:37:58 and to abadger1999's proposal can be attached to that as a followup 19:38:14 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 #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 mattdm: yeah, I'm trying to write your broader question into a second proposal now. 19:38:26 mattdm: we can just say it's provisional and we'll consider re-affirming it when the board votes? ;) 19:38:27 or alternately, since abadger1999's proposal passes, to attach the broader question to that :) 19:38:44 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 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 abadger1999 yes but oooh put some of notting's wording into it :) 19:39:29 abadger1999: do you think we could ask anything more broad and open ended? 19:39:44 because in the past, that has worked great with the board. 19:39:51 We always get back coherent, helpful answers when we do that ;) 19:40:08 pjones Board: meaning of life? please advice. 19:40:09 pjones: Yeah, good point there. 19:40:13 notting: well, Board can overrule this agreement and say "no, we don't want it" 19:40:15 abadger1999: Why does this question even matter to FESCo? 19:41:05 mitr: it informs *a lot* of the decisions we need to make and coordinate. 19:41:15 * mattdm agrees 19:41:18 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 pjones: +1 19:42:05 and those are nice questions, because they're questions you can tell if have been answered or not ;) 19:42:08 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 those questions should have been asked right from the start, even for the current 3 products 19:42:49 were they? 19:43:14 mitr: fesco's interactions with websites and marketing affect that. 19:43:23 ltinkl: they were somehow 19:43:26 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 mitr: for isntance, fesco weighed in on multi-desktop dvds. 19:43:40 did the Board decide on the e.g. Cloud product? 19:43:46 ltinkl: yep 19:43:57 ok 19:43:57 it did 19:44:01 proposed as part of all three products 19:44:20 So, next steps? 1) ask the board, 2) establish goals/milestones, something else? 19:44:21 but they did consider each one individually 19:44:47 * mitr is +1 to question wording by pjones 19:45:10 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 do we need to elaborate on "b"? 19:45:35 ltinkl: well the original proposal was "recommend to consider" i.e. "ask" 19:46:01 mattdm: We do need to agree on what the goals are IMHO. Not necessarily today. 19:46:11 mitr: "that they consider", notice the use of conjunctive there 19:46:26 okay, let me try this again: 19:46:28 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 pjones: the second part perhaps is even more general than what I had written? 19:46:56 I'd like to actually file a ticket with the board this week. 19:47:13 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 abadger1999: the board needs to limit us here. We need constraints from them as guidance. 19:48:15 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 I'm okay with delegating someone (abadger1999, pjones, both?) to file that ticket 19:48:47 because I think we *basically* agree on what it should say 19:49:14 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 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 I really don't think that's better. 19:49:37 k 19:49:43 We are at +3 for the questions by pjones, +4 with pjones implied. So let's ask those and move on? 19:49:55 is that counting me? 19:49:57 +1 if not 19:49:57 mitr: Am I counted there? If not, +1 19:50:06 mattdm: it wasn't. 19:50:09 I oculd be +1 for pjones if we add something specific about the constraint we're talking about. 19:50:33 proposal -- add us all to cc for the board ticket and we can clarify as needed 19:50:33 Something along the lines of the "In particular[..]" that I wrote above. 19:50:36 #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 could that be rephrased as: what should new product proposals to the board contain before we submit them? 19:50:57 I'm reasonably willing to trust that the Board is sufficiently competent to understand what "constraint" means. 19:50:58 mattdm: +1 to that 19:50:59 abadger1999: Those "in particular" are really non-obvious to be the only reasonable alternatives 19:51:25 mattdm: +1 no matter what else we decide. 19:51:31 mattdm: +1 19:51:34 mattdm: +1 19:51:38 mitr: sure. but do they sum up the only ones that were mentioned today 19:51:40 ? 19:51:45 mattdm: +1 19:51:51 mattdm: yes 19:51:54 mattdm: +1 19:51:57 mattdm: Will you file the ticket then? 19:52:09 I'm a bit confused here :) 19:52:21 aw crap :) 19:52:24 mattdm, +1 19:52:26 i mean, sure :) 19:52:29 [20:51] [20:38] agreed recommend to the board that they consider this product for F22 19:52:35 #action mattd to file the board ticket 19:52:40 ltinkl: For KDE in particular, (1) in F21 we do not expect to ship a Plasma Product. 19:52:40 [20:50] agreed Ask the board a) are they actually okay with a Plasma product in F22 19:52:46 #undo 19:52:46 Removing item from minutes: ACTION by mitr at 19:52:35 : mattd to file the board ticket 19:52:53 #action mattdm to file the board ticket 19:52:53 (2) We want the board to consider it for F22 19:53:17 (3) We are going to ship a KDE Spin that blocks the release and is listed on the download page. 19:53:20 and this last part has been higher level talk about any new products, not kde in particular 19:53:50 (though the wording on (3) left some wiggle room; it could be a Plasma spin instead.) 19:53:51 ltinkl: These latest proposals to take to the Board are only indirectly related to kde. and likely will not affect F21. 19:53:55 ltinkl: AFAICS the two parts are actually asking the same thing 19:54:13 mitr: but they kinda contradict each other in wording 19:54:30 pjones: Correct. KDE Spin could be renamed. 19:54:37 ltinkl: No, they don't imply FESCo's position on the matter. 19:55:14 Proposal: Leave the ticket open, discuss goals/milestones on devel@, to be voted on next week. 19:55:30 mitr: +1 19:55:37 * mitr is +1 for the record 19:55:39 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 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 mitr: -1 Please don't make us go through this again next week 19:56:14 sgallagh: do you have a counter-proposal to get those goals established? 19:56:16 sgallagh: well, we're already on the hook for some form of setting milestones. he's really just formalizing that AFAICS 19:56:33 though that could reasonably be a different, specifically worded ticket. 19:56:35 mitr: I think sending this to the Board as discussed is enough to close it... 19:56:38 sgallagh: sorta agree -- I'd say we discuss it when the Board comes back to us with some guidance. 19:56:44 ltinkl that's redundant, not contradictory. 19:56:47 abadger1999: Yes 19:56:52 abadger1999: +1 19:57:11 ltinkl: I kind of think you're splitting the hairs a bit fine here ... 19:57:15 I am assuming we want *one* board ticket for these two proposals? or do we want two? 19:57:20 sgallagh, abadger1999: OK. I'm withdrawing that, and let's keep the ticket open until the board comes back. 19:57:28 wfm 19:57:29 ok 19:57:30 mattdm: I'm okay with one, I guess. 19:57:37 #topic #1266 Updates to the non-responsive policy 19:57:39 .fesco 1266 19:57:40 mitr: #1266 (Updates to the non-responsive policy) – FESCo - https://fedorahosted.org/fesco/ticket/1266 19:57:41 https://fedorahosted.org/fesco/ticket/1266 19:58:03 I agree with everything mitr said in the tickets. 19:58:41 Generally I agree with the invalid e-mail fasttrack; without the extra FESCo ticket I could be +1 19:59:20 so, it would be a bugzilla bug? 19:59:23 For orphaning everything as the result, undecided leaning towards +1 19:59:24 or just email to devel list? 19:59:44 nirik: The current process is just email to devel, followed by FESCo action at the _end_ of that process. 20:00:17 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 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 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 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 mitr: ... the not nice thing is it's easy to ignore 20:01:00 pjones: yes to both 20:01:08 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 t8m: Wellll how often is it actually useful to non-responsive-maint a single package instead of all of them? 20:01:58 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 mitr, I suppose there might be a case where maintainer does not care about some package but works on others? 20:02:35 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 sure, although if thats the case you would think they would just orphan it and hand it off. 20:02:55 t8m: there's certainly asymmetry of workload within individual maintainers. 20:03:08 (please don't look at my packages for examples ;) 20:03:10 mitr: ah -- my intention was to coninute to leave that separate (it's a problem but a spearate problem) 20:03:16 nirik, yeah, maybe that would be incentive to orphan things that you do not care about at all 20:03:20 I just wanted to mass orphan for invalid email. 20:03:57 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 all the timeouts in the process mean that many people don't bother, or just go part way and forget 20:04:07 abadger1999: Ah, OK; as two section headers on the same level I viewed them as independent 20:04:07 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 mitr: they are independent -- It seems I probably need to change the wording in the second section? 20:04:39 abadger1999: yes 20:04:45 pjones: sure. Could be a number of other reasons too... 20:05:05 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 sure. 20:06:39 Does this read better now: https://fedoraproject.org/wiki/User:Toshio/Nonresponsive_maintainers_policy#Orphaning_Process 20:08:27 wordsmithing over IRC... 20:08:29 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 reads ok to me 20:08:38 sure, +1 20:08:51 mitr: +1 20:08:55 on both counts. 20:09:06 mitr, +1 20:09:08 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 is ready to +1 anything at this point :) 20:09:25 +! 20:09:27 +1 20:09:43 mattdm: Proposal: mattdm takes over all non-responsive maintainer packages :) 20:09:50 +1 but note -- as applied to a single package, that's the orphaning process that we'd follow as well. 20:09:56 sgallagh: sold 20:10:15 abadger1999: good point 20:10:17 mitr: +1, in all seriousness 20:10:54 With all the edits... 20:10:56 Proposal: changes as made on Toshios' page approved 20:11:05 also +1 20:11:08 +1 20:11:12 +1 20:11:14 +1 20:11:28 abadger1999: will you update the page? 20:11:36 +1 20:11:40 mitr: yeah, make it my action. 20:11:41 #agreed Proposal: changes as made on Toshios' page approved (+6) 20:11:53 #action abadger1999 to update the nonresponsive maintainer policy page 20:11:55 thanks 20:12:05 #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 #info dgilmore will chair next week's meeting 20:12:51 sgallagh: if you want I can do the week after 20:12:57 done :) 20:12:58 dgilmore: I think that's Summit. 20:13:14 #topic Open Floor 20:13:15 sgallagh: okay, not something ive ever been to 20:13:16 Ah no, that would be one after that 20:13:22 Anything for open floor? 20:13:43 I fly out to a conference April 7, then vacation, won't be back until April 27th. 20:14:22 abadger1999: Enjoy your vacation 20:14:41 I had one small thing... 20:14:45 I'll try thanks :-) 20:14:58 At /some/ point I'm going to take some post-rhel-7 vacation, but it's not clear when yet. 20:15:09 so just, you know, vague fyi 20:15:31 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 this is re: https://bugzilla.redhat.com/show_bug.cgi?id=1064537 20:16:15 I asked about guidelines and was told none were being written :-/ 20:16:31 there are at least some places where they would definitely make sense. 20:16:42 "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 :-( There should be some.... we have socket activation and such.. is this not just "time activation"? 20:17:05 Right, but I asked for a migration guide and was told that there isn't a direct analog 20:17:18 That new timer units would have to be written on a case-by-case basis 20:17:26 https://fedoraproject.org/wiki/Packaging:Systemd#Activation 20:18:06 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 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 nirik, the cron jobs run by default and we are not creating new ones within this Change 20:18:50 nirik: It... can't get worse than it was with cron? 20:18:53 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 mitr: I don't need a migration guide, just a packaging guideline 20:19:34 nirik: These detailed questions fall under the general umbrella of "have packaging guidelines" IMHO 20:19:35 ok 20:20:06 mitr: right. Just wanted to make sure I didn't misunderstand and should be applying these now without those guidelines existing. 20:20:44 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 ... about writing the guidelines they have already planned to, that is 20:21:41 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 so sure, if someone would remind them that would be great. 20:23:37 #info for cron-to-systemd-time-units, please make sure the necessary packaging guidelines are approved before commiting the patches. 20:23:39 Sufficient? 20:23:56 sounds great to me. 20:24:02 worksforme 20:24:10 Anything else for open floor? 20:24:39 I'll close the meeting in 2 minutes if not... 20:26:47 Thanks everyone! 20:26:48 mitr: Thank you for chairing this long meeting. 20:26:49 #endmeeting