18:00:16 #startmeeting FESCO (2012-12-12) 18:00:16 Meeting started Wed Dec 12 18:00:16 2012 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:19 #meetingname fesco 18:00:19 The meeting name has been set to 'fesco' 18:00:26 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb abadger1999 sgallagh 18:00:26 Current chairs: abadger1999 jwb limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 18:00:34 #topic init process 18:00:43 ok, who all is around? 18:00:50 * limburgher is here 18:00:50 hello. 18:00:51 helloooooooo n^wfesco. 18:00:52 Hello all 18:00:55 Hi 18:00:57 I'm here, but kinda also busy dealing with a fire. :) 18:00:59 * abadger1999 here 18:01:01 we have two new members joining today, and i pinged them both earlier 18:01:13 * sgallagh waves 18:01:23 I missed you guys ;-) 18:01:26 Is this week running with the new committee or the old one? 18:01:30 * limburgher waves back and extends congrats to both 18:01:38 mjg59, no idea, but i was going with new 18:01:43 New makes things easier for me 18:01:51 mjg59, with proper thanks to the departing members of course 18:02:19 #topic FESCo member changes 18:02:23 Yeah I didn't slave over a hot fesco for those long years just to not get proper thanks 18:02:44 :-) 18:02:46 so, abadger1999 and sgallagh are now both returning to FESCo after a bit of time away per the election results 18:02:48 hehe 18:02:59 which means mjg59 and limburgher are unfortunately departing 18:03:13 Well 18:03:17 You say unfortunate 18:03:17 i wanted to extend a hearty thanks to both mjg59 and limburgher for their contributions over their terms. it has been much appreciated 18:03:19 You can still kick me around. :) 18:03:23 many thanks mjg59 and limburgher! 18:03:30 and i do hope you both stick around for the fun anyway :) 18:03:33 Thank you! 18:03:38 And congratulations to the new members 18:03:41 hi 18:03:43 condolances^Wwelcome abadger1999 and sgallagh 18:03:45 Wouldn't miss it for. . .well . . . 18:03:48 #info Welcome to abadger1999 and sgallagh 18:03:50 much thanks and appropriate beverages to limburgher and mjg59 18:04:00 #info Many thanks to mjg59 and limburgher! 18:04:26 mjg59, limburgher: Thanks for everything. Hope you'll stick around and help out anyway :) 18:05:03 has anyone heard from mitr, mmaslano, or t8m ? 18:05:11 oops, mitr is here 18:05:12 I'm here 18:05:16 yep, see that now 18:05:28 ok, so i think we're just missing mmaslano 18:05:39 hi, i'm late but here 18:05:42 ah, great 18:05:48 let's move on with the agenda then, shall we? 18:05:51 I'm like 30% here. 18:06:09 #topic #973 raising warning flag on firewalld-default feature 18:06:09 .fesco 973 18:06:10 https://fedorahosted.org/fesco/ticket/973 18:06:11 jwb: #973 ("raising warning flag on firewalld-default feature") – FESCo - https://fedorahosted.org/fesco/ticket/973 18:06:24 should we do this last in case mattdm shows up? 18:06:33 nirik, he's on the rest of them too 18:06:44 i mean, we can, but he'll be missing something 18:06:45 ah true. ;) 18:07:18 basically, it seems the firewalld people are suggesting that anaconda use lokkit instead of firewalld, and firewalld will do some kind of conversion after install? 18:07:34 Per https://bugzilla.redhat.com/show_bug.cgi?id=885807#c7 , it seems not 18:08:08 hi 18:08:12 I'm getting lost in all of the conversations, though 18:08:15 twoerner, we're discussing firewalld in f18 18:08:23 ok 18:08:31 * nirik is also a bit lost as to what current status is and proposals. 18:08:47 twoerner, the overview i have is that you wish for anaconda to use lokkit and that firewalld can be started after install? 18:08:56 if that isn't correct, can you correct us? 18:08:59 is it realistic to change the pygobject3 dep chain now after the freeze? 18:09:52 jwb: what I meant was that anaconda could use lokkit still to solve the blocker 18:09:52 ... and would we want to do it? 18:10:17 firewalld has a convert tool that is able to convert most of the lokkit configuraion 18:10:42 that sounds... awfully equivocal. 18:10:49 twoerner: it's a manual tool currently, correct? 18:10:58 notting: yes, it is manual only 18:11:01 atm 18:11:44 is it feasible to move firewalld to F19 as default at this point? 18:11:45 twoerner: so, from your view everything is ok as is? or what changes would you advocate right now? 18:11:54 * nirik nods, and that question too. 18:11:59 t8, mitr: it would be good to change pygobject3 but I do not know if it can be done still 18:12:28 nirik: I would like o change pygobject3 and leav firealld in for all installations for consitency 18:12:48 but that pulls X into things, right? 18:12:50 At this point I tink, let's just stop making changes and let QA do a final release validation using the existing criteria 18:13:02 nirik, not if pygobject3 dep chain is fixed 18:13:27 * nirik thinks there are a number of issues here... perhaps we could try and list them, then address them one by one? 18:13:28 mitr, does pygobject3 dep chain change count? 18:13:40 mitr: the theoretically failing criteria in the current state would be 'minimal install is way too big'? 18:13:46 nirik: firewalld only used GObject, GLib and Gio from gobject3, no X 18:13:46 QA might take the pygobject3 dep chain as a NTH item if they feel the risk (which is non-zero) can be mitigated 18:14:46 notting: I can't see minimal install in the release requirements, going strictly by the book 18:14:54 mitr: yep, it's still possible - and it really depends on how risky it would be 18:15:08 do we have a patch/proposed fix for pygobject3? 18:15:17 mitr, yeah, I really wonder whether there are apps that require just pygobject3 but need the cairo and other bindings 18:16:01 nirik: i assume (hah) it's just yanking the pycairo requires out of the spec file 18:16:04 nirik: Based on #855346, probably not 18:16:28 oh wait, you'd need a rebuild or subpackaging 18:17:14 .bug 855346 18:17:17 abadger1999: Bug 855346 excessive dependencies - https://bugzilla.redhat.com/show_bug.cgi?id=855346 18:18:32 * nirik would prefer to fix that, we should be able to test a proposed fix pretty easily? 18:18:58 There are 40 packages dependent upon pygobject3 right now (according to repoquery). This is potentially a manageable number for a provenpackager to rebuild while adding explicit Requires/BuildRequires on Cairo 18:19:27 as a potential short-term mitigation 18:19:40 this seems doable, but honestly it seems forced 18:20:09 sgallagh: http://www.fpaste.org/D75B/ 18:20:12 jwb: I don't disagree, but individual maintainers can pull those back out where appropriate 18:20:32 notting: How was that generated? 18:20:45 (Though if it's accurate, it probably reduces the effort significantly) 18:20:51 sgallagh: take everything that requires pygobject3, see if they also Require: cairo in some form 18:21:40 so the question would be which of those that *don't* a) might still use cairo b) could manage to get installed without it 18:21:42 Ok, so that brings it down to 13 packages that potentially would need intervention. 18:21:51 I an help with this, but I am not a provenpackager 18:21:56 so we're looking at a rebuild of pygobject3, then a rebuild of 13 packages 18:22:02 * nirik nods. 18:22:11 jwb, at most 13 packages 18:22:13 all of which need to be in an update(s) and then approved by QA as NTH or blocker 18:22:18 yep 18:22:26 jwb, they can be in a single update 18:22:27 and all done Real Soon Now 18:23:04 would someone like to take the lead on it? contact all maintainers, wait for reply for a bit then just update them all and make 1 update with all the changes? 18:23:14 unless we don't want to do it? ;) 18:23:55 so if anaconda uses lokkit, firewalld won't magically work on firstboot without some kind of manual tool run to convert thigns? 18:24:25 I can add the convert tool to firewalld post install 18:24:41 script 18:24:46 that won't help, lokkit firewall is written after package installation 18:24:55 right 18:25:00 jwb: ... and we are left with a lokkit package that responds but doesn't really work. 18:25:12 .bug 885807 18:25:15 nirik: Bug 885807 firewalld accidentally made mandatory; needs to be optional for f18 and f19 - https://bugzilla.redhat.com/show_bug.cgi?id=885807 18:25:35 the standard config besides kickstart configuration of the firewall is already enabed in the zones 18:25:42 I'd prefer fixing the dep chains - it would be 'a good thing' regardless of default firewall 18:25:51 anaconda ads ssh in common 18:25:53 t8m: That's a separate issue 18:26:03 mitr, yep 18:26:38 so essentially, we have two choices: 1) fix pygobject3 issue and go with firewalld as default everywhere, 2) revert firewalld entirely until f19 18:26:46 or is there some other option i'm not seeing? 18:27:00 actually, i think it's more than 13 packages to check, as even the ones that still require cairo might need updated to pull in a potential new subpackage 18:27:14 I'm generally fine with people who don't want to use firewalld having to do some amount of extra work. "yum remove firewalld post-install" is a little border-line, but not obviously out of the question 18:28:14 notting: good point. 18:28:31 a kludge-y way would be to make pygobject3-base subpackage that would not include the cairo etc. and make firewalld require the -base and the pygobject3 main package would provide the rest and require the -base 18:28:36 mitr: a simple systemctl disable firewalld.service would work also 18:29:08 t8m: this is a nice and fairly simple solution 18:29:26 t8m: Yeah, that sounds less kludgy than our other suggestions, at least. 18:29:41 t8m: if we can seperate out the cairo using part of it safely 18:29:48 but sounds like thats just one .so ? 18:30:02 nirik: and the Requires: pycairo, yes 18:30:24 ok, well it seems everyone is clearly headed down my option 1 path 18:30:30 you could even be a bad packager and have the packages share files 18:30:41 jwb: whats involved in option 2? it seems like that might be more moving parts at this point? 18:30:44 * mattdm shows up 18:30:56 nirik, use lokkit i would guess 18:31:25 notting: Bad suggestion. No cookie. 18:32:35 ok, when it is needed to be complete? 18:32:49 s/complete/ready 18:32:50 yesterday 18:33:02 * adamw pipes in that he would be horribly scared by option 2) from a QA perspective, so glad to see 1) appears favoured. 18:33:03 mattdm: The story so far: http://paste.fedoraproject.org/2368/ 18:34:04 proposal: fix pygobject3 issues with firewalld and use firewalld as default everywhere 18:34:20 scared or scarred? 18:34:24 likely both. 18:34:40 jwb, +1 18:34:41 jwb: +1 18:34:42 jwb: what does "default" mean there? To me that implies an option to which there is a non-default alternative. 18:34:42 +1 (although it's not nice to have to choose this at this point) (also add: update docs to make clear this is the case... feature page, release notes, etc) 18:35:02 jwb: +1 18:35:10 yeah, +1 18:35:26 mattdm: it means you can systemctl it off or -firewalld in ks.cfg or ... 18:35:29 mattdm, default means "the thing that anaconda and the default install uses" 18:35:30 mattdm: i think you can still take it out in kickstart. 18:35:37 right, what they said 18:35:43 jwb: +1 18:35:49 jwb: +1 18:35:55 okay, so it includes finding some solution to the current situation where you can't take it out in kickstart. 18:36:01 mattdm: "possible to remove in some, not necessarily theoretically optimal, way" 18:36:11 jwb: +1 18:36:11 mattdm: oh? is there a bug on that? 18:36:29 .bug 885807 18:36:34 mattdm: Bug 885807 firewalld accidentally made mandatory; needs to be optional for f18 and f19 - https://bugzilla.redhat.com/show_bug.cgi?id=885807 18:36:57 and 18:37:01 .bug 884878 18:37:03 mattdm: Bug 884878 FirewallConfig in imgcreate/kickstart.py requires FirewallD - https://bugzilla.redhat.com/show_bug.cgi?id=884878 18:37:29 #agreed fix pygobject3 issues with firewalld and use firewalld as default everywhere 18:37:34 oops 18:37:36 #undo 18:37:36 Removing item from minutes: 18:38:13 twoerner, can those two bugs be fixed relatively easily? 18:38:55 jwb: I do not know where the firewalld requirement in livecd-tools comes from? 18:38:58 jwb: We talked about those - it would probably involve installing lokkit again 18:39:01 is this from anaconda code? 18:39:34 wait 18:39:35 * nirik thinks we are going in circles here. ;) 18:39:40 mattdm: The failure case isn't clear. Is it "can't install with -firewalld in %packages", or "can't (rpm -e firewalld) in %post"? 18:39:46 mitr, it should be sufficient to just spit out warning and continue w/o firewall if firewalld is not present 18:40:15 if we're doing with firewalld as the default, bug 884878 shouldn't matter? 18:40:24 t8m: Hm. Effectively silently ignoring a security configuration doesn't make me very happy 18:40:49 mitr: can't install with "-firewalld". 'rpm -e' is a workaround, but then there's the leftover deps which is messy. 18:40:49 mitr, /me neither but we don't have too many options 18:41:06 mitr: if you explicitly say you don't want firewalld, it's hard to see how you're not saying "I'll handle my own firewall setup, don't do it for me" 18:41:23 pjones, +1 that's another pov 18:41:34 mattdm: Idl take the workaround at this point I think 18:41:45 jwb: that's the difference between 'default everywhere' and 'mandatory everywhere' 18:42:27 It feels like a big end-run around the feature process. 18:42:30 pjones: right, but that's not how the anaconda code works at the moment, and probably not something we want to change 18:42:39 fair enough 18:42:40 mattdm, well at this point i think we're basically at the point of "mandatory everywhere" or "not installed, punt to f19" 18:42:41 pjones: If my %packages contains -firewalld and +iptables-services, it's not as clear 18:44:11 ok, we need to make a decision here or move on 18:44:28 should we refine the proposal from "default" to "default and mandatory"? 18:44:50 jwb: I think before that we should examine the alternative. 18:44:51 well, you can still not use it. 18:44:54 i was agreeing with jwb's proposal in the mindset of 'just touch pygobject3; don't touch anything else' 18:44:58 if you are moving firewalld in the base package set instead of anaconda foring it in, it could be removed with -firewalld in %packages 18:45:11 What would it take to remove it entirely? I suspect that we're in a position where that's no longer feasible 18:45:15 sgallagh, the alternative is what i listed as #2 a while ago 18:45:16 In which case our choices diminish to one 18:45:19 basically, use lokkit 18:45:22 twoerner: but then you get 0 firewall out of the box without it, right? 18:45:51 nirik: yes.. if you are removing a package, you should add the other one 18:45:54 I think the "mandatory" wording is not helping clarify things... 18:46:05 nirik: I just wanted to say that your can remove it then 18:46:12 twoerner: but even if you add lokkit and/or iptables, anaconda won't give you a firewall 18:46:18 mitr, me either, but mattdm has a point 18:46:49 nirik: with the lokkit call in anaconda you would get one 18:47:08 Given the schedule, we need to be looking for the very minimal solutions IMHO, instead of trying to invent new solutions in a meeting 18:47:16 mitr, +1 18:47:23 mitr: +1 18:47:25 The time to look for solutions was Monday 18:47:31 yes 18:47:45 * nirik is still for the 'fix pygobject3' and nothing else. 18:47:55 if that's our approach, then the proposal already passed 18:48:11 and the concerns on removing it via kickstart will be ignored 18:48:48 I don't love being unable to remove it, but it's not a strong enough concern to affect my original vote. 18:48:53 jwb: per mattdm, for anaconda there is a kickstart solution/ugly workaround. 18:48:55 (Which was +1, for the record) 18:49:09 so does anyone wish to change their vote? 18:49:29 * notting does not 18:50:03 mitr: +1 18:50:09 #agreed fix pygobject3 issues with firewalld and use firewalld as default everywhere (+:9, -:0, 0:0) 18:50:38 #info there is a somewhat ugly workaround for removing firewalld via kickstart for those that don't wish to install it 18:50:39 mitr: remove it in post? yeah 18:50:47 ok, we need to move on 18:50:59 #topic #896 Refine Feature process 18:50:59 .fesco 896 18:51:00 https://fedorahosted.org/fesco/ticket/896 18:51:02 jwb: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896 18:51:13 I'm not sure we have anything to explicitly discuss on this today 18:51:18 but it's follow up from last week 18:51:22 I'm afraid I don't have anything new 18:51:29 it seems there is still on-going discussion on the devel list 18:51:55 anyone have something new to bring up? if not, i'll move on to the two concrete proposals we have 18:52:13 * sgallagh has nothing 18:52:54 ok, let's move on to the next two then 18:53:09 #info discussion of the submitted proposal still on-going on the devel list 18:53:16 #topic #980 Add "activate contingency" points to the features process 18:53:16 .fesco 980 18:53:17 https://fedorahosted.org/fesco/ticket/980 18:53:18 jwb: #980 (Add "activate contingency" points to the features process) – FESCo - https://fedorahosted.org/fesco/ticket/980 18:54:16 the proposal here is to add an explict date in the schedule for "feature actually works" 18:54:19 right mattdm ? 18:54:32 right 18:54:43 and automatically back out the feature if it doesn't. 18:54:43 * jreznik is reading 18:55:24 mitr, i believe you suggested that "feature freeze" already is that date? 18:55:36 I think we are all discussing "disruptive" features (whateve that means) here, right? 18:55:49 mitr: yes. 18:55:51 for sake of progress, sure 18:56:10 jwb: This cycle, "1 week before beta" was that date I think 18:56:52 going back to the beginning of this meeting, this cycle it seems like "the day after feature freeze" was that date. :-/ 18:57:08 It seems to me that it's difficult to find a date that "really works" 18:57:08 s/feature/final/ 18:57:31 jwb: "1 week before beta freeze" taht is, sorry 18:57:34 yeah, one size I am not sure fits all. 18:57:56 Perhaps we differentiate based on "critpath"? Anything that changes critpath needs to be useful at Feature Freeze date or it gets punted? 18:58:05 mattdm: beginning of this meeting - it was an exception and we had a lot of exceptions this cycle... yeas 18:58:18 mattdm, that's not really a fair classification of the feature process 18:58:30 i mean, it's broken, but it isn't broken unilaterally 18:58:35 mattdm: is it a date in the general schedule or a date per feature? 18:58:42 sgallagh: it's all about get punted... someone has to really do that 18:58:53 abadger1999: I was suggesting a date in the general schedule. 18:58:56 k 18:58:57 sgallagh: What _would_ we punt at Feature freeze? 18:59:25 I mean, we technically can, but the urge to give a little more time is very strong 18:59:26 apologies, i have to go 18:59:28 mattdm: in schedule we have several feature milestones... what's the difference to the current milestones? 19:00:13 jreznik: those milestones don't require any testing or sanity checks beyond "is it done" 19:00:17 * nirik thinks replacing the feature process in little parts is kinda doomed... we should come up with a complete revamp... probibly in a higher BW communications channel like fudcon 19:00:26 Also, many features will get most of the feedback only after beta 19:00:28 nirik, i tend to agree 19:00:33 mitr: Ok, so maybe at feature freeze, we vote on whether we believe one week or something is enough time. If not, say "sorry, there's always a Fedora N+1" 19:01:03 mattdm: actually it does require - feature freeze is about testability 19:01:32 nirik: The problem with making big changes at FUDCon is that we have to plan WELL in advance that we're going to do so, in order to allow interested stakeholders time to plan the trip 19:01:34 I'm not seeing how this isn't a proposal to paper over the schedule problems we had with F18. 19:01:40 sgallagh: that's what was done for f18... and adding week, week :) 19:01:44 Those problems weren't with the feature process, they were with the schedule. 19:02:02 sgallagh, changes aren't made at FUDCon. they're discussed 19:02:08 (I'm no fan of the feature process, but let's try not to shift the blame.) 19:02:15 sgallagh: sure, but also, changes should be proposed/written up, not approved there. 19:02:25 sure 19:02:27 pjones: I'd say I agree with your point 19:02:40 so, we could get ideally one good proposal/change/new process... and get more feedback after fudcon and put in effect. 19:02:42 proposal: defer this until we have a larger overall discussion of the feature process 19:02:43 pjones: I can't see that; having to deal with firewalld now, when the schedule has slipped for many weeks, is not a problem of having the schedule slightly wrong. (OTOH arguably we shouldn't be trying to fix every single case that isn't ideal) 19:02:54 jwb: +1 19:03:19 jwb, +1 19:03:22 mitr: I'd assumed that when it was said that this was about disruptive features, we meant anaconda not firewalld. 19:03:25 nirik: That would be nice, but I think the lead time to January is too short to do that this FUDCon 19:03:28 I'm fine with deferring, given that a larger rework is in progress. 19:03:32 jwb: +1 19:03:35 (I for one would have a hell of a time getting there at this point) 19:03:36 jwb: +1 19:03:52 sgallagh, it's going to be discussed at FUDCon. 19:04:11 sgallagh, even if we pretend it isn't a formal discussion, it's still going to happen. 19:04:13 sgallagh: you could provide input on any document that comes out of fudcon tho. ;) 19:04:22 * sgallagh sighs and goes to beg for travel budget. 19:04:31 pjones: Anything that's a significant change to the distro defaults 19:04:33 sgallagh: see me if your begging fails 19:04:47 sgallagh, it's also no different than the group of people that submitted the current proposal, who all happen to be in the same physical location 19:04:48 rbergeron: think about mitr too :) 19:04:49 rbergeron: Will do, thanks 19:04:55 jreznik: yes, i know 19:05:09 ok, i have 5 votes for defering if you include mine 19:05:15 jwb: +1 to defer 19:05:22 mattdm: meh. that's not a bright line criteria. 19:06:12 pjones: understood; maybe there will never be one. But I definitely didn't mean just anaconda *or* just firewalld. 19:06:39 notting left, so mitr and abadger1999 ? 19:07:12 mattdm, or anyone else: Would anyone like to write up a more specific proposal for #980? I mean, I agree that there probably is a possible improvement, but a solution isn't clear at all; meeting personally is great, but doesn't do the thinking for us :) 19:07:20 jwb: +1 with the above note 19:07:43 sure, i can add that as an info 19:07:47 abadger1999, ? 19:07:57 mitr: I'll be happy to work with people on a new grand scheme of which this might be a part. 19:08:00 mitr: what does it mean "more specific proposal?" 19:08:25 * mattdm notes that my proposal is actually specific 19:08:29 jreznik: for example, "the time of decision should be $X ... becasue..." 19:08:34 ok, the proposal passed. i think we're going to move on 19:08:38 #agreed defer this until we have a larger overall discussion of the feature process 19:08:41 damnit 19:08:44 #undo 19:08:44 Removing item from minutes: 19:08:46 mattdm: "not too late" is all it says I think? 19:08:56 bleagh. I don't see the need to defer until fudcon but we should definitely defer for thismeeting. 19:08:59 #agreed defer this until we have a larger overall discussion of the feature process (+:8, -:0, 0:0) 19:09:14 mitr: see comment #2 in the ticket 19:09:31 abadger1999, my proposal didn't mention fudcon 19:09:41 see how sneaky i am? 19:09:51 it's like i've done this before or something 19:09:55 mattdm: right, sorry, I missed that 19:10:01 jwb: well, I also don't see a need to defer until there's a larger overall discussion necessarily 19:10:16 abadger1999, is that a -1? 19:10:19 but yeah, doesn't change that we won't resolve this issue this meeting. 19:10:31 ok, moving on 19:10:36 #topic #979 Features process proposal: Track features in bugzilla 19:10:36 .fesco 979 19:10:37 https://fedorahosted.org/fesco/ticket/979 19:10:37 jwb: #979 (Features process proposal: Track features in bugzilla) – FESCo - https://fedorahosted.org/fesco/ticket/979 19:10:38 I'm not sure we will get a "larger" discussion than we usually manage to - but anyway, anyone can put this on the agenda 19:10:46 i have a feeling this will wind up with the same resolution 19:11:15 however, i do like the idea of not using the wiki 19:11:35 and i hate trac, so bugzilla seems to be the only other option 19:12:13 jwb: do you want o track all features in bugzilla? 19:12:22 I kinda cringe about using bugzilla for more workflow stuff but it's a better tool than what we're using now. 19:12:24 as I mentioned in ticket it doesn't make sense for all features 19:13:06 well, one bug wouldn't be too much overhead... 19:13:08 jwb: not using wiki is a good idea but not sure bugzilla is a good tool for tracking neither 19:13:13 * nirik kinda likes the idea as well... 19:13:21 mmaslano, neither does tracking the specific item you listed via a wiki page 19:13:28 From the FESCo point of view, perhaps we actually don't care (the feature wrangler collects a status report for us)...until we do and we need detailed status information for a late feature 19:13:40 yes 19:13:45 mitr, +1 19:13:53 mitr, i disagree. 19:14:04 jreznik, i don't see another option that isn't trac 19:14:07 do you? 19:14:49 But when we do care, I'm not sure that feature-owner-maintained task lists tell us what we need to know; we need to know primarily about the tasks that weren't anticipated by the feature owner. 19:14:49 would it mean that the current FESCo feature tickets will be abandoned in favor of the bugzilla bugs? 19:14:52 jwb: trac, from wiki, bz and trac - the best option (but still not the really good one) 19:15:12 What about setting up something like redmine? 19:15:21 but as far as I know - everyone trying any kind of feature tracking in bz failed horribly... 19:15:23 t8m: I can't really see bugzilla replacing the wiki for most of the textual content 19:15:25 proposal: defer this one under exactly the same criteria as we deferred the last one 19:15:30 pjones, +1 19:15:41 mitr: wiki is for textual data and has to be linked to tracking sw 19:15:54 mitr, not the wiki, the trac tickets that are created for FESCo meetings 19:16:08 pjones: at least I can try to draft the process in features trac 19:16:44 t8m: That's better only because trac tickets are editable and thus serve as a wiki 19:16:56 btw. two years ago we were talking about moving spin process (similar to feature one, actually 1:1) to trac too but it has not been moved 19:17:16 pjones submitted a proposal 19:17:17 sgallagh: if you want infra to host it, redmine is not in EPEL, and we have limited ruby known how. 19:17:30 pjones: +1 19:17:32 i have no idea what redmine is 19:17:34 nirik: Well, I was thinking more about OpenShift. 19:17:34 pjones, +1 19:17:43 jwb: Web-based project management suite 19:17:44 redmine is basically super-trac 19:18:21 sure, we could do that, although it adds openshift as a dependency on our releases possibly, which might or might not be acceptable. 19:18:25 I'm not sure how much effort it would be to maintain (and I'm sure I don't have the time personally to look into it until early February) 19:18:29 well let's go with trac for now? as I said - I can try to work on it and fesco could review it... 19:18:39 i hate trac 19:18:53 I can look on those tools and make a note about it in our ticket if you want 19:19:03 i mean, my singular opinion doesn't count but man do i hate trac 19:19:09 mmaslano: I can take care too... 19:19:11 jwb: Trac is a lot like Democracy. It's the worst system ever devised... except for all the others. 19:19:37 are we deferring or discussing further? 19:19:37 jwb: the main advantage of trac - it's used in our infra everywhere... 19:19:52 s/main/only/ 19:20:03 jreznik, that isn't an advantage. it's like saying "well, we screwed up once so lets keep doing it" 19:20:03 jreznik: except for where we use bugzilla 19:20:24 mattdm: and bz is not a tracking tool... 19:20:33 nirik: note: I think if we used trac for this, it would promote fedorahosted into a more critical level of infrastructure (as far as freezes are concerned) 19:20:49 abadger1999: right. 19:20:51 except bugzilla is even worse for project tracking than trac 19:20:56 t8m: +1 19:21:00 jreznik: sure it is. but that's basically a semantics argument. 19:21:01 jreznik: I would be strongly -1 to tracking detailed feature progress in trac - that needs to happen preferably in our bugzilla (so that it can be linked with other bugs) or perhaps upstrea 19:21:05 trac is terrible, we should look on different tools, which might be better for tracking process 19:21:14 there's always rt... but I think we should stop trying to dictate tools here. 19:21:23 We can track the feature itself in trac instead of the wiki page, however that's entirely different than the topic of the ticket 19:21:39 mitr: ? 19:22:24 jreznik: "update package foo", "add dependency here", "fix this crash" is the kind of things that needs to be in bugzilla unless we migrate away from bugzilla entirely 19:22:28 mitr, it's actually not clear what's the topic - whether it asks for tracking the feature as a whole or having it split out into multiples of subtasks 19:22:39 Bugzilla is already used to track actual work on features, to greater and lesser degree depending on the feature. 19:22:42 mitr: that's true 19:22:47 mattdm: true 19:23:03 imho subtasks - real bugs, should go into bz 19:23:07 Linking that to a tracking bug is less overhead than developing / integrating a new tracking tool. 19:23:13 t8m: The proposal says "continue to use the wiki as overview" 19:23:21 tracking of features is on wrangler anyway 19:23:29 think of the wiki page as the stuff marketing reads 19:23:33 mitr: good proposal +1 19:24:21 mmaslano: I wasn/t proposing anything I think 19:24:52 Do we want to have a greater bz/wiki/trac conversation here? 19:25:36 tooling is imporant but process is more 19:25:47 so let's first deal with process and then with implementation 19:25:50 * sgallagh wonders if we shouldn't just deploy Launchpad and call it a day... 19:25:52 I'm -1 to pjones (i.e. this really needs a specific proposal that takes care of most of the process, not just people meeting), but the larger-scope discussion isn't necessary I think. 19:26:18 we have 4 minutes left on the 20min timeout 19:26:26 so get to discussing :) 19:26:27 tooling and process are different topics, let's prepare proposals for the next meeting 19:26:39 * nirik is fine with using bugzilla. Anything further is going to be much longer than we have left in this meeting. 19:27:19 The meat of the proposal is: new bugzilla component "Fedora Feature", and tracking bugs for features. 19:27:24 mmaslano: it's all about the whole feature process revamp - not sure "next meeting" is the realistic timeframe :) 19:27:37 To me, the questions are 19:27:38 1) should detailed tracking in bz be mandatory? Mandatory for "important" features? neither? 19:27:40 2) should we start now or wait for hypothetical burndown charts? 19:27:42 mattdm: what does the tracking bug mean? 19:27:48 and taking off my fesco hat for a second, I'll note any new stuff you want infrastructure to maintain/host needs to go through our normal Request for resources process. We won't toss up some random thing just for this with no one maintaining it and it not being fully open, etc. 19:28:05 mattdm: I think goes beyond that a little -- it's how we organize the subtasks to be done for a specific feature. 19:28:30 is it for tracking work on feature or tracking feature process - for a) ok, for b) quite impossible... 19:28:33 mattdm: It's kind of like the way qa uses bugzilla plus tracker bugs plus a lot of documented process 19:28:42 * jreznik has to prepare for Board meeting now... 19:28:55 abadger1999: okay, sure. I don't think that's bad. :) 19:29:07 mattdm: we'd have to build up the documented process, not just decide to use bugzilla with tracking bugs. 19:29:15 abadger1999: and writing tools to make it scalable as just bz is far from enough 19:29:24 mitr: start now, rather than waiting. It's easier to write the charts against real data. 19:29:32 I think this change should be part of the big feature process revamp. 19:29:39 t8m: yes 19:29:40 documented process is in https://fedorahosted.org/fesco/ticket/979. 19:29:42 mattdm: -- Yeah, I dont think it's necessarily bad... but it's a bigger change to thought process than just the shift in implementation 19:29:46 (that's why i voted for deferring) 19:29:49 jreznik: We did reasonably fine with completely manual process, I'm not tooo concencned with scaling. 19:30:17 first let's have process defined as t8m said - then implementation... 19:30:27 pjones proposed that like 10 min ago 19:31:07 +1 deferring as well 19:31:14 * abadger1999 finds a phone for board meeting 19:31:38 ok, that's +5 19:31:44 so we are going to defer this 19:31:55 * jreznik is ok to work with fesco on redefining tools as he thins wiki is not a good tracking tool and it takes a lot of my time to do real tracking, not get out of sync etc. 19:31:58 I'm a little confused about what more is asked for. 19:32:11 +1 to defer while we sort out what we actually want 19:32:26 #agreed defer this until we have a larger overall discussion of the feature process (+:6, -:0, 0:0) 19:32:33 mattdm, more discussion 19:32:56 #topic Next week's chair 19:33:03 Do we just need a more wordy version of the recommendation in https://fedorahosted.org/fesco/ticket/979 19:33:05 ? 19:33:06 ok, who wants to chair next week? 19:33:08 mattdm, no 19:33:19 do we meet next week? 19:33:28 mattdm, discussion of the overall feature process, and then possibly comparison of other tools,e tc 19:33:36 mmaslano, why wouldn't we? 19:34:02 just asking, some people already have vacation or busy schedule 19:34:14 ok, is there anyone that won't be here next week? 19:34:30 * nirik can probibly do it if no one else steps up 19:34:34 Another point: do we need to discuss scheduling of this meeting, or does the current slot continue to work for everyone? 19:34:50 Well, I'll be on vacation for the next two weeks whether we meet or not. 19:34:55 sgallagh, up to you and abadger1999 19:34:58 * sgallagh should be fine with the current schedule 19:35:04 * pjones is fine with the current schedule 19:35:18 * abadger1999 has fpc just before. After next week; nothing after. 19:35:39 abadger1999: are you saying it does work, or doesn't? 19:37:12 pjones: works for me 19:37:22 ok, so we keep the current time 19:37:27 now, are we meeting next week? 19:37:30 pjones is out 19:37:43 or, attending out of the goodness of his heart 19:38:20 I'll be around, though possibly split-attention 19:38:53 * nirik should be around 19:39:03 * abadger1999 can be here 19:39:05 i'll be here 19:39:20 I'll probably be here 19:39:37 that's 5 19:39:47 nirik you want to chair? 19:40:12 want is a strong word... but I will 19:40:24 new guys... either of you want to chiar? 19:40:53 jwb: I can't next week. Too much going on here, may only be paying half attention. 19:40:53 I can be chair if doesn't want 19:41:04 if nirik doesn't want 19:41:43 sold! 19:41:51 #agreed t8m will chair next week 19:41:56 #topic Open Floor 19:42:09 ok, does anyone have anything for Open Floor? 19:42:16 Just, thanks everyone for looking at my tickets even if they're all deferred. :) 19:42:34 mattdm: I think some of them are good ideas... just features is such a mess. ;( 19:43:47 i'll close the meeting in 2 minutes if there's nothign else 19:45:09 ok, thanks everyone 19:45:11 #endmeeting