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