15:01:12 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-01-10)
15:01:13 <zodbot> Meeting started Fri Jan 10 15:01:12 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:19 <haraldh> <-
15:01:20 <pknirsch> #meetingname  Fedora Base Design Working Group
15:01:20 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:23 <jwb> hello
15:01:33 <pknirsch> good morning and good afternoon folks!
15:01:40 <haraldh> hi
15:01:46 <pknirsch> #chair jwb haraldh
15:01:46 <zodbot> Current chairs: haraldh jwb pknirsch
15:01:49 * masta is here
15:01:53 * jreznik is here too
15:01:54 <pknirsch> i hope everyone had a great holidays?
15:02:01 <jwb> yep
15:02:02 <pknirsch> #chair masta jreznik
15:02:02 <zodbot> Current chairs: haraldh jreznik jwb masta pknirsch
15:02:24 <pknirsch> same here. though too much food :)
15:02:25 <jreznik> yep, wish holidays were a year long :)
15:02:28 <pknirsch> hehe
15:02:51 <jreznik> pknirsch: first soccer match this year after break was... pain :)
15:03:06 <masta> dgilmore: ping
15:03:14 <pknirsch> i can imagine :) i managed to at least step out of the house every day at least once :P
15:03:16 <notting> jreznik: the "i need to either do this more often or not at all" pain?
15:03:25 <pknirsch> #chair notting
15:03:25 <zodbot> Current chairs: haraldh jreznik jwb masta notting pknirsch
15:03:49 <jreznik> notting: yes, that one :)
15:04:55 * Viking-Ice drinking the latest brew from the factory whale beer ;)
15:05:02 <pknirsch> O.o
15:05:10 <pknirsch> that sounds, "interesting" :P
15:05:47 <haraldh> Viking-Ice, stop killing whales and sharks with your bow! :)
15:06:23 * dgilmore is here
15:06:32 <pknirsch> #chair dgilmore
15:06:32 <zodbot> Current chairs: dgilmore haraldh jreznik jwb masta notting pknirsch
15:06:39 <pknirsch> okidokie, lets get started then.
15:06:46 <pknirsch> #topic Buildreq cleanup updates and further discussion/actions
15:09:27 <pknirsch> so i got dragged into other stuff during my holidays so didn't get to work on much over the past weeks unfortunately, so no updates from my side yet regarding progress. The points i have on my list are running rjones' autobr script on fedora packages and check what additional brs there are and writing a script to do rebuilds with 1 br dropped each time and verifying with rpmdiff and other tools if it's at least looking sane.
15:10:10 <pknirsch> i hope to get to it soon, but i got pulled into other work this and next week, so probably not much coming from me the next week either
15:10:38 <dgilmore> okay.
15:10:45 * pknirsch mumbles something about having to dance on too many weddings at once
15:10:57 <dgilmore> pknirsch: but think of all teh cake :)
15:11:20 <pknirsch> dgilmore: heh :) i think back in horror to all the cookies i had over xmas :)
15:11:25 <dgilmore> pknirsch: it slikely going to be a long term project to reduce things
15:12:15 <pknirsch> dgilmore: right. and i think Viking-Ice and others have pointed out that for the long run we should also propose some additional FPC guidelines that require packagers to limit BRs to a minimum
15:12:49 <pknirsch> otherwise this effort will be creeping back over time and we'd have to do it over and over again
15:13:11 <pknirsch> or maybe integrate something that can check this in the successor of AutoQA, but not sure if thats feasible
15:14:30 <dgilmore> pknirsch: maybe
15:14:51 <haraldh> so, automated checks or quarterly review?
15:15:10 <pknirsch> i'd love to get this automated, but i'm not sure if thats possible
15:15:11 <dgilmore> pknirsch: i think packages should require bootstraping functionality if needed. and we should work to enable smaller functional rpms
15:15:28 <dgilmore> but i dont want to go to the debian level of every .so in its own rpm
15:15:34 * pknirsch nods
15:16:10 <haraldh> what we would need is split src.rpms ... not split rpms
15:16:28 <dgilmore> auto rpmdiff, abi checks, soname warnings etc should be in autoqa's replacement
15:17:03 <dgilmore> haraldh: split srpms mean extra work, in some places it wont matter
15:17:32 <dgilmore> i guess in Matts Ring proposal it depends where the package falls
15:17:40 <pknirsch> mhm
15:17:45 <haraldh> well, if you don't want to pull in buildreqs for a e.g. GUI subcomponent..
15:18:15 <Viking-Ice> pknirsch, one thing over the holidays did you manage to reach out to the maintainers of those 2k packages?
15:18:23 <dgilmore> something in Base its fair to split into 2 or 3 srpms
15:18:37 <pknirsch> Viking-Ice: not yet, but it's also on my list
15:18:39 <jwb> there's recently some discussion of putting tests in %check.  that will also potentially bring in extra BRs
15:18:46 <dgilmore> something thats a far outlier package we should keep things easier for them
15:19:13 <jwb> s/putting/running
15:19:24 <pknirsch> hm, true, i remember that thread jwb
15:19:30 <misc> jwb: this could be made conditionnal
15:19:56 <jwb> misc, on what?
15:20:27 <misc> jwb: if build for the mirror, then the tests are disabled, and ran on another system, with more BR avaliable
15:20:58 <jwb> misc, so conditional and disabled by default.
15:21:24 <jwb> which means it won't actually catch the things people want to put the %check stuff for there in the first place, which is to prevent builds from koji going out broken
15:21:36 <misc> jwb: we could want to have it ran if that's mock on a developper system or something like this
15:21:47 <jwb> which makes it pointless because you can just install the package after build and run the tests yourself
15:22:08 <misc> or do the build twice, one with check and one without, the without being the one pushed, with less BRs
15:22:38 <jwb> it's possible to do this, but i doubt it's valuable.
15:23:10 <dgilmore> i guess it depends on the BR's and how big they are
15:23:40 <pknirsch> hm, actually, wasn't the new tool going to use some tests commited to git instead of using %check? i think i read something along those lines, but i might be mistaken
15:23:48 <misc> we would have reduced BR in the final rpm, and still have the tests, to the expense of building twice ( unless we do some hack like using --short-circuit )
15:24:01 <jwb> pknirsch, that's what people are pushing for
15:24:04 <misc> pknirsch: that was also a proposal, yes
15:24:07 <dgilmore> i dont think we should tear out things that are useful really just to reduce something
15:24:28 <jwb> misc, the tests can be packaged regardless.  it's running them in %check that is the problem area and doing that conditionally doesnt' really buy much
15:24:36 * pknirsch nods
15:24:42 <dgilmore> and the BRS for something in %check have zero effect on the resulting size and its deps
15:25:00 <dgilmore> which ultimately that is what we want to solve
15:25:07 <jwb> dgilmore, they have an effect on what is required to be self-hosting
15:25:09 <dgilmore> allow for a smaller BAse
15:25:13 <jwb> no
15:25:19 <jwb> install size is not what we're discussing
15:25:26 <jwb> people really need to stop equating the two
15:25:29 <dgilmore> jwb: yes that would need included in the self hosting base
15:25:40 <dgilmore> jwb: im not equating the two
15:25:51 <jwb> 10:24 < dgilmore> and the BRS for something in %check have zero effect on the  resulting size and its deps
15:26:06 <dgilmore> jwb: i guess we should say we are trying to do two things
15:26:08 <jwb> if you mean BRs for %check don't increase the number of packages required to be self-hosting, i think you're wrong
15:26:23 <jwb> if it's brought in as a BR, it increases the size of Base
15:26:31 <dgilmore> making the size of teh self hosting base smaller, and the size of a minimal install smaller
15:27:10 <dgilmore> jwb: 15:24 < dgilmore> i dont think we should tear out things that are useful really just to reduce something
15:27:11 <Viking-Ice> regarding testing/automation It's best that you go through these meeting minutes https://lists.fedoraproject.org/pipermail/qa-devel/2014-January/000603.html with automation having the automation is a higher priority of them all
15:27:30 <dgilmore> jwb: if the value in having it is worth it then its worth it
15:27:40 <dgilmore> i guess i made my point poorly
15:27:52 <pknirsch> thanks Viking-Ice
15:28:19 <pknirsch> ah right, Taskotron
15:28:25 * pknirsch remembers now
15:29:59 <pknirsch> Viking-Ice, do you know if Taskotron is focusing on promoting %check usage in specfiles or using tests commited to git ?
15:30:05 * pknirsch can't find it there
15:30:27 <jwb> i think the latter is the plan, but it's really just being discussed
15:30:28 <Viking-Ice> https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan#Phase_1:_AutoQA_Replacement
15:31:01 <pknirsch> ah, so it's post package build external testing, thanks!
15:31:54 <masta> BRs for %check seem negative to me... in my Utopian fantasy world I'd rather have some kind of TestRequire syntax in spec, but that is probably crazy talk
15:32:12 <Viking-Ice> right
15:32:18 * pknirsch nods
15:32:43 <notting> masta: i thought that was a RFE to rpm and one point
15:32:46 <notting> s/and/at/
15:32:51 <pknirsch> but as %check isn't being strongly encouraged now with the new Taskotron we should be fine
15:33:15 * Viking-Ice nod
15:34:03 <pknirsch> alright, lets move on to the next topic as we're already in half an hour.
15:34:33 <pknirsch> #topic Inter WG topic: Stable application runtimes
15:34:56 <pknirsch> so i wanted to bring this up as this is most likely something that will be landing in our lap obviously at the end.
15:35:34 <pknirsch> I don't think though there is much to discuss at this point. I just saw that the various WGs all prefer different container technologies so far, which is a bit of a bummer
15:35:54 <pknirsch> and i'd personally love to avoid having to support all variants of container tech
15:35:58 <pknirsch> in Base
15:36:21 <Viking-Ice> base/core should only concern itself with what systemd brings to the table
15:36:27 <pknirsch> and iirc Base already at least provides the systemd one, right?
15:36:32 <pknirsch> as Viking-Ice just said :)
15:37:11 <pknirsch> Does anyone know what libvirt-lcx uses? Is that based on systemd containers?
15:37:17 <Viking-Ice> yes
15:37:26 <mitr> IMHO containers don't give you stable and secure runtimes; has that been missed or do you disagree?
15:37:27 <pknirsch> cool, that's perfect then.
15:37:39 <haraldh> what we might want to define at some point of time, is a fixed d-bus api, desktop api, wayland/X protocol API
15:37:52 <haraldh> for a given base or product
15:37:57 <pknirsch> haraldh: in base?
15:38:01 <haraldh> yes
15:38:03 <pknirsch> hm
15:38:06 <haraldh> d-bus API for systemd
15:38:10 <haraldh> for example
15:38:23 <pknirsch> sure, but X API seems a bit far off of base, no?
15:38:24 <haraldh> or config file syntax
15:38:36 <haraldh> pknirsch, sure.. not for base
15:38:59 <notting> well, if the only stable runtime is what's provided in base, then we've got it easy. might be a bit of a problem for uptake, though.
15:39:02 <haraldh> but a desktop product might want to specify s.th. like GNOME 4 API
15:39:05 <pknirsch> mitr: i certainly don't disagree
15:39:19 <pknirsch> right haraldh
15:39:27 <mitr> Also, if we declare the already stable runtimes as stable, we are not really solving the problem
15:39:36 <pknirsch> hehhe
15:39:45 <pknirsch> "Look! Stable is stable!"
15:39:45 <pknirsch> :)
15:39:48 <mitr> (Long-term, the right solution clearly _is_ to provide a stable runtime; but all the application developers are choosing the unstable ones)
15:40:37 <mitr> (... thinking particularly of web apps now)
15:40:46 <pknirsch> mitr: i remember Dan Walsh's comments about container tech and security :)
15:40:51 <pknirsch> yea
15:41:24 <pknirsch> the question is whether we require containers to be secure
15:42:12 <masta> that seems to be a plus, secure containers
15:42:28 <Viking-Ice> pknirsch, dan walsh talk at flock was a bit outdate as well as not entirely correct in the container vs virtual comparison
15:43:18 <mitr> pknirsch: Users require their servers to be secure; the question is whether this is should be up to each individual application developer watching upstreams of their dependencies (because historically that kind of watching has been what the distributions do)
15:43:20 <abadger1999> pknirsch: Re: X API... I would see that as something Base could do.... Base is more than just Product to me.
15:43:38 <abadger1999> It's also setting expectations for what a Fedora Release is.
15:44:03 <abadger1999> which could certainly extend to something as core as the API of X
15:44:20 <pknirsch> sure, i just wonder where the API definiton of Base would end.
15:44:25 <mitr> Saying "security of contents of containers is not our promise; we hear JBoss will give you a secure application server, and stay away from $modern_language" would be consistent, but I suppose not popular
15:45:04 <pknirsch> Viking-Ice: hm, how so?
15:46:06 <Viking-Ice> I will have to go through his slide to point to the errors he made but containers aren't secure as things stand now
15:46:18 <pknirsch> right
15:46:24 <pknirsch> as mitr pointed out
15:46:41 <abadger1999> pknirsch: <nod>  Yeah -- I think it's bigger than the packageset that would ship in a "base product" but I'm not sure where it ends either.
15:46:45 <pknirsch> abadger1999: so where would you draw the line for API definitions that base provides
15:46:46 <mitr> Viking-Ice: security of how containers are isolated from the rest of the OS is yet another, separate, concern - and we wouldn't need that to get stable applicaton runtimes via containers
15:46:48 <pknirsch> ah
15:47:14 <pknirsch> right mitr
15:47:29 <abadger1999> pknirsch: "Things that are core to Fedora" :-)  which just moves the question to "what is 'core'?"
15:47:30 <pknirsch> and stable application runtimes doesn't mention "security" ;)
15:47:30 <Viking-Ice> mitr, right you would need that to get *secure* stable applicaton runtimes via containers
15:48:42 <Viking-Ice> abadger1999, core is minimal bootable system anything on top of that is definable per person thus subjected to debates
15:48:43 <pknirsch> abadger1999: hehe, right.
15:49:18 <notting> abadger1999: every question is just a matryoshka doll of more questions?
15:49:37 <abadger1999> Viking-Ice: I don't agree with that for the purposes we're talking about here.  And some debate is okay for this....
15:49:44 <jwb> i can boot a system with a kernel and a shell.  that's two packages.  i guess we're done
15:49:50 <pknirsch> :)
15:50:31 <abadger1999> like smtp daemon and syslog daemon -- those are things that I htink Base WG should look at.  The decision could be, "these are not core to the Fedora platform", though :-)
15:51:10 <Viking-Ice> I would say since that by the method that was chosen and resulted in 2k packages is what base "supports" if it's a component api and what not outside whats in those 2k packages your are on your own
15:51:26 <Viking-Ice> or rather falls into the spectrum of another WG
15:51:59 <abadger1999> I think I'd say there's a difference between what Base supports and what Base specifies.
15:52:17 <pknirsch> hm
15:52:24 <abadger1999> Base can support (ship, maintain, own) a minimal packageset.
15:52:28 <pknirsch> that gets rather complicated then though
15:52:36 <pknirsch> wouldn;t it?
15:52:38 <Viking-Ice> I would say what Base supports and what Base specifies can never be outside those 2k packages
15:52:53 <haraldh> Viking-Ice, agreed
15:53:13 <abadger1999> But they might also specify "If you ship X in you product in Fedora 21, it should implement API $version"
15:53:48 <haraldh> abadger1999, why not make a meta "base + X" specification?
15:53:59 <haraldh> which all products use, which ship X
15:54:20 <abadger1999> haraldh: Sure.  That's fine.  I'm just saying I think Base WG is the place where that specification should be discussed.
15:54:30 <haraldh> might be true
15:54:35 <abadger1999> Cool.
15:54:44 <notting> abadger1999: wait, wasn't the idea to define what fedora 21 even *was* in relation to X number of products?
15:54:54 <notting> (given that '.next' implies it may not even be 21)
15:55:03 <Viking-Ice> it wont be 21
15:55:07 <Viking-Ice> I think that is clear
15:56:02 <abadger1999> notting: Sure.  And isn't deciding what the core expectations of any Fedora ($version) system are that definition?
15:56:35 <abadger1999> Viking-Ice: <nod>  I don't disagree... but until we have another name for it, we have to call it something.
15:56:57 <haraldh> but, is it "Fedora.Base.21 + Fedora.Desktop.1" then? :)
15:57:57 <jreznik> abadger1999: we already have "If you ship X in you product in Fedora 21, it should implement API $version" - you're usually out of game if you don't implement it (last time it was bluez 5)...
15:58:10 * jreznik was dragged out by my boss :(
15:58:24 * pknirsch nods
15:58:44 <abadger1999> haraldh: I don't know :-)  [It could be.... we don't number previous Fedora versions after the version of any of the sub-components it ships]
15:59:03 <Viking-Ice> we dont have resources to deal with any of the output from the WG's not us ( QA ) not Releng and not Infra, in all three service sub communities we have maybe 20 people "active" in each of them and from our and only Tim and Josef are currently working on automation and in addition to that I have yet to see any buy inn from maintainers to lot of topics being discussed by the WG's just the contrary people planning to ignore that output let alo
15:59:03 <Viking-Ice> ne being signed up supporting their components for x period of time ( hence I asked pknirsch to first all the maintainers in those 2k packages before anything get's decide )
15:59:42 <abadger1999> jreznik: <nod>  I agree totally.
16:00:13 <jwb> we talk a lot, but we've yet to actually do anything as a group.  maybe we could focus on one thing and actually do it
16:00:54 <masta> Hey folks, you have given me a lot of thoughts to ponder after this discussion ends, which for me is right now (hard stop). Thanks!
16:01:16 <masta> will catch up on the meeting logs later
16:01:55 <jreznik> jwb: we should call working groups to talking groups
16:02:09 <jwb> i'll resign if that's what this is
16:02:10 <Viking-Ice> jwb, right before anything is done you have to ensure that there is will to do anything from the people involved or would be affected by any decision making which was why pknirsch was planning to reach out to the maintainers of those 2k components ( which is the right thing to do above everything else )
16:02:44 <jwb> Viking-Ice, i don't disagree with that.  though 2k is the starting number we're trying to reduce from
16:03:42 <Viking-Ice> jwb, right and you cant know to what extent we can reduce those components *until* you have started dialog with their maintainers to see to what extent they would be willing to do or can do for that matter
16:04:22 <haraldh> and we don't have a defined method to reduce the BRs, yet... do we?
16:04:41 <jwb> haraldh, communicating the goal is different from telling them how to do it
16:05:13 <jreznik> jwb: but it's a good idea to focus on one thing for now - quick survey among base wg members what should be that real one? that build reqs pruning? going back to the beginning and defining what base should be for other products? /me is more for the second
16:05:18 <haraldh> so, task before the next meeting: make a list of the maintainers of the 2k packages?
16:05:27 <Viking-Ice> haraldh, technically we cant and we should wait for their input maybe they have some great ideas on what can be achieved that this group has not thought of
16:06:22 <Viking-Ice> jwb, you cant tell anybody to do anything in an open community if or when that start people will simply walk away from contributing in this case orphan their package
16:06:29 <haraldh> also email them questioning for ideas to reduce the BRs of their package and probably join the next meeting
16:06:40 <Viking-Ice> /me nods
16:06:40 <jwb> jreznik, we already defined that
16:06:50 <jwb> jreznik, see "What is Base" here: http://fedoraproject.org/wiki/Base
16:07:33 <haraldh> also interesting what be the number of BRs for every of those 2k packages
16:07:40 <jreznik> jwb: defined - yes, but did we agree on that with other groups? do they accept our definition?
16:07:53 <haraldh> and usage number of other packages
16:07:58 <Viking-Ice> jreznik, I would think they have no saying in it
16:08:01 <haraldh> then find the low hanging fruits
16:08:02 <Viking-Ice> ( other groups )
16:08:17 <jwb> jreznik, well asking ourselves that is just talking in circles.  the other WGs actually need to be asked and not in this meeting
16:09:49 <notting> Viking-Ice: we tell people to do stuff all the time. "your stuff must build to be shipped". "you must use git to commit to the packages", etc.  leadership needs to lead, set direction, policies, etc. yes, people may decide to leave, but you can't do nothing in fear of that.
16:10:02 <haraldh> hmm, maybe by parsing the build logs, we can easily get the number of installed packages in mock
16:10:04 <Viking-Ice> I'm not foreseeing how their input is relevant because it can just end one way they either want to add something to base/core or remove something from base/core ( just think cloud vs workstation different needs from base/core )
16:10:05 <jreznik> jwb: that's my point, we set it, moved forward, done and I'd really to hear some feedback
16:10:23 <Viking-Ice> notting, telling them yes having them follow it no
16:10:33 <jreznik> but on the other hand I like other ideas that are worked on/(talked)
16:10:56 <Viking-Ice> fesco does not have the ability to force anything last time I checked
16:11:21 <jwb> Viking-Ice, not asking the consumers of Base if it meets their needs is like not asking the maintainers if they're willing to do work to reduce BRs
16:11:46 <jreznik> yep
16:12:17 <pknirsch> any volunteers for that then?
16:12:20 <Viking-Ice> jwb, quite the contrary the WG's will have to add or remove anything that is not brought in by those 2k components
16:13:03 <jwb> sigh.  yeah, defining a Base that doesn't work for the products is really a great way to start out
16:13:30 <haraldh> well, we will have revisions anyway
16:13:38 <pknirsch> as i strongly agree with jwb's point that our work and "final" definitons needs to be a dialog with the other WGs
16:13:38 <notting> ? we need buy-in from the packagers to make changes in what we do, but we don't need buy-in from the creators of our end-user deliverables that we're building something useful?  that seems impressively backwards. unless fedora only exists to serve its packagers.
16:13:59 <jwb> pknirsch, technically jreznik's point.  i just think this meeting is the wrong place to have that discussion
16:14:28 <Viking-Ice> jwb, the products the wg's are delivering have different requirements from base which means with your approach we will have to server them all and in addition to that each of the products might have different life cycle so how to you suggest base will be able to deal with that?
16:14:52 <Viking-Ice> s/to you/do you
16:15:21 <jwb> they have _additional_ requirements.  that doesn't mean we shouldn't try and find commonality between them
16:15:24 <pknirsch> jwb: right. isn't the FESCO meeting on Wednesdays where all WGs have a representative?
16:15:31 <jwb> pknirsch, yes
16:15:43 <pknirsch> jwb: there we could present the current ideas and add that to the FESCO agenda.
16:15:49 <mitr> Viking-Ice: yes base has to serve them all otherwise it _is'nt_ a base; As for lifecycles, FESCo has decided on keeping a single lifecycle by default
16:15:53 <pknirsch> unfortunately next Wednesday i'm on a business trip
16:16:14 <haraldh> gather the requirements, work s.th. out (which is a compromise), get feedback , rinse and repeat
16:16:22 <jwb> haraldh, right
16:16:24 <pknirsch> aye
16:16:40 <pknirsch> thats why i'd call all the documents/ideas we have so far not more than drafts
16:17:42 <pknirsch> same with the BR cleanup: asking for feedback from all maintainers is just purely and simply the right thing to do(tm)
16:18:31 <haraldh> so, let's start with the 2k packages, find a method to reduce them, ask the maintainers of the reduced set, if they are willing to support a longer lifecycle and our method of reducing the BRs
16:19:13 <haraldh> and maybe resolve https://fedorahosted.org/fesco/ticket/1202
16:19:14 <haraldh> :)
16:19:28 <jreznik> pknirsch: we definitely need some session not only that fesco one... I know I promised to take a look but during F20 release cycle, every single other meeting would kill me... but I got some buy in from a few folks...
16:19:52 <jreznik> and I'm still surprised not many people from other teams actually has a clue that products are happening...
16:20:39 <jreznik> I talked to a few guys, they will try to be more active now :D but it's impossible to follow all wgs meetings, all discussions... maybe fesco could ask for regular status updates?
16:20:54 <Viking-Ice> mitr, from my pov is that the distribution no longer can be restrained to single lifecycle and even less so with multiple products even with different products from the same wg like for example Gnome moves on a different pace then KDE and the core/base moves on a different speed then both of these etc.
16:21:06 <jreznik> aka what wg agreed on, what wg is working on, what are the plans for next week (so interested people can join it)
16:21:38 <robyduck> jreznik: +1 thanks
16:21:42 <pknirsch> right jreznik. could you bring that up with FESCO please? As i said, i won't be able to make it next Wednesday, but after that i can certainly do that
16:21:57 <Viking-Ice> mitr, it's vital from my pov if we are going to advanced to the next level as an distribution we need to be able to move past of single lifecycle for multiple products ( or rather the output from relevant service sub-community )
16:22:41 <Viking-Ice> and something we should be aiming at overcoming for the next 5 - 10 years
16:24:38 <jreznik> pknirsch: yep, I'll try - as I'm a bit nervous that we lack this/direction
16:26:22 <haraldh> pknirsch, maybe we can work together next week, to get some package statistics?
16:26:52 <haraldh> it's much more fun to do it with more than one brain :)
16:27:04 <pknirsch> haraldh: i'm gone all Tuesday and Wednesday next week, but sure, lets hook up on monday to work on it
16:27:07 <pknirsch> yea
16:27:08 <pknirsch> :)
16:27:16 <haraldh> monday is fine
16:27:54 <haraldh> so, anybody with an overview.. what has been decided on the release cycle?
16:28:07 <haraldh> any max. or min. values?
16:28:21 <haraldh> I see  https://fedorahosted.org/fesco/ticket/1202 closed
16:28:25 <haraldh> as fixed
16:28:48 <abadger1999> haraldh: yeah fesco decided that the first release of the fedora.next concept would keep the same release cycle for all products.
16:28:53 <jreznik> haraldh: I tried to summary it in http://borntobeopen.blogspot.cz/2014/01/wheres-fedora-21-schedule.html
16:29:22 <abadger1999> But that W's that want to have diffeing release cycles need to start asking for what they want so we can globally figure out if it's possible to do so.
16:30:12 <abadger1999> (since it's not just about what the products want to do but also about what the support infrastructure around building the products can handle)
16:30:12 <jreznik> I understand it more us - please, consider it would be a huge disruption in the beginning but we're open doing it later once we have everything in place aka tooling, test automation
16:30:26 <jreznik> abadger1999: exactly
16:30:37 <haraldh> ok
16:30:43 <haraldh> so postponed until later
16:30:58 <abadger1999> haraldh: well postponed implementation until later.  Planning should be happening now :-)
16:31:08 <haraldh> fine with me.. bad for the WGs who want long lived products
16:31:47 <haraldh> so, if planning should happen now, why is the ticket closed?
16:32:00 <abadger1999> The sooner the planning starts giving fesco some idea of what they want, the sooner we can start discussion with rel-eng, qa, infra, etc as to whether the ideas are possible.
16:32:46 <abadger1999> haraldh: nothing for fesco to do until actual things the WG's want to implement are written down.
16:32:52 <mitr> haraldh: AFAICT basically whoever wants a different lifecycle is expected to come up with a proposal; if there isn't any proposal, there won't be any further changes
16:32:54 <abadger1999> haraldh: so the fesco ticket is closed.
16:33:06 <haraldh> hmm, we should have at lease one representative of the other WGs in our meeting
16:33:15 <haraldh> so they can report their needs here
16:33:26 <haraldh> and make sure base has what they need
16:33:50 <abadger1999> haraldh: Probably WG's that want differing release cycles should open their own ticket/ticket equivalent to make those plans inside their own WG.
16:34:26 <haraldh> well, as base has to support all cycles, we have to find a compromise
16:34:37 <haraldh> so, they should report their wishes to us
16:34:42 <abadger1999> haraldh: <nod> although that's also fesco's job.
16:34:43 <Viking-Ice> mitr, you must also understand that each product has different lifecycle expectancy from the base server products require longer like 18 - 21 month while for example in workstation the product that's based on Gnome requires shorter ( since they implement things faster  )
16:35:09 <jwb> workstation has not indicated it needs a changed release cycle
16:35:15 <jreznik> abadger1999: well, once base exists, it should be base work...
16:35:33 <mitr> Viking-Ice: Server doesn't have a long lifecycle on the agenda at all; we do have "stable application runtimes" (which still happen to be in /etopic) as something we want to discuss
16:36:03 <abadger1999> haraldh: more so in this case, because the cycle is not just dependent on the inter-relation between the products but also on the interrelation between the non-product groups in fedora (rel-eng, qa, translators, infra, docs, design team, etc)
16:36:17 <mitr> (not claiming this is some unchangeable aspect of Server, just the direction we currently seem to be interested in)
16:36:28 <abadger1999> jreznik: I disagree for the above reasons of who is being coordinated.
16:36:47 <Viking-Ice> haraldh, I would say that would be the wrong approach I would say that base lifecycle should be tied to 3 releases per year ( 4 month ) tied to the kernel release with one LTS release in circulation tied to the kernel LTS release which would be replaced with the next supported LTS kernel release as in the one we would have in circulation would be EOL with an new LTS kernel release
16:38:24 <jreznik> abadger1999: that's true that it's our tradition to forget to ask non devel groups...
16:38:30 <abadger1999> as it's getting towards the end time for this meeting, I just want to mention that I have another piece of information (maybe clarification) for the BR cleanup when we get to open floor.
16:39:38 <jwb> Viking-Ice, kernel releases are closer to 2mo, not 4.  there were 5 major kernel releases in 2013
16:40:12 <pknirsch> abadger1999: i think it's certainly already time for open floor, sec.
16:40:16 <pknirsch> #topic Open Floor
16:40:18 <haraldh> jwb, you shewed him away
16:40:54 <haraldh> jwb, you scared him away
16:41:05 * jwb shrugs
16:41:05 <abadger1999> One thing to add about the BR cleanup: "<pknirsch> but as %check isn't being strongly encouraged now with the new Taskotron we should be fine"
16:41:09 <haraldh> jwb, you shooed him away
16:41:23 <abadger1999> We actually have a packaging guideline to encourage people to use %check
16:41:30 <jwb> abadger1999, ew.
16:41:46 <abadger1999> https://fedoraproject.org/wiki/Packaging:Guidelines#Test_Suites
16:41:52 <pknirsch> hm, but Taskotron doesn't "enforce" it any more than the already existing guidelines, right?
16:41:54 <abadger1999> "If the source code of the package provides a test suite, it should be executed in the %check section, whenever it is practical to do so. "
16:41:57 <pknirsch> that was my main point
16:42:11 <jwb> abadger1999, which is "practically" never ;)
16:42:22 <abadger1999> pknirsch: I'm uncertain.  I think it would be hard for an automated tool to enforce it.
16:42:28 <pknirsch> right
16:42:30 <haraldh> time to rethink the .spec syntax :)
16:42:50 <haraldh> BuildRequires(Documentation):
16:42:53 <pknirsch> haraldh: the emperors new clothes? :P
16:42:55 <haraldh> BuildRequires(Check):
16:43:09 <notting> we want test suites done on every build, if possible. before, %check was the only hammer. once we come up with more hammers, we can/shoudl deprecate that. but i don't know that we can reasonably do that before we have the other hammers in place
16:43:51 <abadger1999> jwb: hehe :-)  At the moment, it's been very practical for me.  But if we're upweighting the pruning of BR's , then I suppose you could interpret it as impractical ;-)
16:45:01 <abadger1999> haraldh: That would be cool but also requires a redefinition of "self hosting" and possibly changes to the build system (not just the basic rpm-build tools)
16:46:29 <abadger1999> ie: for self-hosting purposes we can build without a %build_doc and %install_doc sections (that uses BuildRequires(Documentation).  But we also need builds where we do use those BuildRequires so that hte packages are generated.
16:46:50 <abadger1999> (the doc subpackages are generated)
16:47:30 <pknirsch> yea, thats the tricky part and thats part of the review we're looking to be doing
16:47:39 <abadger1999> <nod>
16:48:26 <pknirsch> if it turns out that by disabling %docs we can get from the 2k to say 500 packages that would be huge and imho very worth pursing
16:48:35 <pknirsch> if it's bringing it down from 2k to 1.9k, less so
16:49:14 <pknirsch> but as haraldh and me already said in previous meetings, i'm a big fan of hard facts and data
16:49:55 <haraldh> pknirsch, monday 13:30 ?
16:50:24 <pknirsch> haraldh: you're getting up later and later man :) but sure, though i'll have a few meetings in the afternoon that i need to attend.
16:50:34 <abadger1999> Cool.  Just wanted to point out hte guideline's existence.
16:50:48 <pknirsch> yea, thanks :) and i'm not objecting that that, don't get me wrong.
16:50:57 <haraldh> well, I thought: eat mails for breakfast, do bugzilla before lunch...
16:51:06 <pknirsch> haha
16:51:20 <haraldh> then have fun in the afternoon with rpms
16:51:43 <pknirsch> decide to get started? :P http://www.joelonsoftware.com/articles/fog0000000339.html :)
16:52:29 <haraldh> hehe
16:52:34 <pknirsch> ok, anything else for today?
16:52:44 <pknirsch> (getting late in EU already ;))
16:53:25 <haraldh> have a nice weekend everybody
16:53:25 <pknirsch> alright, if not, thanks everyone and see you next week :)
16:53:34 <pknirsch> #endmeeting