15:01:12 #startmeeting Fedora Base Design Working Group (2014-01-10) 15:01:13 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:19 <- 15:01:20 #meetingname Fedora Base Design Working Group 15:01:20 The meeting name has been set to 'fedora_base_design_working_group' 15:01:23 hello 15:01:33 good morning and good afternoon folks! 15:01:40 hi 15:01:46 #chair jwb haraldh 15:01:46 Current chairs: haraldh jwb pknirsch 15:01:49 * masta is here 15:01:53 * jreznik is here too 15:01:54 i hope everyone had a great holidays? 15:02:01 yep 15:02:02 #chair masta jreznik 15:02:02 Current chairs: haraldh jreznik jwb masta pknirsch 15:02:24 same here. though too much food :) 15:02:25 yep, wish holidays were a year long :) 15:02:28 hehe 15:02:51 pknirsch: first soccer match this year after break was... pain :) 15:03:06 dgilmore: ping 15:03:14 i can imagine :) i managed to at least step out of the house every day at least once :P 15:03:16 jreznik: the "i need to either do this more often or not at all" pain? 15:03:25 #chair notting 15:03:25 Current chairs: haraldh jreznik jwb masta notting pknirsch 15:03:49 notting: yes, that one :) 15:04:55 * Viking-Ice drinking the latest brew from the factory whale beer ;) 15:05:02 O.o 15:05:10 that sounds, "interesting" :P 15:05:47 Viking-Ice, stop killing whales and sharks with your bow! :) 15:06:23 * dgilmore is here 15:06:32 #chair dgilmore 15:06:32 Current chairs: dgilmore haraldh jreznik jwb masta notting pknirsch 15:06:39 okidokie, lets get started then. 15:06:46 #topic Buildreq cleanup updates and further discussion/actions 15:09:27 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 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 okay. 15:10:45 * pknirsch mumbles something about having to dance on too many weddings at once 15:10:57 pknirsch: but think of all teh cake :) 15:11:20 dgilmore: heh :) i think back in horror to all the cookies i had over xmas :) 15:11:25 pknirsch: it slikely going to be a long term project to reduce things 15:12:15 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 otherwise this effort will be creeping back over time and we'd have to do it over and over again 15:13:11 or maybe integrate something that can check this in the successor of AutoQA, but not sure if thats feasible 15:14:30 pknirsch: maybe 15:14:51 so, automated checks or quarterly review? 15:15:10 i'd love to get this automated, but i'm not sure if thats possible 15:15:11 pknirsch: i think packages should require bootstraping functionality if needed. and we should work to enable smaller functional rpms 15:15:28 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 what we would need is split src.rpms ... not split rpms 15:16:28 auto rpmdiff, abi checks, soname warnings etc should be in autoqa's replacement 15:17:03 haraldh: split srpms mean extra work, in some places it wont matter 15:17:32 i guess in Matts Ring proposal it depends where the package falls 15:17:40 mhm 15:17:45 well, if you don't want to pull in buildreqs for a e.g. GUI subcomponent.. 15:18:15 pknirsch, one thing over the holidays did you manage to reach out to the maintainers of those 2k packages? 15:18:23 something in Base its fair to split into 2 or 3 srpms 15:18:37 Viking-Ice: not yet, but it's also on my list 15:18:39 there's recently some discussion of putting tests in %check. that will also potentially bring in extra BRs 15:18:46 something thats a far outlier package we should keep things easier for them 15:19:13 s/putting/running 15:19:24 hm, true, i remember that thread jwb 15:19:30 jwb: this could be made conditionnal 15:19:56 misc, on what? 15:20:27 jwb: if build for the mirror, then the tests are disabled, and ran on another system, with more BR avaliable 15:20:58 misc, so conditional and disabled by default. 15:21:24 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 jwb: we could want to have it ran if that's mock on a developper system or something like this 15:21:47 which makes it pointless because you can just install the package after build and run the tests yourself 15:22:08 or do the build twice, one with check and one without, the without being the one pushed, with less BRs 15:22:38 it's possible to do this, but i doubt it's valuable. 15:23:10 i guess it depends on the BR's and how big they are 15:23:40 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 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 pknirsch, that's what people are pushing for 15:24:04 pknirsch: that was also a proposal, yes 15:24:07 i dont think we should tear out things that are useful really just to reduce something 15:24:28 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 and the BRS for something in %check have zero effect on the resulting size and its deps 15:25:00 which ultimately that is what we want to solve 15:25:07 dgilmore, they have an effect on what is required to be self-hosting 15:25:09 allow for a smaller BAse 15:25:13 no 15:25:19 install size is not what we're discussing 15:25:26 people really need to stop equating the two 15:25:29 jwb: yes that would need included in the self hosting base 15:25:40 jwb: im not equating the two 15:25:51 10:24 < dgilmore> and the BRS for something in %check have zero effect on the resulting size and its deps 15:26:06 jwb: i guess we should say we are trying to do two things 15:26:08 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 if it's brought in as a BR, it increases the size of Base 15:26:31 making the size of teh self hosting base smaller, and the size of a minimal install smaller 15:27:10 jwb: 15:24 < dgilmore> i dont think we should tear out things that are useful really just to reduce something 15:27:11 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 jwb: if the value in having it is worth it then its worth it 15:27:40 i guess i made my point poorly 15:27:52 thanks Viking-Ice 15:28:19 ah right, Taskotron 15:28:25 * pknirsch remembers now 15:29:59 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 i think the latter is the plan, but it's really just being discussed 15:30:28 https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan#Phase_1:_AutoQA_Replacement 15:31:01 ah, so it's post package build external testing, thanks! 15:31:54 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 right 15:32:18 * pknirsch nods 15:32:43 masta: i thought that was a RFE to rpm and one point 15:32:46 s/and/at/ 15:32:51 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 alright, lets move on to the next topic as we're already in half an hour. 15:34:33 #topic Inter WG topic: Stable application runtimes 15:34:56 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 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 and i'd personally love to avoid having to support all variants of container tech 15:35:58 in Base 15:36:21 base/core should only concern itself with what systemd brings to the table 15:36:27 and iirc Base already at least provides the systemd one, right? 15:36:32 as Viking-Ice just said :) 15:37:11 Does anyone know what libvirt-lcx uses? Is that based on systemd containers? 15:37:17 yes 15:37:26 IMHO containers don't give you stable and secure runtimes; has that been missed or do you disagree? 15:37:27 cool, that's perfect then. 15:37:39 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 for a given base or product 15:37:57 haraldh: in base? 15:38:01 yes 15:38:03 hm 15:38:06 d-bus API for systemd 15:38:10 for example 15:38:23 sure, but X API seems a bit far off of base, no? 15:38:24 or config file syntax 15:38:36 pknirsch, sure.. not for base 15:38:59 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 but a desktop product might want to specify s.th. like GNOME 4 API 15:39:05 mitr: i certainly don't disagree 15:39:19 right haraldh 15:39:27 Also, if we declare the already stable runtimes as stable, we are not really solving the problem 15:39:36 hehhe 15:39:45 "Look! Stable is stable!" 15:39:45 :) 15:39:48 (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 (... thinking particularly of web apps now) 15:40:46 mitr: i remember Dan Walsh's comments about container tech and security :) 15:40:51 yea 15:41:24 the question is whether we require containers to be secure 15:42:12 that seems to be a plus, secure containers 15:42:28 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 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 pknirsch: Re: X API... I would see that as something Base could do.... Base is more than just Product to me. 15:43:38 It's also setting expectations for what a Fedora Release is. 15:44:03 which could certainly extend to something as core as the API of X 15:44:20 sure, i just wonder where the API definiton of Base would end. 15:44:25 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 Viking-Ice: hm, how so? 15:46:06 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 right 15:46:24 as mitr pointed out 15:46:41 pknirsch: 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 abadger1999: so where would you draw the line for API definitions that base provides 15:46:46 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 ah 15:47:14 right mitr 15:47:29 pknirsch: "Things that are core to Fedora" :-) which just moves the question to "what is 'core'?" 15:47:30 and stable application runtimes doesn't mention "security" ;) 15:47:30 mitr, right you would need that to get *secure* stable applicaton runtimes via containers 15:48:42 abadger1999, core is minimal bootable system anything on top of that is definable per person thus subjected to debates 15:48:43 abadger1999: hehe, right. 15:49:18 abadger1999: every question is just a matryoshka doll of more questions? 15:49:37 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 i can boot a system with a kernel and a shell. that's two packages. i guess we're done 15:49:50 :) 15:50:31 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 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 or rather falls into the spectrum of another WG 15:51:59 I think I'd say there's a difference between what Base supports and what Base specifies. 15:52:17 hm 15:52:24 Base can support (ship, maintain, own) a minimal packageset. 15:52:28 that gets rather complicated then though 15:52:36 wouldn;t it? 15:52:38 I would say what Base supports and what Base specifies can never be outside those 2k packages 15:52:53 Viking-Ice, agreed 15:53:13 But they might also specify "If you ship X in you product in Fedora 21, it should implement API $version" 15:53:48 abadger1999, why not make a meta "base + X" specification? 15:53:59 which all products use, which ship X 15:54:20 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 might be true 15:54:35 Cool. 15:54:44 abadger1999: wait, wasn't the idea to define what fedora 21 even *was* in relation to X number of products? 15:54:54 (given that '.next' implies it may not even be 21) 15:55:03 it wont be 21 15:55:07 I think that is clear 15:56:02 notting: Sure. And isn't deciding what the core expectations of any Fedora ($version) system are that definition? 15:56:35 Viking-Ice: I don't disagree... but until we have another name for it, we have to call it something. 15:56:57 but, is it "Fedora.Base.21 + Fedora.Desktop.1" then? :) 15:57:57 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 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 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 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 jreznik: I agree totally. 16:00:13 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 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 will catch up on the meeting logs later 16:01:55 jwb: we should call working groups to talking groups 16:02:09 i'll resign if that's what this is 16:02:10 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 Viking-Ice, i don't disagree with that. though 2k is the starting number we're trying to reduce from 16:03:42 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 and we don't have a defined method to reduce the BRs, yet... do we? 16:04:41 haraldh, communicating the goal is different from telling them how to do it 16:05:13 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 so, task before the next meeting: make a list of the maintainers of the 2k packages? 16:05:27 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 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 also email them questioning for ideas to reduce the BRs of their package and probably join the next meeting 16:06:40 /me nods 16:06:40 jreznik, we already defined that 16:06:50 jreznik, see "What is Base" here: http://fedoraproject.org/wiki/Base 16:07:33 also interesting what be the number of BRs for every of those 2k packages 16:07:40 jwb: defined - yes, but did we agree on that with other groups? do they accept our definition? 16:07:53 and usage number of other packages 16:07:58 jreznik, I would think they have no saying in it 16:08:01 then find the low hanging fruits 16:08:02 ( other groups ) 16:08:17 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 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 hmm, maybe by parsing the build logs, we can easily get the number of installed packages in mock 16:10:04 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 jwb: that's my point, we set it, moved forward, done and I'd really to hear some feedback 16:10:23 notting, telling them yes having them follow it no 16:10:33 but on the other hand I like other ideas that are worked on/(talked) 16:10:56 fesco does not have the ability to force anything last time I checked 16:11:21 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 yep 16:12:17 any volunteers for that then? 16:12:20 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 sigh. yeah, defining a Base that doesn't work for the products is really a great way to start out 16:13:30 well, we will have revisions anyway 16:13:38 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 ? 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 pknirsch, technically jreznik's point. i just think this meeting is the wrong place to have that discussion 16:14:28 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 s/to you/do you 16:15:21 they have _additional_ requirements. that doesn't mean we shouldn't try and find commonality between them 16:15:24 jwb: right. isn't the FESCO meeting on Wednesdays where all WGs have a representative? 16:15:31 pknirsch, yes 16:15:43 jwb: there we could present the current ideas and add that to the FESCO agenda. 16:15:49 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 unfortunately next Wednesday i'm on a business trip 16:16:14 gather the requirements, work s.th. out (which is a compromise), get feedback , rinse and repeat 16:16:22 haraldh, right 16:16:24 aye 16:16:40 thats why i'd call all the documents/ideas we have so far not more than drafts 16:17:42 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 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 and maybe resolve https://fedorahosted.org/fesco/ticket/1202 16:19:14 :) 16:19:28 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 and I'm still surprised not many people from other teams actually has a clue that products are happening... 16:20:39 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 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 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 jreznik: +1 thanks 16:21:42 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 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 and something we should be aiming at overcoming for the next 5 - 10 years 16:24:38 pknirsch: yep, I'll try - as I'm a bit nervous that we lack this/direction 16:26:22 pknirsch, maybe we can work together next week, to get some package statistics? 16:26:52 it's much more fun to do it with more than one brain :) 16:27:04 haraldh: i'm gone all Tuesday and Wednesday next week, but sure, lets hook up on monday to work on it 16:27:07 yea 16:27:08 :) 16:27:16 monday is fine 16:27:54 so, anybody with an overview.. what has been decided on the release cycle? 16:28:07 any max. or min. values? 16:28:21 I see https://fedorahosted.org/fesco/ticket/1202 closed 16:28:25 as fixed 16:28:48 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 haraldh: I tried to summary it in http://borntobeopen.blogspot.cz/2014/01/wheres-fedora-21-schedule.html 16:29:22 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 (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 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 abadger1999: exactly 16:30:37 ok 16:30:43 so postponed until later 16:30:58 haraldh: well postponed implementation until later. Planning should be happening now :-) 16:31:08 fine with me.. bad for the WGs who want long lived products 16:31:47 so, if planning should happen now, why is the ticket closed? 16:32:00 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 haraldh: nothing for fesco to do until actual things the WG's want to implement are written down. 16:32:52 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 haraldh: so the fesco ticket is closed. 16:33:06 hmm, we should have at lease one representative of the other WGs in our meeting 16:33:15 so they can report their needs here 16:33:26 and make sure base has what they need 16:33:50 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 well, as base has to support all cycles, we have to find a compromise 16:34:37 so, they should report their wishes to us 16:34:42 haraldh: although that's also fesco's job. 16:34:43 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 workstation has not indicated it needs a changed release cycle 16:35:15 abadger1999: well, once base exists, it should be base work... 16:35:33 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 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 (not claiming this is some unchangeable aspect of Server, just the direction we currently seem to be interested in) 16:36:28 jreznik: I disagree for the above reasons of who is being coordinated. 16:36:47 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 abadger1999: that's true that it's our tradition to forget to ask non devel groups... 16:38:30 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 Viking-Ice, kernel releases are closer to 2mo, not 4. there were 5 major kernel releases in 2013 16:40:12 abadger1999: i think it's certainly already time for open floor, sec. 16:40:16 #topic Open Floor 16:40:18 jwb, you shewed him away 16:40:54 jwb, you scared him away 16:41:05 * jwb shrugs 16:41:05 One thing to add about the BR cleanup: " but as %check isn't being strongly encouraged now with the new Taskotron we should be fine" 16:41:09 jwb, you shooed him away 16:41:23 We actually have a packaging guideline to encourage people to use %check 16:41:30 abadger1999, ew. 16:41:46 https://fedoraproject.org/wiki/Packaging:Guidelines#Test_Suites 16:41:52 hm, but Taskotron doesn't "enforce" it any more than the already existing guidelines, right? 16:41:54 "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 that was my main point 16:42:11 abadger1999, which is "practically" never ;) 16:42:22 pknirsch: I'm uncertain. I think it would be hard for an automated tool to enforce it. 16:42:28 right 16:42:30 time to rethink the .spec syntax :) 16:42:50 BuildRequires(Documentation): 16:42:53 haraldh: the emperors new clothes? :P 16:42:55 BuildRequires(Check): 16:43:09 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 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 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 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 (the doc subpackages are generated) 16:47:30 yea, thats the tricky part and thats part of the review we're looking to be doing 16:47:39 16:48:26 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 if it's bringing it down from 2k to 1.9k, less so 16:49:14 but as haraldh and me already said in previous meetings, i'm a big fan of hard facts and data 16:49:55 pknirsch, monday 13:30 ? 16:50:24 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 Cool. Just wanted to point out hte guideline's existence. 16:50:48 yea, thanks :) and i'm not objecting that that, don't get me wrong. 16:50:57 well, I thought: eat mails for breakfast, do bugzilla before lunch... 16:51:06 haha 16:51:20 then have fun in the afternoon with rpms 16:51:43 decide to get started? :P http://www.joelonsoftware.com/articles/fog0000000339.html :) 16:52:29 hehe 16:52:34 ok, anything else for today? 16:52:44 (getting late in EU already ;)) 16:53:25 have a nice weekend everybody 16:53:25 alright, if not, thanks everyone and see you next week :) 16:53:34 #endmeeting