18:07:27 #startmeeting FESCO (2012-12-05) 18:07:27 Meeting started Wed Dec 5 18:07:27 2012 UTC. The chair is notting. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:07:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:07:38 now with an actual correct date 18:07:50 #topic 896 - Refine Feature Process 18:07:53 .fesco 896 18:07:55 notting: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896 18:08:34 #meetingname fesco 18:08:34 The meeting name has been set to 'fesco' 18:08:37 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 18:08:37 Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 18:08:48 ok, apologies. back to the feature process 18:09:27 so there was some discussion on fedora devel list but I the things discussed were mostly orthogonal to the proposed changes 18:10:01 * nirik wonders if we shouldn't make sure to have a fudcon session on this and hash out a more concrete proposal/revamp? 18:10:14 nirik: I really think we should 18:10:40 nirik, that basically means postponing the changes to F20 features?? 18:10:44 I'm not against much of mmaslano's proposal... it seems a step in the right direction, but might not be worth doing that only to redo it again soon. 18:11:13 nirik, I think we should do at least some changes now 18:11:13 I suppose. Do we have any f19 features ready yet? 18:11:16 nirik: nice, but only jreznik from group which proposed the feature process will be there 18:11:36 mmaslano, +1 18:11:38 if we need to get more people there to fix the feature process and we think that's the best spot, then say so and i'll see if i can get the money. 18:11:41 we can/should have irc at least to help others provide input 18:11:43 just ask. 18:11:55 nirik: that's the plan, to make broader discussion on revamping process, but more for f20... this proposal is smaller one, to help now 18:12:43 i think the problem we have is that list discussion does not seem to help make the propsal concrete, and either we domainate the fesco meeting until we come up with one, or we do it outside. all options are suboptimal 18:12:46 * jreznik promised on Board the call for FUDCon session after Beta - just wanted to sort it out on FESCo before with this proposal 18:13:41 the idea was - propose "smaller" changes to current process as F19 is behind the doors 18:13:49 so, what do folks not like about the proposal? perhaps we could remove those parts and just accept the rest? 18:14:02 jreznik, +1 18:14:05 I think so 18:14:34 or take the parts piecemeal? 18:14:35 nirik: the most? it's not solving every problem in the universe 18:14:54 otherwise I did not see any strong objections... but maybe I'm just blind :) 18:14:59 jreznik, heh :) 18:15:10 jreznik, I did not see any strong objections either 18:15:10 if you consider it as "small first step" 18:15:13 well, there were some questions/discussion about the assigning a fesco member to each feature. 18:15:24 i'm here now. apologies for being late 18:15:24 * nirik notes https://fedoraproject.org/wiki/User:Mmaslano/Feature_process is the link 18:15:25 nirik: ok, that part 18:15:35 johann came with additional changes eg. orphaning old packages, but that's outside of feature process 18:15:54 * limburgher sorry i'm late 18:16:11 * nirik nods. 18:16:18 nirik: so, I assume fesco member interested in the feature should help feature owner, on the meeting would someone volunteer 18:16:20 nirik: for that sheppard think - I can take more responsibility for that as wrangler but still we would need a good way how to communicate it to fesco 18:16:29 What if there's no fesco member interested in the feature? 18:16:29 yeah, I still don't like the "complex features" plan at all tbh 18:16:35 mmaslano: nods 18:16:49 mjg59: round-robin? 18:16:52 pjones: objections? 18:16:55 pjones, can you be more specific? 18:16:58 limburgher: That sounds pretty awful 18:17:13 jreznik: t8m: we had a whole conversation about what's not good about it last week. 18:17:20 mkg59: Agreed. 18:17:24 limburgher: For instance, the degree to which I'm going to be useful in shepherding a ghc transition is minimal 18:17:24 or what if we have a bunch of features and every fesco person gets like 4-5 of them... thats a lot of load. 18:17:54 pjones, I read the log but did not find anything serious 18:17:55 I think the onus should, in the general case, be for the feature owner to be responsible for working with the rest of the distribution 18:17:58 nirik: still less than everything in the hands of feature wrangler (and not saying I don't want to take a part of that) 18:18:08 fesco shouldn't need to be involved in the vast majority of cases 18:18:20 sure, I think more communication is good, but not sure that idea is the best way to do it. 18:18:36 * nirik likes the 'mail devel-announce about your new feature' idea. 18:18:52 jreznik: well, either the idea is that it shouldn't be much direct work, and it's just process advisory, or it it's more than that. Last week it was made to sound like it's that. In which case it would seem the feature wrangler is still in the best position to do that - in fact it's the wrangler's job. 18:18:53 mjg59: the sheperd is there also for tracking process and know the real status 18:19:05 So if fesco is doing it, I'd like to see the feature wrangler's role addressed at the very least. 18:19:07 nirik: I'd say that's the main idea behind - and if we would stick with old process for f19, I will do it even in that case 18:19:12 some features will be easy to "shepperd" some won't 18:19:13 if the feature owner isn't being responsible/accountable with their status, i don't know that delegating it to a fesco member is *better* 18:19:18 mmaslano: Which shouldn't be necessary! 18:19:31 also, I am very happy to help anyone in Fedora get something done if they come to me, but it's much less efficent for me to go nag someone every week... "do you need any help?" 18:19:54 nirik, I don't see any nagging in the proposal 18:19:56 but also we choose the feature wrangler *because* we need a shepherd sometimes, and we should choose somebody who's strong suit that is. it's not what we choose fesco members for. 18:19:59 mjg59: the fact is that we've had features where we learn about blocking important issues only by the time of beta RCs fairly frequently. "It shouldn't happen" but it odes 18:20:20 mitr: I don't think we solve the problem that a minority of features are being badly managed by imposing extra management on top of features 18:20:32 pjones: I'd be ok with that - for that "sheppherd sometimes" 18:20:35 nirik: or worse - be a blocker in their progress... 18:20:38 mitr: Especially given that the desire is for there to be less fesco involvement in most features 18:20:43 t8m: well, a 'shepard' is expected to keep up on the status of the feature right? so, that implies to me that they must talk to the feature owners often and ask them the status? 18:21:04 it seems like a step in exactly the wrong direction. 18:21:18 mjg59: What is the alternative? individually impose extra management requirements on projects that have had a bad history? 18:21:22 an alternative idea would just be to rope the feature owners for complex feature into directly reporting to fesco. 18:21:24 so, what would folks think of dropping the shepard part of this? are there other parts folks don't like after that? 18:21:27 a feature mentor opt-in or "requested because it's a particularly sticky feature" seems less heavy-handed 18:21:28 * jreznik is ok with skipping sheppard part - and willing to help - just it will need a closer cooperation with fesco... 18:21:29 mitr: That'd be one option 18:21:36 frankly, i see the shepard role as a human nag for filling out the 'status' section on the feature pages 18:22:08 notting: just reporting to fesco is not enough... /me knows the pinging when deadline is around to get a status... someone has to be nagging... 18:22:10 mitr: there's no reason to make that pejorative - we can appoint a shepherd for any feature we desire needs /extra/ attention. but there's no reason to require that to be a fesco member. 18:22:39 jwb: it should be more - not only pinging (I do it, I can do it) for status but understand the feature 18:22:41 pjones: No, but i think that should be the preference. 18:22:50 jreznik: Yes. 18:22:50 notting: I don't think reporting directly avoids the miscommunication problem; a shepherd that is directly trying out the feature would, I think, give FESCo more reliable information 18:22:54 pjones: than you can leave it to feature owner and then you are back at the problem that fesco will be pinging the owner without any result 18:23:01 jreznik: i mean, summon them to the meeting. have a meeting item to go through the complex features with explicit representation from the owner required. 18:23:15 notting: ok 18:23:16 I.e. not "update the percentage", but "I tried this and it doesn't work / has anybody talked to infra about this?" 18:23:43 notting: I do not think more people will be willing to create visible feature if they have to attend (another) meeting 18:23:53 and yeah, it could be limited to only a few high touch features 18:23:56 mitr: exactly 18:23:57 jreznik, fesco should understand the feature _before_ it's approved 18:24:06 jreznik, not as an evolution of nagging about it 18:24:14 (and then agenda items live in the etherpad forever and you have 30 people in the r^Wfedora meeting and oh god what have i created) 18:24:14 mmaslano: the answer to alleviating the constant useless ping is not to make it more constant 18:24:25 jwb: That eseentially means the feature has to be feature-complete at the time of proposal 18:24:53 mitr: or at least testable. 18:24:54 jwb: but also the consequences of being late, missing some parts (I know fesco members are God-like and knows everything before the feature is approved ;-) but development brings changes... 18:24:56 mitr, no it doesn't. it means the feature page has to be clear on what the feature is intended to do, and the submitter has to be responsive to questions along the way 18:25:11 jreznik, then the feature owner needs to make people aware 18:25:17 jwb: to give a specific example, I can't see that it would have solved the fedup problem 18:25:26 mmaslano: perhaps an either/or. either you relaibly update clear correct status on your own, or you have to show up to the meeting to answer for it anyway. carrot/stick? 18:26:00 notting, +1 18:26:11 or anyone who doesn't update gets a mentor assigned to try and get that status..? 18:26:13 notting: how would we determine "clear correct status" 18:26:22 jwb: yes, that's the problem - if it's not communicated well, people are not aware - part we try to solve 18:26:23 perhaps i am too jaded by people/projects that cannot report progress *unless* they are dragged into a meeting room. but that's a different issue. 18:26:58 mitr: i think dropping the percentages entirely might be best, and requiring detailed scope and status on each item therein 18:27:04 nirik: or fesco can ask me as wrangler to nag for updates for certain features... 18:27:18 yeah, the % is anoying... 18:27:33 percentage is a poor measure, and we should do away with it. 18:27:36 notting, that would mean so big administrative overhead that people will avoid the feature process as they can 18:27:42 % doesn't indicate anything other than "in progress" - doesn't say anything about blocked, in danger, etc. 18:27:44 for example: https://fedoraproject.org/wiki/Anaconda/Work_List is far better than any percentage 18:27:46 t8m: they already do 18:27:53 perhaps it should be a set of steps? 'planning' 'implementing' 'testable' 'on_qa' 'done' or something. 18:27:54 pjones, and they will even more 18:28:14 I'm definitely for dropping the percentage, but making it even more detailed is no-go 18:28:16 sounds like we all agree % as status is dumb and needs to be replaced. perhaps with a bulleted list of subitems to be completed during development or something 18:28:20 adding mentors and such isn't likely to make the process less heavy and more inviting. 18:28:27 jwb: +1 18:28:42 jwb: which you basically have to do already anyway... 18:28:52 pjones, you don't have to, but it sure is nice. 18:28:57 jwb, which for many features will be a single point bulleted list 18:29:00 so... let's make them have to 18:29:16 t8m: if it's a non-complex feature (or whatever we're calling the first category), that should be ok 18:29:17 t8m, then either they're extremely simple, or we ask them to not be dumb 18:29:24 nirik: Many features don't really have the waterfall model (parts can be dropped out of scope any time) - and I don't think FESCo _needs_ this kind of information. We're more concerned about the impact on the rest of distribution, timing, infrastructure, collisions... 18:29:46 percentage is - how far we think we are, we need - how far are we from the goal? 18:29:52 mitr: sure. I guess really what we want is: "On track" "warning" "danger" ? 18:30:01 jreznik, percentage is meaningless 18:30:07 jreznik: right. except it's also the sum of a bunch of non-numerical things. 18:30:15 nirik, +1 18:30:21 What's the difference between 50% and 99%? 18:30:44 nirik: If you really want an enum, "nobody else needs to care", "are these two talking?", "release danger, find volunteers to help the feature" 18:30:45 jreznik, i can have 100% of the code written and be either 50%, 75%, or 99% complete because i'm waiting on legal 18:30:51 meaningless 18:30:58 99% of a big project may be farther away from complete than 50% of small feature. 18:31:23 jwb: yep - so the status is what's blocking the feature complete - during the cycle I tried to get this comment from late features as just bumping 10% is meaningless 18:31:39 ok, so what can we actually get done in this meeting. ;) I think we are drifting into the %age weeds without a clear proposal to vote on. 18:31:39 so remove the percentage entirely 18:31:55 20 minutes on the topic 18:31:57 and 100% means "code is done" to some people, and 100% means "i tested and made sure there was documentation too" for other people. 18:32:00 jwb: use enums or just status as green, orange and red? 18:32:02 can we all agree to the 'less complex features' part of the proposal? 18:32:03 nirik, i doubt much. honestly, this is a high-bandwidth kind of topic 18:32:08 nirik: I think we're sufficiently split on this that voting on a proposal isn't going to be useful 18:32:09 jwb: agreed. 18:32:19 nirik: We don't want to accept something just because of a 5/4 split at this point 18:32:28 jreznik, i think i already suggested a bulleted list of items that need to be complete 18:32:38 jwb: I'm ok with that 18:32:43 mjg59: sure, but I think there's parts of the current proposal we could all agree on? or no? 18:32:45 +color status 18:32:54 ok, mini-proposal from big proposal: all features are announced on devel-announce by wrangler once verified 18:33:02 That sounds good 18:33:04 +1 to nttoing 18:33:05 +1 18:33:06 +1 18:33:07 notting, +1 18:33:08 +1 18:33:10 more communication is good. 18:33:16 jreznik, i know PMs like red/yellow/green and percentages because they're easier to codify and chart-ify, but they just don't work here 18:34:12 notting: +1 18:34:22 notting +1 18:34:31 +1 18:34:33 To extend this a little, "... and FESCo votes on them no sooner than a week after the announcement". OK? 18:34:34 what about proposal: Leaf features (self decided by feature proposal) are implicitly approved unless anybody (including f.e. feature wrangler) escalates them to being 'regular features'. 18:34:51 #agreed Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0) 18:35:03 t8m, i'm -1 on that 18:35:09 t8m: I'd like to work on that a little more - we sort of suggest a lighter-weight feature page, but don't really have a list of what "lighter-weight" means. 18:35:10 (as a side note to this, I wonder if it shouldn't be 'feature owner announces to devel-announce' as then they are set to get replies about their feature and be involved in any discussion) 18:35:14 t8m: so defer? 18:35:18 jwb, why? do you like fesco voting 18:35:30 mitr, no problem 18:35:33 t8m, not because it doesn't help with reducing fesco's time, but because i don't think all leaf features are ACTUALLY FEATURES 18:35:46 jwb, that's orthogonal 18:35:49 jwb: they typically are in the "marketing list" sense 18:35:56 t8m: I'd rather just stop defining them that way than add more process around them 18:36:04 t8m, no it isn't 18:36:32 * jreznik will take an action of preparing template for feature announcements and process (to announce once feature ready for fesco etc.) 18:36:57 t8m, or even if it's orthongonal, it just introduces a new problem worse than the one it solves 18:37:11 jwb, and that problem is? 18:37:13 without a clearer definition, the feature list grows ridiculously 18:37:19 fesco limits it defacto today 18:37:22 and we suck at it already 18:37:26 jwb, and that is a problem? 18:37:35 clearly i think so 18:37:43 yes, that's a major problem. 18:37:48 why? 18:38:18 give a journalist a list of 10 features and they can write an article about the next release highlights. give them a list of 30-50 and they'll just pick whatever they think is important anyway 18:38:29 what's wrong on saying I've this new cool package XY which is making Z better than anything else in Fedora? 18:38:30 because it removes all utility from the list while simultaneously adding to the amount of work we have to do that's simply overhead. 18:38:36 jwb: Our marketing is doing this by writing the feature announcements 18:38:38 jwb: we have Beasts for that 18:38:42 I'm fine with this proposal if we simultaneously change "Leaf features" to "Release notes" 18:38:45 sorry Beats or how it's called :) 18:38:51 jwb, that can be filtered by marketing 18:38:59 Let's stop calling them features 18:39:00 mjg59: it's not for release notes... 18:39:05 mjg59, no kidding, right? 18:39:09 bullshit 18:39:13 mjg59: "items of note"? 18:39:14 jreznik: of course it's for release notes. 18:39:34 pjones: not every leaf feature has to go release notes 18:39:41 so, the proposal is "fill out template -> announce -> if no one suggests it is escalated -> release notes"? 18:39:45 mjg59: It's the other way around. "features" is a good name for the marketing list, and "technical changes" or "projects" or something is what we are more concerned about 18:39:45 if a feature isn't going to be looked at by fesco, and it isn't going to be written about by marketing, but it's approved on the feature list, what is it? because it's not a feature. 18:39:51 jreznik: then we're right back to the fact that there's no point to having them. 18:40:00 notting, basically yes 18:40:24 mitr: Sure, I'm fine with changing "Feature process" to "Technical changes process" 18:40:25 jwb, it's formalized announcement of development work 18:40:36 mitr: Just so long as there's actually a split between these things 18:40:39 t8m, that gets announced where? 18:40:46 jwb, on fedora devel 18:40:46 jreznik: you can't have it both ways 18:40:49 notting: probably a step to "drop if the feature owner doesn't update status to 100% by beta time" 18:41:08 jwb, using the feature template helps reviewing whether it is really 'leaf feature' or full feature 18:41:16 jreznik: If a leaf feature isn't going to go in the release notes, what's the incentive for anyone to go through the process? 18:41:37 'leaf feature' just sounds like something that isn't a feature and needs a different damn name 18:41:54 'development project' or something 18:41:55 Aren't release notes primarily a technical document, rather than a source of marketing background info? 18:41:55 mjg59: visibility of changes? that's the main idead here... 18:42:09 mitr: yep 18:42:23 jreznik: If a feature is so uninteresting that we're not putting it in the release notes, and if it doesn't impact any other packages, why is it a feature? 18:42:26 it's processed later to something more consumable by marketing and media 18:42:29 mitr: Both, really, like a car's mpg rating. 18:42:41 so... we need another document? 18:42:54 notting, we have it. the devel-announce archives 18:43:03 yeah, that's enough 18:43:03 i propose we move on the the next agenda item 18:43:04 * nirik thinks we need to start over on features with a clear setup. ;) 18:43:37 Can I squeeze one more proposal in here? 18:43:44 is there anything else from the proposal that people would like to suggest? 18:43:46 mitr: go ahead 18:43:51 well - it's time for f19 features - accept them as it's now? take a part of the proposal? 18:43:54 Proposal: "FESCo votes on new features o sooner than a week after the devel-announce announcement". 18:44:04 "no sooner" 18:44:13 mitr, +1 18:44:17 +1 18:44:19 mitr: +1 18:44:37 mitr: i.e., to allow time for some discussion? seems reasonable. +1 18:44:44 notting: yep 18:44:45 sure, sounds fine. 18:44:50 we could say that is why in the text too, but +1 18:44:52 not sure we need the rule, but I don't see the problem with it easier. 18:45:37 #agreed FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:7, -:0, 0:0) 18:45:53 +1, sorry 18:45:58 #undo 18:45:58 Removing item from minutes: 18:46:03 #agreed FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0) 18:46:04 Sudden phone call 18:46:31 one last bit: we had discussed "features must have a 'reasonable' contingency plan". is this worth a proposal, or? 18:46:45 Seems like a kneejerk reaction to me. 18:46:56 I suspect we may be more strict looking at that in f19... but I don't know of any concrete change to propose 18:47:09 notting, I think this can be left on individual feature decision when fesco approves 18:47:16 it 18:47:16 nirik: I can't imagine that we wouldn't. 18:47:34 notting: It's sort of a case of FESCo voting that FESCo will do something in the future.... I think we do need to pay more attention, but I'm not sure that means anything for the formal policy. 18:47:41 ok, sounds good 18:47:52 mitr: +1 18:48:07 so no proposal to lower the fesco burden on low-impact features? 18:48:34 (no acceptable proposal that is) 18:48:35 t8m: Defer a week, I'll try to make it a bit more specific 18:48:40 When a feature is "We will rewrite this significant part of the project", there's a significant possibility that the only contingency plans are "Revert large portions of the project, including features that this feature depends on" or "Slip the release" 18:48:40 mitr, OK 18:48:42 * jreznik will try to be more bad guy as wrangler for contingency plan part 18:49:02 jreznik: :) 18:49:02 So... which of those is reasonable? 18:49:08 #agreed mitr (and otherse) will continue to discuss specific improvements 18:49:13 mjg59: it is what happened with anaconda... 18:49:14 #undo 18:49:14 Removing item from minutes: 18:49:18 #agreed mitr (and others) will continue to discuss specific improvements 18:49:26 mjg59: yeah, sounds like a per-feature basis 18:49:43 mjg59: "you won't rewrite it without keeping the old version working; if you can't, feature is rejected" would be one more option. 18:49:43 jreznik: We're agreeing that that would be a reasonable contingency plan, then? 18:49:52 mitr: Yeah, good luck with that one. 18:49:52 jreznik: that's not at all what happened with anaconda. 18:50:02 moving on in the agenda (#940 was added after meeting annoucement, can discuss later) 18:50:18 pjones: not saying it's all... 18:50:22 mjg59, arguably "We will rewrite this significant part of the project" those features should be done in a separated branch and be done within one release cycle when ready 18:50:29 #topic 960 - F18 schedule + the holidays 18:50:30 jreznik: I'm saying you're completely miscategorizing what happened. 18:50:36 Viking-Ice: Thanks 18:50:37 .fesco 960 18:50:41 notting: #960 (F18 schedule + the holidays) – FESCo - https://fedorahosted.org/fesco/ticket/960 18:51:03 Ok so how did something we agreed on 4 weeks ago suddenly become a problem again 18:51:17 so, on this... I'd be ok with freezing next tuesday, but only if QA and anaconda folks were ok with it... 18:51:20 did we? we agreed that we can open it after beta 18:51:21 it was reopened by stakeholders who would like it discussed... 18:51:38 adamw, tflink: are you around? see nirik's question... 18:51:43 notting: Yes, and the failure of process appears to be that the stakeholders weren't aware of what we'd decided 18:52:06 notting: Is that because we didn't do enough to tell them, or is it because they weren't paying attention? 18:52:21 let's figure that out after we decided on the ticket 18:52:21 jreznik: yo 18:52:27 13:50:21 Viking-Ice │ mjg59, arguably "We will rewrite this significant part of 18:52:28 is dgilmore here? 18:52:29 mjg59: at least QA were on the meeting... Anaconda usually does not care if they are frozen or not when I talked to them 18:52:31 pointing fingers is fun, but it won't actually CLOSE THE TICKET 18:52:43 so far as freezing goes, i think the thing that most worries us is fedup, again 18:52:45 jreznik: Anaconda and QA aren't the people who reopened this ticket 18:52:55 (uh, sorry mouse error) 18:52:56 has anyone determined what state we want fedup to be in for final? 18:53:08 uh, functional? 18:53:09 are we expecting the GUI to be implemented? logging, progress indication? 18:53:31 dgilmore is traveling/on PTO right now I think. 18:53:34 adamw: I talked to wwoods - I got some replies - /me is going to report a ticket 18:53:57 adamw, I am fine f 18:54:05 so as with beta, fedup and SB are the two significant things for determining freeze date, i believe. 18:54:08 adamw: i'd say "no", "would be nice", and "would be nice", in that order 18:54:11 jreznik: sorry about not responding to your email yet - have been having too much fun with blockers the last couple of days 18:54:12 with no GUI if the commandline steps are just one command :D 18:54:21 * nirik is with notting on that. 18:54:28 * jreznik is preparing the todo's/requirements list for fedup, will file a ticket to fesco soon 18:54:39 t8m: it's one command... 18:54:51 if we're happy with being, erm, flexible about how polished fedup is, then it's probably not blocking freeze at this point, as it does appear to broadly work in beta. 18:54:55 I'd say would be nice for all three. 18:54:57 jreznik: seriously, we're going to write a requirements document *now*? 18:55:09 pjones: now sucks but is better than never... 18:55:11 adamw: Did for me. 18:55:15 adamw: doubtful. 18:55:36 i'm just sayng 'no' to GUI now because it seems better to bug fix w/o a GUI than try and bake something in 2 weeks 18:55:47 If there's going to be a requirement document then we can't freeze 18:55:54 pjones: as adamw said... before beta nobody knows what's fedup about, no we at least think we know what it is about... 18:55:59 Because we have no idea what those requirements are or whether the code meets them 18:56:24 mjg59: +1 18:56:49 there's skeletal gui core righ now, but really a gui, no functionality 18:57:01 notting, +1 18:57:15 IIRC, someone from design just started working on the GUI - not sure where that is at the moment, though 18:57:22 is not gui a must have before release these after breeding our user base on preugprade? ( the cli user base will stick to yum as always )+ 18:57:23 jreznik: So more of a gu, not so much i? 18:57:33 jreznik: So... just what? 18:58:07 I think progress indication is rather important to have - perhaps not a blocker, but having something happening from the same thread to ensure that it at least hasn't crashed would be good. We are asking an user to nervously sit in front of a screen for 10-30 minutes 18:58:07 Viking-Ice: the preupgrade "gui" wasn't much different than preupgrade-cli, IMHO. 18:58:15 #link https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet 18:58:48 if we need another week for requirements documentation and/or adding gui progress indicators, and dennis is sayign that another week is needed because of PTO (?)... 18:58:57 tflink: as I said - there's skeletal gui - it means glade you can click and that's all 18:59:09 nirik, I'm just saying why did we bother with fedup if we are going to release without it having GUI the cli users will continue to use yum as they have done all those years 18:59:16 much as i hate to slip based on vague blockeriness 18:59:27 i don't think i'm saying 'we need a requirements document' here. 18:59:34 Viking-Ice: there were many 'cli users' who use preupgrade. 18:59:37 adamw: So why is jreznik saying that? 18:59:39 rbergeron: that's more question what we are able to finish before Christmass 18:59:41 i'm just saying, i want fesco to have considered the question of what we want for fedup for the final release. 18:59:44 Could someone please explain what's actually going on? 18:59:58 if you have considered that question and you're all on the same page, and that page is okay with freezing for release, then fine. 19:00:02 mjg59: ha. ;) 19:00:27 and I'm trying to collect the requirements to avoid "ah, we thought gui was requirement as we talked about it months ago" 19:00:41 What I'm hearing right now is that someone's not enthusiastic about us freezing because they'd like fesco to consider a question, and someone else is fine with us freezing as long as fedup meets a requirement document that hasn't been written yet 19:00:46 adamw: okay, that's fine and we'll take it in to account, but right now I'm more concerned with what jreznik is doing and why 19:01:12 (Does this requirements document have a contingency plan?) 19:01:22 mjg59: we were asked if F18 final was ready for freeze. our answer was "that depends on what fesco is expecting from the final release" 19:01:26 pjones: fedup is feature - fesco should say what they require for the feature and what's blocking release 19:01:42 jreznik: that's not at all how any feature has ever worked. 19:01:43 the stuff about fedup is part of the "what is fesco looking for?" part 19:01:47 The questions are: do we want to freeze a week earlier to help avoid people working during holidays? The answer seems related to 'what state must fedup be in before we can freeze' 19:01:48 so, from that document, isn't 877623 just 998 all over again? 19:02:00 jreznik, i think you meant to imply fedup is a release requirement? 19:02:01 oh, god. 19:02:20 notting: yes. mark it duplicate. I intend on fixing it as an f19 feature. 19:02:25 notting: In case of fedup, we have a "trusted" base to build on 19:02:48 jwb: from previous discussion and tickets, I understand it was what fesco wanted to discuss - if not, well - I'm ok with that 19:02:50 no chicken-and-egg problems, at least in theory 19:03:04 mitr: yes, but it isn't something we did before, as i understand it 19:03:28 i'm with nottings "no gui, move on" 19:03:30 notting: right 19:03:40 jwb: +1 19:03:58 Proposal: allow deferment of fedup gui until F19 19:04:00 right. +1 to no gui... too many more moving parts right now. 19:04:04 pjones: +1 19:04:08 +1 19:04:11 * pjones is +1 to me 19:04:13 +1 19:04:28 pjones: +1 19:04:36 +1 19:05:12 +1 19:05:15 +1 19:05:45 okay, so that leaves the logging, progress indication, and signature verification questions, i believe. 19:05:53 tflink probably has better specific info on those than I do. 19:05:56 #agreed Allow deferment of fedup gui until F19 (+:8, -:0, 0:0) 19:06:12 logging is pretty much fixed AFAIK 19:06:26 tflink: great 19:06:49 jreznik: Again, just to clarify - what is the role of this requirements document that you're writing? 19:06:59 proposal: signature verification is a new requirement that will be targeted in f19 19:07:05 proposal: do not block on signature checking (as a non-regression) 19:07:10 +1 19:07:10 the major unkowns/issues left that I'm aware of are: progress indication during upgrade, boot entry modification before and after upgrade and post-upgrade cleanup 19:07:24 preupgrade did no signature verification? 19:07:31 mjg59: what you're voting on... 19:07:33 t8m: yep 19:07:41 ok +1 then 19:07:45 notting: +1 19:07:46 jreznik: Still not getting it 19:07:49 notting: +1 19:07:53 i like nottings better. +1 19:07:59 notting: +1 19:08:02 (to notting) 19:08:10 jreznik: We're voting on the requirements document, or the requirements document embodies what fesco decides? 19:08:13 tflink: wow. we're talking about final release and boot entries are problematic? 19:08:14 mjg59: it was an attempt to gather information that we're doing here outside a meeting 19:08:33 tflink: thanks 19:08:34 mitr: yep. fun times 19:08:46 tflink: That doesn't answer my question 19:08:47 #agreed Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0) 19:08:57 mjg59: then I don't understand your question 19:09:07 so boot entry modification & cleanup sound like bugs, that should be tasked via blocker bug criteria? 19:09:12 tflink: Who determines the contents of the requirements document? 19:09:31 mjg59: well, call it a todo list 19:09:33 tflink: as notting says, are they really 'design questions' or just run-of-the-mill blocker bugs? 19:09:35 notting: sounds right. 19:09:39 jreznik: No, that doesn't help 19:09:58 Who wrote this document, and what were they expecting it to be for? 19:10:05 I still have no idea what's going on 19:10:07 mjg59: I think that requirements document might have a been a bit of a misnomer this late - it was more of a "what is left that could potentially block release" kind of thing, describing where fedup needs to be in order to get final out the door 19:10:07 mjg59: _Having_ a document is necessary to be able to talk about the requirements. The voting that we just did would be impossible without a list of items to vote on. 19:10:09 tflink: bear in mind that we're kind of applying the 'all planned functionality must be present in code before freeze' thing from beta here, so the question isn't 'what's still broken in fedup' but 'are any major parts of fedup not written yet' 19:10:30 mitr: So it's not a requirements document, it's a list of things that someone might decide are requirements? 19:10:37 if these are just bugs in the current code, i'm with notting that we don't need to hold freeze for them. 19:10:37 mitr: and yet we did that voting with no such document. 19:10:58 adamw: I'm not sure it's wise to freeze under the assumption that some of this will be fixed quickly when we're not even sure what the problems are 100% yet 19:11:01 mjg59: i think the idea is that since fedup is a thing that fesco is allowing to land well well after feature freeze, fesco needs to decide the requirements 19:11:18 tflink: so file the damned bugs and mark them as potential blockers. 19:11:21 notting: Ok, but I still don't understand the process 19:11:23 pjones: because the content was said in the meeting - I just wanted to add more insights from feature owner 19:11:24 and handle them the way we'd expect to. 19:11:28 tflink: i just worry that we've never held freeze before on the basis of 'there's some blocker bugs we're worried about', and that might be a leap too far. 19:11:41 mjg59: "we haven't done this before, so we're kind of making this up"? 19:11:48 notting: Nope, still not getting it 19:12:17 pjones: trying to do that but I'm just voicing concern here since the quesiton (as I understand it) was: does QA think that moving freeze is OK? 19:12:17 because fedup had no feature, we are making up what needs to be in it's scope for final? 19:12:32 This really ought to be a very easy question to answer 19:12:35 adamw: ok, let's have a proposed blocker bug for the issues left, it should not affect freeze - just blocker bug 19:12:54 Who wrote this requirements document, and are the contents of it actually requirements? 19:13:23 mjg59: there is no document yet, we're kind of making stuff up as we go along while attempting to not go insane in the process 19:13:28 mjg59: jreznik wrote it as input (it appears), and we are iterating over (as FESCo) whether the contents are requirements? 19:13:33 tflink: Then why did jreznik say that he'd written a requirements document? 19:13:39 mjg59: for the record, i'm not aware there *is* a requirements document, and i have been operating entirely in the context of this meeting. you asked what QA thought about freezing, i tried to give an answer to that question, which was based around the concept of 'what major chunks of code that we might want for final might not have been written yet'. 19:13:41 mjg59: we are attempting to coordinate here between fedup maintainers and QA? 19:13:43 notting: Ok, so we're not treating it as a requirements document? 19:13:45 mjg59: There isn't a document, and we haven't needed/used it, so is it that important what it would have been? 19:13:46 mjg59: I don't think he did. he just got started on one 19:14:14 The point I'm trying to make is this: 19:14:18 so far as i can see, that topic has been discussed and decided fairly sensibly above. 19:14:24 mjg59: not written - I was just trying to summarize what's needed, what would fesco want to hear, what feature owner thinks it's doable by beta and what should be blocker... 19:14:25 People shouldn't be writing requirements documents unless they're in a position to decide what those requirements are 19:14:45 you really seem to have latched onto this concept of a requirements document with strange assiduity. 19:14:52 mjg59: perhaps it's mislabeled. "proposed potential requirements"? 19:15:07 mjg59: so are you volunteering to write it? 19:15:08 right, so from the perspective of fedup we are left with only bugs, no missing unwritten functionality? 19:15:12 notting, +1 :) 19:15:17 the one thing we didn't cover was progress 19:15:25 notting: yep, sorry for mislabeling it as todo/requirements... 19:15:36 i am willing to consider "a progress indicator of some sort" a blocker for f18 19:15:50 notting: and it's the bug currently I'd say 19:15:53 yeah at least some rough sort 19:16:20 is there a proposal we're voting on at the moment? i've sort of tuned out since we weren't being productive. 19:16:22 * nirik nods. +1 19:16:37 adamw: When someone presents something as a requirements document that contains a set of requirements that haven't been previously discussed, yes, I think it's time to ask questions about what is going on 19:16:45 so it should not affect freeze as far as I understand the discussion 19:17:09 notting: so, that part is written, but not working? or do we know? 19:17:23 nirik: afaik, doesn't exist? 19:17:26 adamw: Especially if nobody involved in it will then actually answer the question as to what this document actually is 19:17:29 * nirik looks again at bug 19:17:31 the progress indicator is written and working 19:17:37 the graphical one, I mean 19:17:46 mjg59: i don't see where anyone at any point actually presented a requirements document. 19:17:52 mjg59: sorry I mislabeled it and I was thinking about the right name I have to admit - just for the moment I called it this way - and of course it would end up by FESCo voting as happening now... so please, we are over it and get back to real work 19:17:55 there is/was a snag in building the upgrade.img to use that indicator 19:17:56 tflink: ... that doesn't help, givne earlier decision 19:18:23 if the code is basically done but there's a bug displaying it, i guess that's not a freeze-holding issue. 19:18:24 ok, great. 19:18:31 adamw: yep 19:18:36 it's just blocking bug 19:18:38 yeah, I don't think it's a freeze-holding issue 19:19:01 tflink: if the progress is GUI only, and we've decided a GUI is out of scope, it does not help 19:19:03 so I think we agreed on fedup not holding possible freeze 19:19:10 Ok 19:19:12 proposal: ping anaconda and fedup folks out of band, if they are ok with moving freeze a week earlier, do so. If not, keep it where we had it and give them another week of non freeze. 19:19:26 jreznik: as in "we will ignore fedup", or "we think we can continue with the current schedule and expect it to hold"? 19:19:39 okay, so aside from fedup, the other thing I see as potentially a problem is secure boot. 19:19:41 notting: let me rephrase - the progress indicator I am referring to is a plymouth splash with a graphical idication of progress and no visible log display 19:19:47 which again isn't a QA issue, but would appear to bear discussion. 19:19:54 adamw: which we appear to have agreed in ticket is a release blocker. 19:19:54 not at all related to the GUI for the fedup client 19:19:55 tflink: ah, ok. 19:20:34 pjones, if there is no realistic estimate that it will be done before the current freeze time there is no point in moving the freeze earlier 19:20:37 so we have any new secure boot status? 19:20:43 pjones: The ticket was title "released without signed ...", and people were voting "+1 blocker" - I'm not 100% sure what the outcome was 19:20:53 pjones: sorry, hadn't seen that - but 'release blocker' or 'freeze blocker'? is it OK to go into freeze with it unresolved, and hope it shows up in time? 19:21:13 adamw: https://fedorahosted.org/fesco/ticket/978 19:21:42 per the ticket we won't release without it. I suppose we could go into freeze without it tho... 19:21:54 that seems unwise to me 19:22:11 pjones has a signed Fedora bootloader 19:22:13 we have a test image now, which a fedora contributor independently had signed. we've got a verbal agreement from RH business development on fedora signing, and we should have it in writing today or tomorrow, they say. 19:22:15 mjg59: "Red Hat legal is no longer a blocker here" could you provide more info? does this mean it's not a problem anymore? what's the current state? 19:22:25 entering freeze with an unknown delay for SB (assuming that we're blocking release for MS-signed SB) 19:22:43 pjones: mjg59: as I understand it there's no plan to release with the independently-signed shim though, right? that's not a viable thing to go to release with. 19:22:44 jreznik: It means exactly what it says. Red hat legal is no longer a blocker here. pjones has a signed Fedora bootloader. 19:22:52 pjones: cool. Might be worth advertising the test image to get some more testing on it? 19:22:52 pjones: "verbal agreement from RH"? 19:22:57 adamw: I don't understand the quesiton 19:23:02 ok 19:23:03 jreznik: way to chop a noun in half. 19:23:27 mjg59: i may be misunderstanding, but what I got from talking to pjones about it is that we have a signed shim build, but it's not the one we actually want to release with. we don't want to build f18 final with that shim in it. 19:23:32 pjones, feel free to converse in czech 19:23:33 I'd like to put new (slightly more conforming to the rfc...) certificates on the signers and re-sign kernel/grub2 and rebuild shim with the newer certs, and then get that signed with the fedora key once business affairs gives us the okay. it's... less strictly required. 19:23:38 adamw: I don't see why we wouldn't 19:23:40 adamw: a MS-signed shim that was submitted to MS to sign by a non-RH fedora contributor 19:23:43 okay. 19:23:47 notting: yes, I know what it *is*. 19:23:56 adamw: The binary would be identical 19:24:23 pjones: happy to assist in the infra side of things to get that all working. 19:24:55 so, It sounds like the end of the tunnel is in sight for that stuff... 19:24:59 pjones: what's your take on the above? am I misunderstanding? 19:25:05 so could this signed shim be used for f18 final or not? that's probably current topic 19:25:06 nirik: okay. I'm going to make some new certs and test it locally after this meeting, hopefully I can get them to you this afternoon. 19:25:12 jreznik: Yes 19:25:13 ok. 19:25:19 adamw: I think I just said my take on it. 19:26:10 if i'm reading this right, mjg59 said 'yes', pjones said 'would prefer not to'? 19:26:10 so, I don't think SB is much of a blocker to going into freeze. 19:26:28 notting: there are "nice to have" bits here. doesn't make a whole great lot of difference. 19:27:18 what would be legal implications if we use this signed shim from the Fedora project pov? 19:27:20 nirik: well, in the context of "shim is not signed" is a blocker bug, and we can't compose a RC with an open blocker bug... 19:27:24 but there's a reasonable chance it would all be sorted by next tuesday? 19:27:29 notting: shim is signed 19:27:57 nirik: yes 19:28:22 so, any votes on my proposal, or counter proposals? 19:28:31 i missed your proposal 19:28:38 proposal: ping anaconda and fedup folks out of band, if they are ok with moving freeze a week earlier, do so. If not, keep it where we had it and give them another week of non freeze. 19:29:08 if we don't freeze earlier, are we agreeing to slip release to 1/15? 19:29:56 that was the request in the ticket 19:30:21 well, i'd be more comfortable if we were agreeing to a proposal that explicitly said so 19:30:33 jwb: +1 19:31:10 i mean, the discussion about the ticket turned into a discussion about blocker bugs and status and to freeze or not to freeze, and not actually about the ticket 19:31:16 jwb: So is that "release 1/15 and freeze at start of January" or only the first half? 19:31:38 that's my whole point. we didn't actually discuss why the ticket was opened and if we agree with what was stated in it 19:31:38 the request was: either freeze 12/11 for 1/8 release, or 12/18 for 1/15 release. 19:31:57 and the question is to pick one of those, or stick with 12/18 for 1/8 (/9, /10) releasee 19:32:00 * rbergeron peeks in for a board meeting but will hold a moment while y'al wrap up... 19:32:38 notting: And is that 1-month freeze really necessary, or just an artifact of the 12/18-1/3 span? 19:33:20 I'm hoping for a few people testing over the holidays, and ignoring the results would be a bit disappointing 19:33:24 right, so dgilmore's objection is that if we freeze on the 18th we have 3 days to get a release done, otherwise it means working during holiday week... which some people will be unwilling to do. 19:33:38 nirik: right 19:34:05 so, we would possibly run into things like a new blocker in component foo and no maintainer willing to work on fixing it, so we lose the week anyhow. 19:34:06 so as notting said - it's freeze week earlier and release jan 08 or move the release day 19:34:15 if people feel more comfortable with a 1/15 release off of a 12/18 freeze, i'm not against it 19:34:25 I'm not sure I agree that that will be the case, but I understand the viewpoint. 19:34:34 i just don't know that it is the *requirement* that is stated 19:35:59 also, note that we could release 01/09 or 01/10 I suppose. 19:36:18 nirik: yep, I added it there as we agreed on Wed and Thu 19:36:32 but is one day more ok? if we freeze earlier, it could be 19:36:59 i guess in order to Move Things Along: 19:37:01 new proposal: ping anaconda and fedup folks out of band, if they are ok with moving freeze a week earlier, do so and keep 01/08 release. If not, discuss release date next weeks meeting. :) 19:37:14 nirik: ping done - [20:35] then i guess my personal answer is: you could freeze right this second as far as i am concerned. 19:37:16 sparks: i may move into -1 momentarily 19:37:24 rbergeron: yep 19:37:31 rbergeron: sorry we are being slow... 19:37:40 i am not sorry 19:37:49 nirik: [20:36] freezing makes no difference to me. pretty sure everything I'm working on is a blocker. 19:37:52 ok then. 19:38:06 i asked clumens about freeze 19:38:19 and anaconda is working only on blocker bugs 19:38:20 proposal: move freeze up a week to 12/11 and keep release 01/08. 19:38:23 jwb: see my post above 19:38:23 he also mentioned the anaconda team is not asking for another week of non-freeze 19:38:29 jreznik, oh 19:38:30 heh 19:38:48 jreznik, well good that he gave us the same answer 19:38:55 * rbergeron notes that the board meeting is moving into #fedora-meeting-1 19:39:35 if we are discussing moving the freeze, that means we have to cover 940 this week 19:40:04 sure. 19:40:58 ok, so from fedup, anaconda pov we are clear - now 940 :) 19:41:09 well, no votes on the proposal? 19:41:14 has everyone moved on to lunch? 19:41:26 i'm still here 19:41:26 no, lunch was earlier. 19:41:40 at this point I think we've all just phased out. 19:41:50 i took the discussion to mean general dissent and discord. 19:42:08 in absence of a decision, we default to 12/18 freeze and 1/8 release 19:42:11 nirik: could you repropose as anaconda/fedup is ok with that 19:42:14 I have no problem with moving the freeze week earlier 19:42:18 proposal: move freeze up a week to 12/11 and keep release 01/08. 19:42:26 jreznik: like that ^ 19:42:28 nirik: +1 19:42:29 nirik, +1 19:42:32 nirik: thx 19:42:33 +1 19:42:34 nirik: +1 19:42:38 +1 19:42:47 * nirik just hit up arrow. Thats the same thing I just typed a few minutes ago 19:43:01 -1. i don't like the idea of compressing the fix time for beta feedback. 19:43:02 +1 19:43:07 * t8m hopes that he won't regret this after weeks of waiting for legal approval of signed SB 19:43:12 +1 19:43:31 t8m: We no longer need RH legal approval 19:43:33 notting, fwiw, such feedback can also be blocker bugs 19:43:35 t8m: hey, wait now. we aren't asking you to move freeze. 19:43:40 notting: as we are releasing after christmass - there should be probably some time... 19:44:08 jreznik: only if they are blockers... otherwise they are 0 days. 19:44:39 i predict a massive amount of 0 day updates regardless of when we release 19:44:46 yes, there always are. 19:44:55 like, a 3.7 kernel rebase 19:45:15 so we are ok with moving the 'final change deadline' *up*? 19:45:16 * limburgher has to go in 2 minutes. 19:45:17 nirik: that's why we have blocker bug process... 19:45:34 notting, apparently, yes 19:45:44 yes, seems so 19:46:04 i think this will go over poorly. but ok... 19:46:13 notting: You're right 19:46:23 nirik: changing vote to -1 , if that matters 19:46:27 notting, for once i hope you're wrong :) 19:46:51 Having two weekends for testers would be fine, freezing 2 days after the second one is too early to fix anything 19:46:56 notting: what the release really depends on are blocker bugs so... 19:47:00 * cwickert wants to point out that the board meeting was moved to #fedora-meeting-1 19:47:15 mitr: ? 19:47:16 ok, then reverting to -1 as well 19:47:48 jreznik: Nov 27 release, 2nd weekend is Dec 8-9, proposal is to freeze on dec 11 19:47:54 I think the beta "go" decision was a pretty clear indicator that QA don't anticipate anybody testing anything here. 19:47:58 * jreznik does not see relevance between beta testers and freeze... 19:48:16 jreznik: final change deadline we've given to packagers/developers 19:48:36 jreznik: and telling them they as of today now have 6 days instead of 13 19:48:37 pjones: eh? can't unpack that sentence. 19:48:44 adamw: I think we blew it. 19:48:46 notting: for testing - there's blocker bug process... for developers - do we want more development on nearly final? 19:48:54 given how wacked out this release has been I don't think anyone will be surprised by any change at this point. 19:49:06 adamw: If we don't care that things aren't testable in the beta, then we don't care if it gets tested. 19:49:09 adamw: he's refering to secure boot 19:49:12 pjones: oh. 19:49:12 notting: on the other hand, I don't disagree... 19:49:25 in any case, we're at +6 -3 at this point. if people are ok with that, we can move on? 19:49:34 please 19:49:43 sure 19:50:11 #agreed (960) Final change deadline moved from 12/18 to 12/11. Release date remains 01/08. (+:6, -:3 0:0) 19:50:15 jreznik: you will announce? 19:50:19 notting: yes 19:50:47 ok 19:51:03 #topic 940 - The /tmp-on-tmpfs feature should be disabled by default 19:51:05 .fesco 940 19:51:08 notting: #940 (The tmp-on-tmpfs feature should be disabled by default) – FESCo - https://fedorahosted.org/fesco/ticket/940 19:51:26 I think we shouldn't discuss this. 19:51:36 It was tacked on at the last minute with no additional details. 19:51:52 imho close it if no-one changed opinion 19:51:54 the relevant parties can't really be expected to be here, and in any case I suspect we know what they'll say. 19:52:24 the ticket had been sitting in the queue with "postponed until future [post-beta] meeting when fedora is more tested" 19:52:35 I could get behind just closing it. 19:52:36 this is the last such meeting, per the prior discussion 19:52:46 FWIW, I don't find bug 858265 usefull. 873831 is a case where ther emight be an issue... but it's not enough info 19:52:55 Did anybody change their opinion? 19:53:12 nirik: 873831 looks like a trivial anaconda patch 19:53:22 could well be. 19:53:23 pyanaconda/packaging/yumpayload.py:_yum_cache_dir = "/tmp/yum.cache" 19:53:34 AFAIK there are at least 3 votes (mitr, me, mmaslano) for revert. 19:53:41 anybody else would like to revert? 19:53:46 also, those bugs aren't on the tmfs tracker... 19:53:53 t8m: this is awful, processwise. 19:54:06 if nobody has brought it up /because/ they changed their mind, there's no reason to hold a new vote. 19:54:09 pjones, I can live with that 19:54:11 it has failed a vote several times. 19:54:18 Making 873831 a blocker seems reasonable 19:54:32 so close it 19:54:34 it was rejected based on the info at the time... but sure it could be revisited. 19:54:45 the last time, we postponed a vote until after beta 19:54:59 so it's probably worth just having a vote and being done with it 19:55:05 notting, +1 19:55:31 I promise I won't propose the revert again if we vote today to reject the revert. :D 19:55:40 proposal: Fedora 18 defaults to /tmp on tmpfs. 19:55:54 +1 19:55:56 notting, that's wrong proposal - that is the current situation 19:55:56 +1. Please file bugs and attach them to the tracker for concrete cases we need to fix. 19:56:02 -1 for the record 19:56:06 notting: +1 (though I still disagree with giving this another vote instead of just closing it based on the previous ones.) 19:56:06 t8m: whatever :) 19:56:13 but -1 anyway 19:56:23 -1 just for the record 19:56:47 Isn't there supposed to be a Board meeting taking place in here right now? 19:56:55 BobJensen: See -1 19:56:56 BobJensen, moved to fedora-meeting-1 19:56:56 BobJensen: it's in #fedora-meeting-1 19:56:57 BobJensen: It's in -1 at the moment. 19:58:20 * notting goes looking for limburgher's prior vote 19:58:37 +1 19:59:04 BobJensen: so many -1 votes on your question for tmpfs :) *joking* 19:59:36 18:04:35 mjg59: I've gone from +1 for default to +-0. really on the fence. 19:59:40 well, THAT helps. 19:59:52 that's 5:3 if we assume notting is for his proposal. 20:00:13 pjones: not necessarily. just stated it 20:00:27 notting: that's why I singled it out, yes. 20:00:42 Well, we're not going to reach 5 for reverting 20:01:15 right, so close it and move on? 20:01:34 that's why the proposal should be for revert to make it more clear but anyway it is clear enough now I think 20:01:48 i am leaning -1. do i think it actually breaks much? no. but it's also not benefiting enough to deal with the noise. 20:02:12 although reverting does make the systemd private /tmp support... messier. 20:02:26 ah, nm. they're in /var/tmp 20:02:33 and it's a hell of a thing to do right before freeze. 20:03:03 pjones, that's why you argued that the decision should be postponed after beta didn't you? :D 20:03:06 pjones, well, we did say we'd revisit it after beta 20:03:24 helpfully, we just moved freeze up after slipping beta by a lot 20:03:45 as it stands now, neither the affirmative to keep nor the affirmative to revert will pass. hooray? 20:04:18 affirmative to keep is not needed - keep is the default 20:04:32 I think so as well - anybody arguing otherwise? 20:04:34 (unless any of the -1-to-have-as-default are also -1-to-revert) 20:05:08 proposal: close the ticket because there is not and will not be enough votes before F18 final freeze to revert 20:05:13 t8m: shall i phrase it for the record in the inverse, then (proposal: revert /tmp-on-tmpfs as default) 20:05:27 notting, I don't care 20:06:37 #agreed #940 (The tmp-on-tmpfs feature should be disabled by default) does not pass. (+:4, -:4, 0:1) 20:06:38 t8m: no, I think it's wrong either way tbh 20:06:49 t8m: hence I'm still voting against reverting it 20:07:38 moving on 20:07:42 #topic Open Floor 20:07:48 chair? 20:07:52 #info Elections going on now - please vote. 20:07:55 whoops 20:07:57 i'll chair next week 20:08:00 keep topic current 20:08:09 #info Next week's chair is jwb 20:08:11 thx 20:08:14 anything else? 20:09:22 if not, will close meeting in two minutes 20:11:34 #endmeeting