18:00:33 <sgallagh> #startmeeting FESCO (2012-02-13)
18:00:33 <zodbot> Meeting started Mon Feb 13 18:00:33 2012 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:33 <sgallagh> #meetingname fesco
18:00:33 <sgallagh> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher
18:00:33 <sgallagh> #topic init process
18:00:33 <zodbot> The meeting name has been set to 'fesco'
18:00:33 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m
18:00:54 <pjones> hello.
18:00:56 <mjg59> Afternoon
18:01:01 <limburgher> hey
18:01:04 <mitr> Hello
18:01:05 <mmaslano> hi
18:01:30 <sgallagh> nirik has jury duty and won't be joining us
18:01:39 <sgallagh> notting: Are you around?
18:01:40 <t8m> hello again
18:02:00 * notting is here
18:02:07 <sgallagh> Ok, then let's begin
18:02:14 <sgallagh> #topic #799 Issues with maintainer responsiveness (clamav)
18:02:14 <sgallagh> .fesco 799
18:02:19 <zodbot> sgallagh: #799 (Issues with maintainer responsiveness (clamav)) – FESCo - https://fedorahosted.org/fesco/ticket/799
18:02:58 <sgallagh> So is there anything for FESCo to do here?
18:03:09 <limburgher> Doesn't look like it, yet.
18:03:16 <notting> i suggest "sigh", but that's not a useful response.
18:03:24 <mmaslano> #798
18:03:25 * nb suggests FESCo tell Philipp that he can't dictate how maintainers do stuff
18:03:27 <limburgher> Beats <headdesk>
18:03:50 <nb> philipp seems to think that everyone must do stuff his way and that they are automatically wrong if they disagree
18:04:07 <mjg59> I'm not familiar enough with clamav to make any rational decisions about whether the maintainer is producing reasonable packages or not
18:04:24 <mjg59> But the base accusation ("The maintainer is non-responsive") doesn't seem to be borne out
18:04:25 <t8m> Well Enrico was always known for very special packaging.
18:04:41 <notting> i'd agree that the packages are odd and nonstandard, but not in any way that's explicitly forbidden, i think
18:04:43 <mitr> What t8m says - The clamav daemon package does not ship an init file, for example
18:04:50 <mjg59> I guess what we're actually being asked to do is to overrule the maintainer
18:04:53 <notting> it would be better if they followed normal conventions
18:05:00 <mjg59> Which I guess is possible, but pretty drastic
18:05:20 <sgallagh> I think we should punt this to FPC to determine if this really falls outside the bounds of our packaging policy
18:05:52 <mitr> I don't care about "normal" as much... I do care about having the software be usable in the manner upstream intended a bit
18:06:06 <limburgher> sgallagh, mitr:  Or both if possible.
18:06:17 <pjones> I think what we should probably do is ask FPC to have a look at the packages and see if there's a solution that involves adjusting the packages and/or the rules to fit better in Fedora.
18:06:19 <mjg59> Anyone from FPC around?
18:06:22 <mitr> sgallagh: I can't really see any packaging problem
18:06:30 <sgallagh> I didn't say "normal". I say "acceptable"
18:06:30 <limburgher> I am.
18:06:37 * nb sees no packaging "problem" the packages are a bit unusual, but they work
18:06:48 <nb> i used to use the fedora clamav packages before i changed my server to use rhel
18:07:24 <limburgher> I did too.
18:07:51 <mjg59> limburgher: You think there's any real reason that FPC would object to the packaging?
18:08:34 <nb> as a EPEL maintainer for clamav, I've had a few disagreements with philipp and he comes across as very much "I'm right you're wrong, why aren't you taking my patch i sent, etc"
18:08:37 <limburgher> I'll have a closer look.  Lemme see.
18:09:15 <sgallagh> limburgher: Should we defer this to next week, then? (To give you time to investigate)
18:09:26 <mjg59> I guess we could push this to FPC, but in the absence of any terribly compelling reason it just seems to be pushing work onto them
18:09:43 <mjg59> I'd be inclined to just close with "Learn to play with others"
18:09:47 <limburgher> sgallagh:
18:10:05 <pjones> mjg59: it'd be nice to be able to do that while sending that message to both parties, not just one.
18:10:05 <t8m> I'd say that philipp should demonstrate where if at all the clamav breaks the packaging guidelines and in case it doesn't and the current maintainer is not unresponsive as demonstrated the ticket should be closed
18:10:06 <limburgher> Yeah, and I can bring it up in FPC, too.
18:10:11 <sgallagh> mjg59: I'm with you on that, but if there's a legitimate issue with packaging, we should try to have it fixed.
18:10:20 <sgallagh> t8m: +1
18:10:21 <limburgher> In open floor, for opinions.
18:10:48 * nb very much agrees with "Learn to play with others"
18:11:20 <mitr> t8m: What if it doesn't break the packaging guidelines but "only" breaks legitimate setups?
18:11:21 <pjones> yeah, I don't think any of us are really going to disagree with that statement.
18:11:26 * limburgher seconded.
18:11:34 <sgallagh> mitr: Then the FPC should be sacked :)
18:11:39 <mitr> OTOH that statement doesn't solve anything
18:11:56 <mitr> sgallagh: FPC deals with primarily "packaging", not "what the stuff does" I think
18:12:03 <limburgher> sgallagh, mitr:  Yes.  Kill the FP. . .wait. . .what?
18:12:05 <pjones> mitr: it might be worth investigating a guideline about exposing functionality that's provided by upstream but doesn't work in the package.
18:12:19 <limburgher> Right, more of a "if you're going to do it, do it intelligently".
18:12:23 <pjones> because, I mean, clearly that's bad.
18:12:23 <sgallagh> I thought there was something along the lines of "Must accomplish something when installed"
18:12:25 <t8m> mitr, maybe it breaks some setups to enable other setups to work I don't know I did not study clamav closely
18:12:25 * mitr doesn't really want to add one guideline per FESCo ticket
18:12:27 <limburgher> Less of a "don't do X"
18:12:37 <pjones> yeah, that's the downside.
18:13:06 <sgallagh> limburgher: I didn't say "kill". I'm not a monster. I peter out at "maim"
18:13:42 <notting> was there a specific proposal here?
18:13:53 <sgallagh> (01:10:05 PM) t8m: I'd say that philipp should demonstrate where if at all the clamav breaks the packaging guidelines and in case it doesn't and the current maintainer is not unresponsive as demonstrated the ticket should be closed
18:13:54 <limburgher> sgallagh:  Whew.
18:14:37 <mitr> t8m: I didn't either.  THe submitter's question "why cannot this upstream-provided configuration option be used" looks entirely reasonable, though - and having a documented rationale for the clamav setup would be nice in any case.
18:14:42 <sgallagh> If philipp wants to complain, I'm all for making him do the legwork.
18:15:11 <notting> sgallagh: +1 to that
18:15:50 <mitr> We do have enough formal reasons to close the ticket - but then we justly deserve receiving another ticket with a different resolution next week
18:16:00 <limburgher> mitr:  Agreed, I've had people come to me and say "Why do you do X this way?"  And I'll look at it and say, "Gee, X is stupid, you're right, let's Y".  And sometimes, Y is stupid, and X really makes sense.  But looking at it is healthy now and again.
18:16:17 <pjones> yeah, tbh, both of them just need to work together better.  he's not unresponsive, so...
18:17:38 <sgallagh> We're at 15 minutes
18:18:11 <mmaslano> he's not unresponsive. I wonder if there are more bugs about the same issue?
18:19:09 <sgallagh> Do we want to continue discussing this further?
18:19:32 * sgallagh is -1 to continuing. I think we're just circling at this point.
18:19:34 <limburgher> Not especially.  I think we've got what we need to move forward for now.
18:19:43 <mitr> Proposal: Ask ensc to document (at least by a link) the packaging rationale inside the package; close ticket and let philipp reopen with a specific proposal
18:19:54 <sgallagh> mitr: +1
18:20:00 <t8m> mitr, +1
18:20:01 <mitr> IOW, if philipp wants this package orphaned, the proposal better include "... and I will maintain it"
18:20:05 <limburgher> mitr: +1
18:20:11 <t8m> mitr, sure
18:20:25 <mmaslano> +1
18:20:45 <pjones> sure, why not.  +1
18:20:57 * sgallagh counts +6. Any dissenters?
18:21:04 <t8m> mitr, sure, FESCo's misson is not 'finding a maintainer for a random package'
18:21:12 <notting> +1
18:21:20 <limburgher> t8m: Nah, we could script that. :)
18:21:54 <t8m> limburgher, you mean by reassigning packages to a random account from the packager group?
18:22:01 <t8m> limburgher, :)
18:22:16 <sgallagh> #agreed Ask ensc to document (at least by a link) the packaging rationale inside the package; close ticket and let philipp reopen with a specific proposal
18:22:31 <limburgher> t8m:  I leave the implementation as an exercise for the reader. :)
18:22:56 <ctyler> .hiub #fedira
18:22:58 <sgallagh> There are two additional tickets that weren't on the agenda (because I found out about them after the fact) but since they deal with Feature Freeze, I think we should discuss them.
18:23:03 <sgallagh> Unless anyone has objections
18:23:11 <t8m> no objection
18:23:16 <limburgher> Go for it.
18:23:39 <sgallagh> #topic #801 Feature Freeze Exception: Thermostat
18:23:39 <sgallagh> .fesco 801
18:23:42 <zodbot> sgallagh: #801 (Feature Freeze Exception: Thermostat) – FESCo - https://fedorahosted.org/fesco/ticket/801
18:24:06 <mitr> I have asked adamw, QE doesn't care
18:24:08 <mitr> adamw: nope, looks like it doesn't affect key functionality at all.
18:24:12 <mjg59> This is harmless, but at the same time there's no reason that this has to go through the feature process other than marketing
18:24:21 <notting> i'd be fine with allowing this as a feature - it's a leaf node w/o dependenices on it in particular
18:24:22 <mjg59> It's one new package, right?
18:24:29 <omajid> right.
18:24:50 <mjg59> So it can be uploaded even if we say no
18:25:09 <sgallagh> Yes. The only real effect here is whether it's called out as a Feature
18:25:20 <mitr> It's all about the relnotes, and being satisfied enough with the quality.  Given that QE doesn't care, I'm +1
18:25:26 <mjg59> Blah blah feature process +1
18:25:28 <limburgher> I guess I feel like it's fine for a feature, but the package can be in way before f18 comes out.  So calling it out as a feature seems extraneous, unless it's for f17.
18:25:29 <sgallagh> omajid: Is the package approved already?
18:25:35 <omajid> sgallagh: no, not yet.
18:25:42 <limburgher> has a review started?
18:25:43 <mmaslano> +1 because our feature process is wrong
18:25:54 <sgallagh> omajid: Will it be reviewed and uploaded to Fedora before tomorrow?
18:26:09 <omajid> limburgher: no. although dbhole did volunteer (offline) to review it.
18:26:11 <pjones> given its age as a thing at all, how sure are we that we even want to do that?
18:26:18 <mitr> sgallagh: QE doesn't care, so does anyone?
18:26:21 <t8m> The package is not yet reviewed so -1
18:26:37 <sgallagh> mitr: If it's not in by tonight it means it won't be on the Alpha release (probably)
18:26:44 <sgallagh> Which makes testing it much more complicated.
18:27:01 <limburgher> +1 for f17 if it's in by tonight, otherwise +1 for f18 (i suppose)
18:27:02 <mitr> Anyone interested enough to test this will have to install it manually anyway, won't they?  In that case it doesn't really matter whether it makes the media.
18:27:14 <sgallagh> I'm -1 on including this as a Feature. Feel free to submit it just as a general package between alpha and beta
18:27:35 <vanaltj> I can review today.
18:27:54 <pjones> yeah, I'm also -1 as a feature, but feel free to continue packaging and whatnot.
18:28:07 <sgallagh> Count is  +2/-2 (assuming reviewed today)
18:28:10 <sgallagh> Any other votes?
18:28:30 <sgallagh> Sorry, +3/-2 (missed mitr above)
18:28:45 * sgallagh really can't count. +4/-3
18:28:49 <sgallagh> Or type...
18:28:52 <sgallagh> +4/-2
18:29:04 <pjones> +some/-someothers
18:29:10 * sgallagh chuckles
18:29:15 <nb> lol
18:29:26 <limburgher> Margin of error +/-14
18:29:32 <sgallagh> haha
18:29:35 <dbhole> :)
18:30:16 <sgallagh> Ok, so any other votes? pjones? notting?
18:30:23 <pjones> I was a -1 already I think.
18:30:23 <sgallagh> Oh sorry, pjones voted.
18:30:28 <sgallagh> Who am I missing
18:30:42 <notting> sorry, didn't explicitly say '+1'. doing so now.
18:30:45 <sgallagh> Oh, so I really can't count after all. +4/-3
18:30:51 <sgallagh> Now +5/-3, so it passes.
18:31:05 <sgallagh> #agreed Thermostat is granted a Feature Exception
18:31:20 <sgallagh> Moving on to current Feature status
18:31:23 <sgallagh> #topic #802 F17 Features - progress at Feature Freeze
18:31:23 <sgallagh> .fesco 802
18:31:24 <zodbot> sgallagh: #802 (F17 Features - progress at Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/802
18:31:51 <sgallagh> So we have a stack of approved features that are not listed as complete for Feature Freeze.
18:31:54 * nirik arrives late (on lunch break from jury dutry)
18:32:09 <limburgher> norm!
18:32:16 <rbergeron> !
18:32:18 <sgallagh> huh?
18:32:34 * rbergeron wonders if that was "normal" or a cheers bar call
18:32:40 <limburgher> B)
18:33:03 <limburgher> Sorry, too much coffee.
18:33:11 * rbergeron notes that some features in the ticket are "Shiny marketing" and others are "critical-path-ish/dependency oriented" looking.
18:33:32 <sgallagh> Well, I think we want to look into whether any of these need to be forced into their "contingency plan" at this time
18:33:43 <limburgher> Do we have a sense of how solid the recorded complete percentages are?
18:33:49 <sgallagh> Not at all.
18:34:08 <t8m> I think not at all solid percentages :)
18:34:11 <rbergeron> I'm asking for (a) sanity check on those lists, (b) Probably shiny marketing passes for the group of shiny features (I expect the vote may go as the above vote went), (c) feedback on the latter group.
18:34:12 <mjg59> So we probably need to tell feature owners to update percentages as appropriate
18:34:12 <limburgher> Then we probably have to assume accuracy, feature owner responsibility, etc.
18:34:12 <sgallagh> I propose we go through this list and decide which ones we really need to look into and dole out assignments to address them
18:34:35 <limburgher> mjg59: Indeed.
18:34:40 <mjg59> I think it makes more sense to prod the owners before wading in ourselves
18:34:47 <rbergeron> mjg59: indeed - and they've been harassed - some have dates that are more recent, others do not.
18:34:48 <sgallagh> I think "Services in private /tmp" belongs in the Critical bucket, personally
18:34:59 <mjg59> rbergeron: Oh, that's already happened? Ok.
18:35:02 <rbergeron> I'm mostly concerned about the sanity check and critical-looking stuff, that might break things.
18:35:16 <limburgher> gcc has been in for awhile.
18:35:24 <notting> sgallagh: that falls in with sysvtosystemd - it's sort of an unbounded effort of package conversion
18:35:38 <rbergeron> I'm happy to continue to prod on all of them - many got updated last week.
18:35:53 <mitr> I can't see anything that's screams "we absolutely must have this testable by Alpha" to me
18:35:58 <sgallagh> notting: Well, that's more of a case of "if it's only done partway for a specific package, that package will be broken" sort of thing, IIRC.
18:36:14 <mitr> Several of the service/daemon changes are a bit risky, but usually easy enough to revert
18:36:40 <sgallagh> mitr: Gnome shell software rendering REALLY needs to be testable for Alpha
18:36:50 <sgallagh> Or else it won't get any testing until beta, most likely.
18:37:00 <mitr> sgallagh: Installed it today - gnome-shell crashes in the first minute of use
18:37:03 <pjones> this part of the process is why I strive not to own things listed as a feature.
18:37:06 <sgallagh> (Because it will need to be on the live media)
18:37:30 <sgallagh> mitr: So what you're saying is that it works better than on ATI? :)
18:37:44 <notting> proposal: move mkdumprd, eclipse juno to shiny-marketing features - those are leaf nodes
18:37:52 <sgallagh> notting: +1
18:37:55 <sgallagh> (to both)
18:37:55 <nirik> notting: +1
18:38:00 <pjones> notting: +1
18:38:02 <t8m> notting, +1
18:38:04 <mitr> "power management" as well - that's tuned, not that often used
18:38:13 <limburgher> notting: +1
18:38:23 <notting> +1 to mitr's addition as well
18:38:26 <sgallagh> mitr: +1
18:38:30 * rbergeron notes to feel free to delegate to me whatever, happy to fill in morein ticket, and has to depart for about 20m, will read logs.
18:38:46 <sgallagh> rbergeron: Thanks for doing the legwork here
18:38:58 <mitr> (and +1 to notting)
18:39:13 <sgallagh> #agreed move mkdumprd, eclipse juno to shiny-marketing features - those are leaf nodes
18:39:18 <t8m> mitr, +1
18:39:20 <rbergeron> sgallagh: 'tis my job (the old one, still my job for now, lol)
18:39:28 <mitr> Wait.... what is the criterion here exactly?
18:39:36 <mitr> Almost everything is "leaf" AFAICS
18:39:53 <sgallagh> mitr: Basically, which things we can tolerate not being 100% at Alpha release.
18:40:05 <notting> mitr: "things that might require fesco involvement b/c they might break stuff if they're not in/get reverted/etc"
18:40:08 <mitr> So is the criterion a) "won't break the rest of the system" b) nobody wiill notice that it is broken anyway, c) something else?
18:40:19 <pjones> sgallagh: that's easy - all of them.
18:40:20 <sgallagh> Proposal: gnome-shell software rendering must be at least minimally usable or else deferred to F18
18:40:34 <mitr> (in particular, doesn't mkdumprd fail a) ? )
18:40:44 <mjg59> What do QA feel about that?
18:41:09 <notting> mitr: if mkdumprd fails, kdump fails. rest of the system works fine
18:41:40 <sgallagh> pjones: I disagree (see my comments on software rendering)
18:41:49 <nirik> I think we should stress to feature owners that there's no problem with slipping to the next release... they can get their work landed in rawhide now.
18:41:51 <sgallagh> We need to retain fallback mode if that's broken/unusable
18:41:58 <mitr> I'm a bit worried about private /tmp - that's many packages, and, which is much more, many different maintainers, so reverting would be a huge pain
18:42:08 <pjones> sgallagh: I don't see any reason that has to be true in alpha - it can be included but not turned on until after alpha if it's known broken, for example.
18:42:09 <mitr> sgallagh: fallback mode is still there
18:42:25 <pjones> or as mitr says.
18:42:47 <sgallagh> pjones: As I said, if it's not available on the live media for Alpha, it *will not get enough testing* to be safe to ship
18:42:54 <sgallagh> In my estimation, at least
18:43:07 <pjones> you can't be serious.
18:43:12 <mjg59> sgallagh: That's why I asked what QA think
18:43:34 <limburgher> I'm comaint on one I'm fixing right this second. . .
18:43:42 <pjones> sgallagh: that makes alpha radically more aggressive than what we've required in the past.
18:44:10 <pjones> effectively you're saying that anything that touches multiple packages has to work 100% by alpha.
18:44:17 <sgallagh> Not at all
18:44:26 <notting> alpha criteria is "testable". don't see anything that makes it not testable?
18:44:49 <sgallagh> I'm saying a core piece of the entire desktop crashing and making the entire system unusable qualifies as untestable
18:44:58 <sgallagh> It prevents much of the rest of the system from being testable
18:45:11 <sgallagh> (short of installing another desktop environment)
18:45:11 <mjg59> Then it's a release blocker
18:45:12 <mitr> sgallagh: Nah, it's stable enough that you can switch to fallback mode in a try or two
18:45:15 <pjones> so what you're saying is "not 100%" means "crashing", which is clearly not the case.
18:45:21 <mjg59> Surely?
18:45:33 <nirik> which bug are we talking about here?
18:45:34 <mitr> I wouldn't arrgue with QE classifying it as a release blocker, but it is testable enough IMHO
18:45:36 <sgallagh> pjones: I'm saying that's what I was told is happening right now, in this very discussion
18:45:51 <pjones> sgallagh: in this discussion you've been told that fallback mode still works
18:45:58 <mitr> nirik: No bug - a temporary VM that I foolishly deleted along with the abrt core
18:46:27 <mjg59> So we have one report of a situation in which software compositing is crashing
18:46:35 <nirik> ok, well, hopefully someone else will also hit it or you can duplicate it and make it an alpha blocker?
18:46:40 <mjg59> And this is somehow "This feature must be dropped" instead of "This is a bug"
18:46:55 <notting> proposal #3: move sysvtosystemd and privatetmp to 'critical' list (i.e., things fesco might need to check with)
18:47:10 <t8m> notting, +1
18:47:14 <limburgher> notting: +1
18:47:18 <mjg59> notting: +1
18:47:18 <pjones> notting: I can +1 that.
18:47:26 <mitr> notting: +1 to privatetmp; sysvtosystemd should be a separate ticket perhaps
18:47:29 <sgallagh> notting: +1
18:47:37 <nirik> I guess so, +1
18:47:59 <mitr> As it is, sysvtosystemd pretty much cannot be a blocker unless we consctiously decide to make it one
18:48:25 <sgallagh> mjg59: You're overstating my position. It's more "if we can't manage to get it into testable form in time for Alpha, maybe it should wait until F18 and be made to use fallback by default (with an option to enable it)
18:48:48 <notting> ok, and as sgallagh has started with sw render - do we want to start going through each of that 'critical' list now, or assign each one to someone to check out and report back next week, or...?
18:49:22 <sgallagh> I suggest we divvy up the critical list and report back in a week
18:49:25 <mmaslano> I'd rather go through the list later.
18:49:57 <mjg59> sgallagh: Again, what's QA's position on this?
18:50:14 <mitr> mjg59: Do we have anyone from QA here?
18:50:29 * notting looks at the lurking adamw
18:50:31 * nirik is fine with getting more data. Is next week too late to revert some features tho?
18:50:31 <mjg59> adamw: ^
18:50:32 <mitr> Perhaps we could get an update from the feature owners (with either a reassuring status, or a commitment to implement fallback)?
18:50:54 <mmaslano> yes, that would help too
18:50:58 <mjg59> It's not difficult to revert the feature by default. It's also unclear that what's being hit isn't something with a simple fix.
18:51:00 <mitr> AFAICS "GCC 4.7" is the only feature really difficult to revert, and we seem to have managed that one already
18:51:17 <mjg59> It's absolutely unclear that beta is too late for it to land
18:51:30 <mjg59> (by default)
18:51:39 <mjg59> I'd want QA to tell us that before we start pronouncing on it
18:51:55 <pjones> nor is it unclear that the beta would be too late to turn it /off/ by default if that's the right thing to do then.
18:54:10 <nirik> so, what action(s) are we gonna take here. ;)
18:54:56 <sgallagh> From the sound of it, none at all.
18:55:09 <limburgher> I thought rbergeron was volunteering to hound the critical list for us.
18:55:31 <nirik> are any of these things needing enabling by default?
18:55:40 * nirik is looking at http://fedoraproject.org/wiki/Feature_Freeze_Policy
18:55:49 <notting> i'd be fine with assigning a fesco member to politely ensure that the critical features are updated, and starting discussions of needed fallbacks
18:55:57 <notting> (i.e., one member per feature)
18:56:17 * nirik is ok with that.
18:56:22 <limburgher> Sure.
18:56:50 <notting> ok, volunteer for NM hotspots?
18:57:12 * nirik can take that one.
18:57:36 <notting> i'll take sw rendering
18:57:47 <notting> volunteer for abrt backtrace dedup?
18:57:51 <t8m> I'll take it
18:58:02 <sgallagh> I'll take privatetmp
18:58:08 <notting> volunteer for NM enterprise networking?
18:58:10 <limburgher> dibs
18:58:28 <notting> volunteer for gcc47 (should be easy!)
18:58:37 <pjones> I can do that.
18:58:48 <notting> and last is sysv to systemd
18:59:14 <sgallagh> I don't think we have any real definition of what success means there
18:59:35 <sgallagh> We seem to have pretty much given up on ever having converted absolutely everything
18:59:38 <mitr> *shrug* I can take it; the per-package nature really means that "fallback" is meaningless
18:59:47 <limburgher> I think it's just an effort to keep the ball moving.  Which is working.  (wonders if we need a concerted push effort)
18:59:58 * nirik did the last of his not long ago.
19:00:10 <nirik> some more provenpackagers working on it could really help
19:00:12 * limburgher too.
19:00:13 <notting> ok, i'll update the ticket with who's poking whom
19:00:20 <sgallagh> Ok
19:00:25 <mitr> sgallagh: I don't think we have ever discussed it, at least this election season
19:00:35 <mitr> But the default is certainly "give up" :(
19:00:57 <sgallagh> I pushed hard for it in F16, and we at least managed to hit all of the stuff on the DVD
19:01:13 <sgallagh> But I think it's a long journey to 100% from here
19:01:16 <limburgher> I'm a provenpackager, maybe I could go through the list, ask "any objection to my doing this in rawhide" and see what happens?
19:01:28 <limburgher> I mean, they've been given the unit files. . .
19:01:42 <nirik> yeah.
19:01:43 <sgallagh> limburgher: I think VikingIce came up with unit files for most packages
19:02:03 <pjones> I'm not sure 100% needs to be the goal.  If something truly isn't getting updated to use systemd, then maybe the best thing to do is let it languish until sysv stops being supported and see if anybody notices ;)
19:02:19 <limburgher> sgallagh: Exactly, and included them in the bugs.
19:02:22 <sgallagh> Should we vote on whether limburgher should be given that authority? It's technically a little beyond standard provenpackager
19:02:39 <sgallagh> pjones: sysv will never go away
19:02:41 <mitr> pjones: I'm philisophically opposed to that.  10 features where 5% is missing equal sum up to a pretty messed-up system
19:02:42 <limburgher> sgallagh:  Note that I'm proposing offering, not forcing.
19:02:50 <sgallagh> If only because we need to still be able to support 3rd party packages
19:03:02 <limburgher> sgallagh:  Right.
19:03:11 <pjones> mitr: only if it's missing in packages you're actually /using/.
19:03:12 <limburgher> mitr: As am I.
19:03:15 <nirik> we already said last cycle that any provenpackagers who wanted to work on it are welcome. ;)
19:03:19 <nirik> I'm happy re-iterating that.
19:03:28 <sgallagh> limburgher: I'm on board with the "forgiveness rather than permission" approach :)
19:03:40 <limburgher> sgallagh:  Oh $_DEITY. . ..
19:03:50 <pjones> yeah, I don't think it's any more broad than provenpackager has always been.
19:03:53 <nirik> perhaps in another few cycles we could get systemd to start warning about unconverted things. ;)
19:03:56 <mitr> limburgher: IMHO, that's a huge task.  If you want to do this, I certainly won't stop you
19:04:02 <mitr> and what pjones said
19:04:06 <pjones> nirik: yeah, that's a good idea.
19:04:15 <limburgher> mitr:  I also never claimed that I'd finish. :)
19:04:17 <sgallagh> It already kind of does
19:04:19 <mitr> nirik: warning about every vendor package?
19:04:43 <tibbs> Some of us have packages with really complicated initscripts.  It is simply not remotely trivial to convert everything.
19:04:51 <nirik> sure... at some point. Doesn't need to be soon, but I think that might help with the last holdouts.
19:05:03 <pjones> mitr: obviously we should check if the package requires redhat-lsb and if so then it's clearly too broken to ever expect fixing.
19:05:08 * rbergeron returrrrrrrrrrrns
19:05:22 <notting> tibbs: /etc/init.d/network. wheee.
19:05:24 <mitr> We can find the holdouts via a simple repoquery, there's no real need to do it at runtime
19:05:28 <pjones> tibbs: I don't think anybody said it was trivial.
19:05:57 <mitr> notting: The "convert to .service" part is simple, or am I missing anything?
19:06:09 <limburgher> tibbs:  Of course.  And if it looks too scary, or whatever, I'll ping the maintainer for input.  Or walk away.
19:06:17 <notting> mitr: convert to service in a meaningful native way. ifup@<foo>.service, etc.
19:06:22 <limburgher> tibbs:  But some are so simple there's no reason not to.
19:06:45 <notting> mitr: what that means for network.target, if each ifup@<foo> is independent, how do you enforce ordering/dependencies, etc.
19:06:56 <mitr> notting: Hm; wouldn't that be so incompatible that there wouldn't be any point?
19:07:03 <mmaslano> not for all services
19:07:27 <notting> mitr: possibly. but, similarly, if all you are doing is wrapping the shell script in a service file that calls it, then is there any point?
19:07:39 <tibbs> Sure, but my point is that there's a lot of grousing going on over "everything isn't converted" while some of it really isn't convertible since systemd doesn't actually do what initscripts do.
19:07:47 <pjones> notting: we have to check the checky box!
19:07:57 <mitr> notting: reasonable dependencies - at the very least, the numerical dependency ordering got actively broken by the switch to systemd, so it needs a human to check the dependencies.
19:08:25 <notting> mitr: think we've gone a bit afield for fesco, maybe table for later
19:08:34 <mitr> Sure
19:08:47 <notting> should we move on?
19:08:53 <sgallagh> Yes, let's
19:08:56 <pjones> oh, yes.
19:08:59 <limburgher> :)
19:09:15 <sgallagh> #action FESCo members will review the critical Features and ask owners for updates
19:09:27 <sgallagh> #topic Next week's chair
19:09:38 <notting> i will miss next week's meeting, so Not Me.
19:09:45 <sgallagh> As will I
19:09:58 <mjg59> I'll also be away
19:09:59 <sgallagh> (I'll update the ticket with my findings on privatetmp)
19:10:01 <mjg59> As will pjones
19:10:07 <mjg59> So maybe skip next week?
19:10:24 <t8m> I will be also away
19:10:33 <sgallagh> Ok, no quorum, so we skip next week
19:10:37 <nirik> ha. I was going to say I could do it, but seems no quorum
19:10:52 <sgallagh> How about the following week?
19:10:57 <limburgher> What do we do with results of feature prodding, just hold for 2 weeks?
19:11:14 <pjones> limburgher: try as much as possible to handle them in tickets?
19:11:17 <notting> report in the ticket as soon as you have the info?
19:11:20 <nirik> pjones: +1
19:11:26 <sgallagh> I suggest updating the tickets and maybe have a vote in tickets if something urgent comes up
19:11:39 <limburgher> pjones, sgallagh, notting: sounds like a plan.
19:12:23 <sgallagh> Ok, so volunteer to chair the Feb 27 meeting?
19:12:35 <nirik> I can do it...
19:12:49 <sgallagh> #action nirik to chair Feb 27 meeting
19:12:56 <sgallagh> #topic Open Floor
19:13:40 <mitr> Update on #798: got some response, but it's all Greek to me and I didn't have time to follow up or test this myself - so I suppose we'll revisit in 2 weeks
19:13:40 <sgallagh> Anything for open floor?
19:13:48 * nirik sees gcc 4.7 feature move to 95%
19:14:00 <limburgher> Much better. :)
19:14:02 <mitr> What about the JBoss AS 7 feature exception?
19:14:08 <pjones> nirik: probably because I mailed jakub a few minutes ago ;)
19:14:13 <nirik> yeah.
19:15:20 <sgallagh> mitr: What about it?
19:15:59 <mitr> sgallagh: FESCo was asked for an exception, so we can approve/reject/postpone I suppose
19:16:40 <mmaslano> well, they are working on it, but they have many packages in plan. So probably they won't package everything...
19:16:49 <sgallagh> mitr: Ah, it didn't have the Meeting keyword, so I missed it
19:17:08 <sgallagh> mmaslano: That sounds like "postpone" to me
19:17:23 <mmaslano> sgallagh: but nothing will be broken
19:17:37 <mmaslano> I guess these are only leaf packages
19:17:37 <mitr> I suppose it sort of belongs in "shiny features" in #802 - except that ovirt depends on it.
19:17:43 <mitr> mmaslano: ^^^
19:18:01 <sgallagh> It's blocking ovirt? Great...
19:18:53 <mmaslano> than I suggest ask jboss ticket and ovirt what's the status
19:18:58 <mitr> sgallagh: it seems ovirt feature owners know about this
19:19:12 <sgallagh> ok
19:19:27 <mitr> Given that this is all new packaging, I don't think we can do much to help
19:20:21 <limburgher> Other than reviews galore.
19:20:22 <sgallagh> Other than offering to help with package reviews, I agree. (On the other hand, I know nothing about Java packaging, so I'll admit to being useless here)
19:20:31 <limburgher> sgallagh: DItto.
19:21:50 <mitr> *shrug* proposal: close the ticket with thanks for the update, and no action currently
19:22:03 <t8m> mitr, +1
19:22:07 <sgallagh> mitr: +1 I don't see much else we can do
19:22:11 <notting> ... sure. +1
19:22:14 <notting> (have to head out now)
19:22:32 <limburgher> +1
19:22:35 <mmaslano> yes +1
19:22:55 <pjones> whatever.  +1./
19:23:05 <nirik> sure, +1
19:23:23 <sgallagh> #agreed close the ticket with thanks for the update, and no action currently
19:23:28 <sgallagh> Anything else for open floor?
19:24:19 <limburgher> Nope.
19:25:22 <sgallagh> I'll end the meeting in two minutes if no one has anything else
19:26:29 * abadger1999 some notes from reading backlog
19:26:37 <sgallagh> abadger1999: Hit me
19:26:39 <abadger1999> Definition, such as it is of testable: http://fedoraproject.org/wiki/Features/Policy/Milestones
19:26:58 <abadger1999> in new feature, policy we probably want to clarify that a bit /me makes a note to do so
19:27:09 <abadger1999> proposal for the systemd conversion
19:27:32 <abadger1999> make viking_ice a provenpackager and give him explicit permission to make conversions to f18 between now and f17 release.
19:27:45 <abadger1999> Ya'll can discuss that at a later meeting :-)
19:27:52 <abadger1999> That's all from me.
19:28:08 <sgallagh> abadger1999: Please open a ticket for the provenpackager (and make sure to CC VikingIce :) )
19:28:52 <mitr> viking_ice in mail: FWIW, "I'm not a provenpackager and have no interested in becoming a package maintainer all thou I would not mind have the ability to fix things here and there if I came across them."
19:29:07 <mitr> sorrh, that FWIW is mine
19:29:16 <limburgher> Yeah.
19:29:26 <abadger1999> mitr: Yep.  That's kinda why this is a special fesco request...
19:29:48 <mitr> OK, why not
19:30:00 <abadger1999> it's about implementing a single type of change that happens to require touching a multitude of packages.
19:30:13 * abadger1999 will open a ticket laying out the specialness.
19:30:14 <limburgher> abadger1999: I'm hearing Casey Casem read that. . .
19:30:52 <abadger1999> :-)
19:30:53 <mitr> My preference would be to announce that any package that isn't converted by F18 Alpha is automatically orphaned & dropped one week later, but I suspect that would be controversial :)
19:31:21 <limburgher> mitr:  Um, yeah, a bit. :)
19:31:52 <mitr> At the very least the DVD is done.
19:32:12 <sgallagh> mitr: I proposed that at F16 and got nasty looks :)
19:33:26 <sgallagh> Anything more to discuss?
19:35:18 <sgallagh> Closing out the meeting in 60s
19:36:11 <sgallagh> #endmeeting