18:07:27 <notting> #startmeeting FESCO (2012-12-05)
18:07:27 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:07:38 <notting> now with an actual correct date
18:07:50 <notting> #topic 896 - Refine Feature Process
18:07:53 <notting> .fesco 896
18:07:55 <zodbot> notting: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896
18:08:34 <notting> #meetingname fesco
18:08:34 <zodbot> The meeting name has been set to 'fesco'
18:08:37 <notting> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
18:08:37 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
18:08:48 <notting> ok, apologies. back to the feature process
18:09:27 <t8m> 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 <pjones> nirik: I really think we should
18:10:40 <t8m> nirik, that basically means postponing the changes to F20 features??
18:10:44 <nirik> 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 <t8m> nirik, I think we should do at least some changes now
18:11:13 <nirik> I suppose. Do we have any f19 features ready yet?
18:11:16 <mmaslano> nirik: nice, but only jreznik from group which proposed the feature process will be there
18:11:36 <t8m> mmaslano, +1
18:11:38 <rbergeron> 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 <nirik> we can/should have irc at least to help others provide input
18:11:43 <rbergeron> just ask.
18:11:55 <jreznik> 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 <notting> 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 <jreznik> the idea was - propose "smaller" changes to current process as F19 is behind the doors
18:13:49 <nirik> so, what do folks not like about the proposal? perhaps we could remove those parts and just accept the rest?
18:14:02 <t8m> jreznik, +1
18:14:05 <mmaslano> I think so
18:14:34 <notting> or take the parts piecemeal?
18:14:35 <jreznik> nirik: the most? it's not solving every problem in the universe
18:14:54 <jreznik> otherwise I did not see any strong objections... but maybe I'm just blind :)
18:14:59 <t8m> jreznik, heh :)
18:15:10 <t8m> jreznik, I did not see any strong objections either
18:15:10 <jreznik> if you consider it as "small first step"
18:15:13 <nirik> well, there were some questions/discussion about the assigning a fesco member to each feature.
18:15:24 <jwb> 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 <jreznik> nirik: ok, that part
18:15:35 <mmaslano> 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 <mmaslano> nirik: so, I assume fesco member interested in the feature should help feature owner, on the meeting would someone volunteer
18:16:20 <jreznik> 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 <mjg59> What if there's no fesco member interested in the feature?
18:16:29 <pjones> yeah, I still don't like the "complex features" plan at all tbh
18:16:35 <limburgher> mmaslano: nods
18:16:49 <limburgher> mjg59:  round-robin?
18:16:52 <jreznik> pjones: objections?
18:16:55 <t8m> pjones, can you be more specific?
18:16:58 <mjg59> limburgher: That sounds pretty awful
18:17:13 <pjones> jreznik: t8m: we had a whole conversation about what's not good about it last week.
18:17:20 <limburgher> mkg59: Agreed.
18:17:24 <mjg59> limburgher: For instance, the degree to which I'm going to be useful in shepherding a ghc transition is minimal
18:17:24 <nirik> 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 <t8m> pjones, I read the log but did not find anything serious
18:17:55 <mjg59> 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 <jreznik> 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 <mjg59> fesco shouldn't need to be involved in the vast majority of cases
18:18:20 <nirik> 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 <pjones> 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 <mmaslano> mjg59: the sheperd is there also for tracking process and know the real status
18:19:05 <pjones> So if fesco is doing it, I'd like to see the feature wrangler's role addressed at the very least.
18:19:07 <jreznik> 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 <mmaslano> some features will be easy to "shepperd" some won't
18:19:13 <notting> 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 <mjg59> mmaslano: Which shouldn't be necessary!
18:19:31 <nirik> 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 <t8m> nirik, I don't see any nagging in the proposal
18:19:56 <pjones> 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 <mitr> 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 <mjg59> 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 <jreznik> pjones: I'd be ok with that - for that "sheppherd sometimes"
18:20:35 <rbergeron> nirik: or worse - be a blocker in their progress...
18:20:38 <mjg59> mitr: Especially given that the desire is for there to be less fesco involvement in most features
18:20:43 <nirik> 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 <pjones> it seems like a step in exactly the wrong direction.
18:21:18 <mitr> mjg59: What is the alternative?  individually impose extra management requirements on projects that have had a bad history?
18:21:22 <notting> an alternative idea would just be to rope the feature owners for complex feature into directly reporting to fesco.
18:21:24 <nirik> 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 <rbergeron> 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 <mjg59> mitr: That'd be one option
18:21:36 <jwb> frankly, i see the shepard role as a human nag for filling out the 'status' section on the feature pages
18:22:08 <jreznik> 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 <pjones> 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 <jreznik> jwb: it should be more - not only pinging (I do it, I can do it) for status but understand the feature
18:22:41 <limburgher> pjones:  No, but i think that should be the preference.
18:22:50 <limburgher> jreznik:  Yes.
18:22:50 <mitr> 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 <mmaslano> 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 <notting> 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 <jreznik> notting: ok
18:23:16 <mitr> 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 <mmaslano> notting: I do not think more people will be willing to create visible feature if they have to attend (another) meeting
18:23:53 <jreznik> and yeah, it could be limited to only a few high touch features
18:23:56 <mmaslano> mitr: exactly
18:23:57 <jwb> jreznik, fesco should understand the feature _before_ it's approved
18:24:06 <jwb> jreznik, not as an evolution of nagging about it
18:24:14 <notting> (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 <pjones> mmaslano: the answer to alleviating the constant useless ping is not to make it more constant
18:24:25 <mitr> jwb: That eseentially means the feature has to be feature-complete at the time of proposal
18:24:53 <nirik> mitr: or at least testable.
18:24:54 <jreznik> 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 <jwb> 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 <jwb> jreznik, then the feature owner needs to make people aware
18:25:17 <mitr> jwb: to give a specific example, I can't see that it would have solved the fedup problem
18:25:26 <notting> 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 <t8m> notting, +1
18:26:11 <nirik> or anyone who doesn't update gets a mentor assigned to try and get that status..?
18:26:13 <mitr> notting: how would we determine "clear correct status"
18:26:22 <jreznik> jwb: yes, that's the problem - if it's not communicated well, people are not aware - part we try to solve
18:26:23 <notting> 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 <notting> mitr: i think dropping the percentages entirely might be best, and requiring detailed scope and status on each item therein
18:27:04 <jreznik> nirik: or fesco can ask me as wrangler to nag for updates for certain features...
18:27:18 <nirik> yeah, the % is anoying...
18:27:33 <pjones> percentage is a poor measure, and we should do away with it.
18:27:36 <t8m> notting, that would mean so big administrative overhead that people will avoid the feature process as they can
18:27:42 <rbergeron> % doesn't indicate anything other than "in progress" - doesn't say anything about blocked, in danger, etc.
18:27:44 <notting> for example: https://fedoraproject.org/wiki/Anaconda/Work_List is far better than any percentage
18:27:46 <pjones> t8m: they already do
18:27:53 <nirik> perhaps it should be a set of steps? 'planning' 'implementing' 'testable' 'on_qa' 'done' or something.
18:27:54 <t8m> pjones, and they will even more
18:28:14 <t8m> I'm definitely for dropping the percentage, but making it even more detailed is no-go
18:28:16 <jwb> 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 <nirik> adding mentors and such isn't likely to make the process less heavy and more inviting.
18:28:27 <nirik> jwb: +1
18:28:42 <pjones> jwb: which you basically have to do already anyway...
18:28:52 <jwb> pjones, you don't have to, but it sure is nice.
18:28:57 <t8m> jwb, which for many features will be a single point bulleted list
18:29:00 <jwb> so... let's make them have to
18:29:16 <notting> t8m: if it's a non-complex feature (or whatever we're calling the first category), that should be ok
18:29:17 <jwb> t8m, then either they're extremely simple, or we ask them to not be dumb
18:29:24 <mitr> 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 <jreznik> percentage is - how far we think we are, we need - how far are we from the goal?
18:29:52 <nirik> mitr: sure. I guess really what we want is: "On track" "warning" "danger" ?
18:30:01 <jwb> jreznik, percentage is meaningless
18:30:07 <pjones> jreznik: right.  except it's also the sum of a bunch of non-numerical things.
18:30:15 <t8m> nirik, +1
18:30:21 <mjg59> What's the difference between 50% and 99%?
18:30:44 <mitr> 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 <jwb> 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 <jwb> meaningless
18:30:58 <mattdm> 99% of a big project may be farther away from complete than 50% of small feature.
18:31:23 <jreznik> 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 <nirik> 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 <jwb> so remove the percentage entirely
18:31:55 <mmaslano> 20 minutes on the topic
18:31:57 <rbergeron> 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 <jreznik> jwb: use enums or just status as green, orange and red?
18:32:02 <nirik> can we all agree to the 'less complex features' part of the proposal?
18:32:03 <jwb> nirik, i doubt much.  honestly, this is a high-bandwidth kind of topic
18:32:08 <mjg59> nirik: I think we're sufficiently split on this that voting on a proposal isn't going to be useful
18:32:09 <nirik> jwb: agreed.
18:32:19 <mjg59> nirik: We don't want to accept something just because of a 5/4 split at this point
18:32:28 <jwb> jreznik, i think i already suggested a bulleted list of items that need to be complete
18:32:38 <jreznik> jwb: I'm ok with that
18:32:43 <nirik> mjg59: sure, but I think there's parts of the current proposal we could all agree on? or no?
18:32:45 <jreznik> +color status
18:32:54 <notting> ok, mini-proposal from big proposal: all features are announced on devel-announce by wrangler once verified
18:33:02 <mjg59> That sounds good
18:33:04 <mmaslano> +1 to nttoing
18:33:05 <nirik> +1
18:33:06 <mitr> +1
18:33:07 <t8m> notting, +1
18:33:08 <mjg59> +1
18:33:10 <nirik> more communication is good.
18:33:16 <jwb> 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 <pjones> notting: +1
18:34:22 <jwb> notting +1
18:34:31 <limburgher> +1
18:34:33 <mitr> To extend this a little, "... and FESCo votes on them no sooner than a week after the announcement".  OK?
18:34:34 <t8m> 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 <notting> #agreed Feature process modification: features are announced on devel-announce by feature wrangler once wrangler verifies feature page content (+:9, -:0)
18:35:03 <jwb> t8m, i'm -1 on that
18:35:09 <mitr> 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 <nirik> (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 <mitr> t8m: so defer?
18:35:18 <t8m> jwb, why? do you like fesco voting
18:35:30 <t8m> mitr, no problem
18:35:33 <jwb> 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 <t8m> jwb, that's orthogonal
18:35:49 <mitr> jwb: they typically are in the "marketing list" sense
18:35:56 <pjones> t8m: I'd rather just stop defining them that way than add more process around them
18:36:04 <jwb> 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 <jwb> t8m, or even if it's orthongonal, it just introduces a new problem worse than the one it solves
18:37:11 <t8m> jwb, and that problem is?
18:37:13 <jwb> without a clearer definition, the feature list grows ridiculously
18:37:19 <jwb> fesco limits it defacto today
18:37:22 <jwb> and we suck at it already
18:37:26 <t8m> jwb, and that is a problem?
18:37:35 <jwb> clearly i think so
18:37:43 <pjones> yes, that's a major problem.
18:37:48 <t8m> why?
18:38:18 <jwb> 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 <mmaslano> 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 <pjones> 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 <mitr> jwb: Our marketing is doing this by writing the feature announcements
18:38:38 <jreznik> jwb: we have Beasts for that
18:38:42 <mjg59> I'm fine with this proposal if we simultaneously change "Leaf features" to "Release notes"
18:38:45 <jreznik> sorry Beats or how it's called :)
18:38:51 <t8m> jwb, that can be filtered by marketing
18:38:59 <mjg59> Let's stop calling them features
18:39:00 <jreznik> mjg59: it's not for release notes...
18:39:05 <jwb> mjg59, no kidding, right?
18:39:09 <jwb> bullshit
18:39:13 <notting> mjg59: "items of note"?
18:39:14 <pjones> jreznik: of course it's for release notes.
18:39:34 <jreznik> pjones: not every leaf feature has to go release notes
18:39:41 <notting> so, the proposal is "fill out template -> announce -> if no one suggests it is escalated -> release notes"?
18:39:45 <mitr> 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 <jwb> 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 <pjones> jreznik: then we're right back to the fact that there's no point to having them.
18:40:00 <t8m> notting, basically yes
18:40:24 <mjg59> mitr: Sure, I'm fine with changing "Feature process" to "Technical changes process"
18:40:25 <t8m> jwb, it's formalized announcement of development work
18:40:36 <mjg59> mitr: Just so long as there's actually a split between these things
18:40:39 <jwb> t8m, that gets announced where?
18:40:46 <t8m> jwb, on fedora devel
18:40:46 <pjones> jreznik: you can't have it both ways
18:40:49 <mitr> notting: probably a step to "drop if the feature owner doesn't update status to 100% by beta time"
18:41:08 <t8m> jwb, using the feature template helps reviewing whether it is really 'leaf feature' or full feature
18:41:16 <mjg59> 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 <jwb> 'leaf feature' just sounds like something that isn't a feature and needs a different damn name
18:41:54 <jwb> 'development project' or something
18:41:55 <mitr> Aren't release notes primarily a technical document, rather than a source of marketing background info?
18:41:55 <jreznik> mjg59: visibility of changes? that's the main idead here...
18:42:09 <jreznik> mitr: yep
18:42:23 <mjg59> 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 <jreznik> it's processed later to something more consumable by marketing and media
18:42:29 <limburgher> mitr:  Both, really, like a car's mpg rating.
18:42:41 <notting> so... we need another document?
18:42:54 <jwb> notting, we have it.  the devel-announce archives
18:43:03 <mmaslano> yeah, that's enough
18:43:03 <jwb> 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 <mitr> Can I squeeze one more proposal in here?
18:43:44 <notting> is there anything else from the proposal that people would like to suggest?
18:43:46 <notting> mitr: go ahead
18:43:51 <jreznik> well - it's time for f19 features - accept them as it's now? take a part of the proposal?
18:43:54 <mitr> Proposal:  "FESCo votes on new features o sooner than a week after the devel-announce announcement".
18:44:04 <mitr> "no sooner"
18:44:13 <t8m> mitr, +1
18:44:17 <mmaslano> +1
18:44:19 <limburgher> mitr: +1
18:44:37 <notting> mitr: i.e., to allow time for some discussion? seems reasonable. +1
18:44:44 <jreznik> notting: yep
18:44:45 <nirik> sure, sounds fine.
18:44:50 <jwb> we could say that is why in the text too, but +1
18:44:52 <pjones> not sure we need the rule, but I don't see the problem with it easier.
18:45:37 <notting> #agreed FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:7, -:0, 0:0)
18:45:53 <mjg59> +1, sorry
18:45:58 <notting> #undo
18:45:58 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x1a586d90>
18:46:03 <notting> #agreed FESCo votes on new features no sooner than a week after the devel-announce announcement. (+:8, -:0, 0:0)
18:46:04 <mjg59> Sudden phone call
18:46:31 <notting> one last bit: we had discussed "features must have a 'reasonable' contingency plan". is this worth a proposal, or?
18:46:45 <pjones> Seems like a kneejerk reaction to me.
18:46:56 <nirik> 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 <t8m> notting, I think this can be left on individual feature decision when fesco approves
18:47:16 <t8m> it
18:47:16 <limburgher> nirik:  I can't imagine that we wouldn't.
18:47:34 <mitr> 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 <notting> ok, sounds good
18:47:52 <jreznik> mitr: +1
18:48:07 <t8m> so no proposal to lower the fesco burden on low-impact features?
18:48:34 <t8m> (no acceptable proposal that is)
18:48:35 <mitr> t8m: Defer a week, I'll try to make it a bit more specific
18:48:40 <mjg59> 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 <t8m> mitr, OK
18:48:42 * jreznik will try to be more bad guy as wrangler for contingency plan part
18:49:02 <limburgher> jreznik: :)
18:49:02 <mjg59> So... which of those is reasonable?
18:49:08 <notting> #agreed mitr (and otherse) will continue to discuss specific improvements
18:49:13 <jreznik> mjg59: it is what happened with anaconda...
18:49:14 <notting> #undo
18:49:14 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x47a09bd0>
18:49:18 <notting> #agreed mitr (and others) will continue to discuss specific improvements
18:49:26 <notting> mjg59: yeah, sounds like a per-feature basis
18:49:43 <mitr> 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 <mjg59> jreznik: We're agreeing that that would be a reasonable contingency plan, then?
18:49:52 <mjg59> mitr: Yeah, good luck with that one.
18:49:52 <pjones> jreznik: that's not at all what happened with anaconda.
18:50:02 <notting> moving on in the agenda (#940 was added after meeting annoucement, can discuss later)
18:50:18 <jreznik> pjones: not saying it's all...
18:50:22 <Viking-Ice> 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 <notting> #topic 960 - F18 schedule + the holidays
18:50:30 <pjones> jreznik: I'm saying you're completely miscategorizing what happened.
18:50:36 <mjg59> Viking-Ice: Thanks
18:50:37 <notting> .fesco 960
18:50:41 <zodbot> notting: #960 (F18 schedule + the holidays) – FESCo - https://fedorahosted.org/fesco/ticket/960
18:51:03 <mjg59> Ok so how did something we agreed on 4 weeks ago suddenly become a problem again
18:51:17 <nirik> 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 <mmaslano> did we? we agreed that we can open it after beta
18:51:21 <notting> it was reopened by stakeholders who would like it discussed...
18:51:38 <jreznik> adamw, tflink: are you around? see nirik's question...
18:51:43 <mjg59> notting: Yes, and the failure of process appears to be that the stakeholders weren't aware of what we'd decided
18:52:06 <mjg59> notting: Is that because we didn't do enough to tell them, or is it because they weren't paying attention?
18:52:21 <jwb> let's figure that out after we decided on the ticket
18:52:21 <adamw> jreznik: yo
18:52:27 <mattdm> 13:50:21 Viking-Ice │ mjg59, arguably "We will rewrite this significant part of
18:52:28 <pjones> is dgilmore here?
18:52:29 <jreznik> 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 <jwb> pointing fingers is fun, but it won't actually CLOSE THE TICKET
18:52:43 <adamw> so far as freezing goes, i think the thing that most worries us is fedup, again
18:52:45 <mjg59> jreznik: Anaconda and QA aren't the people who reopened this ticket
18:52:55 <mattdm> (uh, sorry mouse error)
18:52:56 <adamw> has anyone determined what state we want fedup to be in for final?
18:53:08 <notting> uh, functional?
18:53:09 <adamw> are we expecting the GUI to be implemented? logging, progress indication?
18:53:31 <nirik> dgilmore is traveling/on PTO right now I think.
18:53:34 <jreznik> adamw: I talked to wwoods - I got some replies - /me is going to report a ticket
18:53:57 <t8m> adamw, I am fine f
18:54:05 <adamw> so as with beta, fedup and SB are the two significant things for determining freeze date, i believe.
18:54:08 <notting> adamw: i'd say "no", "would be nice", and "would be nice", in that order
18:54:11 <tflink> 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 <t8m> 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 <jreznik> t8m: it's one command...
18:54:51 <adamw> 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 <limburgher> I'd say would be nice for all three.
18:54:57 <pjones> jreznik: seriously, we're going to write a requirements document *now*?
18:55:09 <adamw> pjones: now sucks but is better than never...
18:55:11 <limburgher> adamw:  Did for me.
18:55:15 <pjones> adamw: doubtful.
18:55:36 <notting> 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 <mjg59> If there's going to be a requirement document then we can't freeze
18:55:54 <jreznik> 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 <mjg59> Because we have no idea what those requirements are or whether the code meets them
18:56:24 <nirik> mjg59: +1
18:56:49 <jreznik> there's skeletal gui core righ now, but really a gui, no functionality
18:57:01 <t8m> notting, +1
18:57:15 <tflink> IIRC, someone from design just started working on the GUI - not sure where that is at the moment, though
18:57:22 <Viking-Ice> 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 <limburgher> jreznik:  So more of a gu, not so much i?
18:57:33 <mjg59> jreznik: So... just what?
18:58:07 <mitr> 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 <nirik> Viking-Ice: the preupgrade "gui" wasn't much different than preupgrade-cli, IMHO.
18:58:15 <jreznik> #link https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final - not updated yet
18:58:48 <rbergeron> 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 <jreznik> tflink: as I said - there's skeletal gui - it means glade you can click and that's all
18:59:09 <Viking-Ice> 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 <rbergeron> much as i hate to slip based on vague blockeriness
18:59:27 <adamw> i don't think i'm saying 'we need a requirements document' here.
18:59:34 <nirik> Viking-Ice: there were many 'cli users' who use preupgrade.
18:59:37 <mjg59> adamw: So why is jreznik saying that?
18:59:39 <jreznik> rbergeron: that's more question what we are able to finish before Christmass
18:59:41 <adamw> 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 <mjg59> Could someone please explain what's actually going on?
18:59:58 <adamw> 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 <nirik> mjg59: ha. ;)
19:00:27 <jreznik> 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 <mjg59> 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 <pjones> 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 <mjg59> (Does this requirements document have a contingency plan?)
19:01:22 <tflink> 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 <jreznik> pjones: fedup is feature - fesco should say what they require for the feature and what's blocking release
19:01:42 <pjones> jreznik: that's not at all how any feature has ever worked.
19:01:43 <tflink> the stuff about fedup is part of the "what is fesco looking for?" part
19:01:47 <nirik> 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 <notting> so, from that document, isn't 877623 just 998 all over again?
19:02:00 <jwb> jreznik, i think you meant to imply fedup is a release requirement?
19:02:01 <adamw> oh, god.
19:02:20 <pjones> notting: yes.  mark it duplicate.  I intend on fixing it as an f19 feature.
19:02:25 <mitr> notting: In case of fedup, we have a "trusted" base to build on
19:02:48 <jreznik> 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 <mitr> no chicken-and-egg problems, at least in theory
19:03:04 <notting> mitr: yes, but it isn't something we did before, as i understand it
19:03:28 <jwb> i'm with nottings "no gui, move on"
19:03:30 <mitr> notting: right
19:03:40 <limburgher> jwb: +1
19:03:58 <pjones> Proposal: allow deferment of fedup gui until F19
19:04:00 <nirik> right. +1 to no gui... too many more moving parts right now.
19:04:04 <notting> pjones: +1
19:04:08 <nirik> +1
19:04:11 * pjones is +1 to me
19:04:13 <mjg59> +1
19:04:28 <limburgher> pjones: +1
19:04:36 <jwb> +1
19:05:12 <t8m> +1
19:05:15 <mmaslano> +1
19:05:45 <adamw> okay, so that leaves the logging, progress indication, and signature verification questions, i believe.
19:05:53 <adamw> tflink probably has better specific info on those than I do.
19:05:56 <notting> #agreed Allow deferment of fedup gui until F19 (+:8, -:0, 0:0)
19:06:12 <tflink> logging is pretty much fixed AFAIK
19:06:26 <jreznik> tflink: great
19:06:49 <mjg59> jreznik: Again, just to clarify - what is the role of this requirements document that you're writing?
19:06:59 <jwb> proposal: signature verification is a new requirement that will be targeted in f19
19:07:05 <notting> proposal: do not block on signature checking (as a non-regression)
19:07:10 <mjg59> +1
19:07:10 <tflink> 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 <t8m> preupgrade did no signature verification?
19:07:31 <jreznik> mjg59: what you're voting on...
19:07:33 <jreznik> t8m: yep
19:07:41 <t8m> ok +1 then
19:07:45 <mitr> notting: +1
19:07:46 <mjg59> jreznik: Still not getting it
19:07:49 <pjones> notting: +1
19:07:53 <jwb> i like nottings better.  +1
19:07:59 <limburgher> notting: +1
19:08:02 <t8m> (to notting)
19:08:10 <mjg59> jreznik: We're voting on the requirements document, or the requirements document embodies what fesco decides?
19:08:13 <mitr> tflink: wow.  we're talking about final release and boot entries are problematic?
19:08:14 <tflink> mjg59: it was an attempt to gather information that we're doing here outside a meeting
19:08:33 <jreznik> tflink: thanks
19:08:34 <tflink> mitr: yep. fun times
19:08:46 <mjg59> tflink: That doesn't answer my question
19:08:47 <notting> #agreed Do not block on fedup signature checking (not a regression) (+:7, -:0, 0:0)
19:08:57 <tflink> mjg59: then I don't understand your question
19:09:07 <notting> so boot entry modification & cleanup sound like bugs, that should be tasked via blocker bug criteria?
19:09:12 <mjg59> tflink: Who determines the contents of the requirements document?
19:09:31 <jreznik> mjg59: well, call it a todo list
19:09:33 <adamw> tflink: as notting says, are they really 'design questions' or just run-of-the-mill blocker bugs?
19:09:35 <pjones> notting: sounds right.
19:09:39 <mjg59> jreznik: No, that doesn't help
19:09:58 <mjg59> Who wrote this document, and what were they expecting it to be for?
19:10:05 <mjg59> I still have no idea what's going on
19:10:07 <tflink> 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 <mitr> 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 <adamw> 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 <mjg59> mitr: So it's not a requirements document, it's a list of things that someone might decide are requirements?
19:10:37 <adamw> 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 <pjones> mitr: and yet we did that voting with no such document.
19:10:58 <tflink> 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 <notting> 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 <pjones> tflink: so file the damned bugs and mark them as potential blockers.
19:11:21 <mjg59> notting: Ok, but I still don't understand the process
19:11:23 <jreznik> pjones: because the content was said in the meeting - I just wanted to add more insights from feature owner
19:11:24 <pjones> and handle them the way we'd expect to.
19:11:28 <adamw> 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 <notting> mjg59: "we haven't done this before, so we're kind of making this up"?
19:11:48 <mjg59> notting: Nope, still not getting it
19:12:17 <tflink> 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 <nirik> because fedup had no feature, we are making up what needs to be in it's scope for final?
19:12:32 <mjg59> This really ought to be a very easy question to answer
19:12:35 <jreznik> adamw: ok, let's have a proposed blocker bug for the issues left, it should not affect freeze - just blocker bug
19:12:54 <mjg59> Who wrote this requirements document, and are the contents of it actually requirements?
19:13:23 <tflink> 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 <notting> mjg59: jreznik wrote it as input (it appears), and we are iterating over (as FESCo) whether the contents are requirements?
19:13:33 <mjg59> tflink: Then why did jreznik say that he'd written a requirements document?
19:13:39 <adamw> 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 <nirik> mjg59: we are attempting to coordinate here between fedup maintainers and QA?
19:13:43 <mjg59> notting: Ok, so we're not treating it as a requirements document?
19:13:45 <mitr> 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 <tflink> mjg59: I don't think he did. he just got started on one
19:14:14 <mjg59> The point I'm trying to make is this:
19:14:18 <adamw> so far as i can see, that topic has been discussed and decided fairly sensibly above.
19:14:24 <jreznik> 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 <mjg59> People shouldn't be writing requirements documents unless they're in a position to decide what those requirements are
19:14:45 <adamw> you really seem to have latched onto this concept of a requirements document with strange assiduity.
19:14:52 <notting> mjg59: perhaps it's mislabeled. "proposed potential requirements"?
19:15:07 <tflink> mjg59: so are you volunteering to write it?
19:15:08 <nirik> right, so from the perspective of fedup we are left with only bugs, no missing unwritten functionality?
19:15:12 <t8m> notting, +1 :)
19:15:17 <notting> the one thing we didn't cover was progress
19:15:25 <jreznik> notting: yep, sorry for mislabeling it as todo/requirements...
19:15:36 <notting> i am willing to consider "a progress indicator of some sort" a blocker for f18
19:15:50 <jreznik> notting: and it's the bug currently I'd say
19:15:53 <t8m> yeah at least some rough sort
19:16:20 <jwb> 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 <mjg59> 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 <jreznik> so it should not affect freeze as far as I understand the discussion
19:17:09 <nirik> notting: so, that part is written, but not working? or do we know?
19:17:23 <notting> nirik: afaik, doesn't exist?
19:17:26 <mjg59> 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 <tflink> the progress indicator is written and working
19:17:37 <tflink> the graphical one, I mean
19:17:46 <adamw> mjg59: i don't see where anyone at any point actually presented a requirements document.
19:17:52 <jreznik> 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 <tflink> there is/was a snag in building the upgrade.img to use that indicator
19:17:56 <notting> tflink: ... that doesn't help, givne earlier decision
19:18:23 <adamw> 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 <nirik> ok, great.
19:18:31 <jreznik> adamw: yep
19:18:36 <jreznik> it's just blocking bug
19:18:38 <tflink> yeah, I don't think it's a freeze-holding issue
19:19:01 <notting> tflink: if the progress is GUI only, and we've decided a GUI is out of scope, it does not help
19:19:03 <jreznik> so I think we agreed on fedup not holding possible freeze
19:19:10 <mjg59> Ok
19:19:12 <nirik> 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 <mitr> 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 <adamw> okay, so aside from fedup, the other thing I see as potentially a problem is secure boot.
19:19:41 <tflink> 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 <adamw> which again isn't a QA issue, but would appear to bear discussion.
19:19:54 <pjones> adamw: which we appear to have agreed in ticket is a release blocker.
19:19:54 <tflink> not at all related to the GUI for the fedup client
19:19:55 <notting> tflink: ah, ok.
19:20:34 <t8m> 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 <nirik> so we have any new secure boot status?
19:20:43 <mitr> 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 <adamw> 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 <mitr> adamw: https://fedorahosted.org/fesco/ticket/978
19:21:42 <nirik> per the ticket we won't release without it. I suppose we could go into freeze without it tho...
19:21:54 <tflink> that seems unwise to me
19:22:11 <mjg59> pjones has a signed Fedora bootloader
19:22:13 <pjones> 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 <jreznik> 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 <tflink> entering freeze with an unknown delay for SB (assuming that we're blocking release for MS-signed SB)
19:22:43 <adamw> 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 <mjg59> 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 <nirik> pjones: cool. Might be worth advertising the test image to get some more testing on it?
19:22:52 <jreznik> pjones: "verbal agreement from RH"?
19:22:57 <mjg59> adamw: I don't understand the quesiton
19:23:02 <jreznik> ok
19:23:03 <pjones> jreznik: way to chop a noun in half.
19:23:27 <adamw> 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 <jwb> pjones, feel free to converse in czech
19:23:33 <pjones> 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 <mjg59> adamw: I don't see why we wouldn't
19:23:40 <notting> adamw: a MS-signed shim that was submitted to MS to sign by a non-RH fedora contributor
19:23:43 <adamw> okay.
19:23:47 <adamw> notting: yes, I know what it *is*.
19:23:56 <mjg59> adamw: The binary would be identical
19:24:23 <nirik> pjones: happy to assist in the infra side of things to get that all working.
19:24:55 <nirik> so, It sounds like the end of the tunnel is in sight for that stuff...
19:24:59 <adamw> pjones: what's your take on the above? am I misunderstanding?
19:25:05 <jreznik> so could this signed shim be used for f18 final or not? that's probably current topic
19:25:06 <pjones> 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 <mjg59> jreznik: Yes
19:25:13 <nirik> ok.
19:25:19 <pjones> adamw: I think I just said my take on it.
19:26:10 <notting> if i'm reading this right, mjg59 said 'yes', pjones said 'would prefer not to'?
19:26:10 <nirik> so, I don't think SB is much of a blocker to going into freeze.
19:26:28 <pjones> notting: there are "nice to have" bits here.  doesn't make a whole great lot of difference.
19:27:18 <jreznik> what would be legal implications if we use this signed shim from the Fedora project pov?
19:27:20 <notting> 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 <nirik> but there's a reasonable chance it would all be sorted by next tuesday?
19:27:29 <mjg59> notting: shim is signed
19:27:57 <pjones> nirik: yes
19:28:22 <nirik> so, any votes on my proposal, or counter proposals?
19:28:31 <jwb> i missed your proposal
19:28:38 <nirik> 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 <jwb> if we don't freeze earlier, are we agreeing to slip release to 1/15?
19:29:56 <notting> that was the request in the ticket
19:30:21 <jwb> well, i'd be more comfortable if we were agreeing to a proposal that explicitly said so
19:30:33 <jreznik> jwb: +1
19:31:10 <jwb> 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 <mitr> jwb: So is that "release 1/15 and freeze at start of January" or only the first half?
19:31:38 <jwb> 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 <notting> the request was: either freeze 12/11 for 1/8 release, or 12/18 for 1/15 release.
19:31:57 <notting> 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 <mitr> notting: And is that 1-month freeze really necessary, or just an artifact of the 12/18-1/3 span?
19:33:20 <mitr> I'm hoping for a few people testing over the holidays, and ignoring the results would be a bit disappointing
19:33:24 <nirik> 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 <jreznik> nirik: right
19:34:05 <nirik> 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 <jreznik> so as notting said - it's freeze week earlier and release jan 08 or move the release day
19:34:15 <notting> if people feel more comfortable with a 1/15 release off of a 12/18 freeze, i'm not against it
19:34:25 <nirik> I'm not sure I agree that that will be the case, but I understand the viewpoint.
19:34:34 <notting> i just don't know that it is the *requirement* that is stated
19:35:59 <nirik> also, note that we could release 01/09 or 01/10 I suppose.
19:36:18 <jreznik> nirik: yep, I added it there as we agreed on Wed and Thu
19:36:32 <jreznik> but is one day more ok? if we freeze earlier, it could be
19:36:59 <notting> i guess in order to Move Things Along:
19:37:01 <nirik> 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 <jreznik> nirik: ping done - [20:35] <clumens> then i guess my personal answer is:  you could freeze right this second as far as i am concerned.
19:37:16 <rbergeron> sparks: i may move into -1 momentarily
19:37:24 <jreznik> rbergeron: yep
19:37:31 <nirik> rbergeron: sorry we are being slow...
19:37:40 <jwb> i am not sorry
19:37:49 <jreznik> nirik: [20:36] <wwoods> freezing makes no difference to me. pretty sure everything I'm working on is a blocker.
19:37:52 <nirik> ok then.
19:38:06 <jwb> i asked clumens about freeze
19:38:19 <jreznik> and anaconda is working only on blocker bugs
19:38:20 <nirik> proposal: move freeze up a week to 12/11 and keep release 01/08.
19:38:23 <jreznik> jwb: see my post above
19:38:23 <jwb> he also mentioned the anaconda team is not asking for another week of non-freeze
19:38:29 <jwb> jreznik, oh
19:38:30 <jwb> heh
19:38:48 <jwb> 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 <notting> if we are discussing moving the freeze, that means we have to cover 940 this week
19:40:04 <nirik> sure.
19:40:58 <jreznik> ok, so from fedup, anaconda pov we are clear - now 940 :)
19:41:09 <nirik> well, no votes on the proposal?
19:41:14 <nirik> has everyone moved on to lunch?
19:41:26 <jwb> i'm still here
19:41:26 <pjones> no, lunch was earlier.
19:41:40 <pjones> at this point I think we've all just phased out.
19:41:50 <limburgher> i took the discussion to mean general dissent and discord.
19:42:08 <notting> in absence of a decision, we default to 12/18 freeze and 1/8 release
19:42:11 <jreznik> nirik: could you repropose as anaconda/fedup is ok with that
19:42:14 <t8m> I have no problem with moving the freeze week earlier
19:42:18 <nirik> proposal: move freeze up a week to 12/11 and keep release 01/08.
19:42:26 <nirik> jreznik: like that ^
19:42:28 <mitr> nirik: +1
19:42:29 <t8m> nirik, +1
19:42:32 <jreznik> nirik: thx
19:42:33 <jwb> +1
19:42:34 <limburgher> nirik: +1
19:42:38 <mjg59> +1
19:42:47 * nirik just hit up arrow. Thats the same thing I just typed a few minutes ago
19:43:01 <notting> -1. i don't like the idea of compressing the fix time for beta feedback.
19:43:02 <pjones> +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 <mmaslano> +1
19:43:31 <mjg59> t8m: We no longer need RH legal approval
19:43:33 <jwb> notting, fwiw, such feedback can also be blocker bugs
19:43:35 <pjones> t8m: hey, wait now.  we aren't asking you to move freeze.
19:43:40 <jreznik> notting: as we are releasing after christmass - there should be probably some time...
19:44:08 <nirik> jreznik: only if they are blockers... otherwise they are 0 days.
19:44:39 <jwb> i predict a massive amount of 0 day updates regardless of when we release
19:44:46 <nirik> yes, there always are.
19:44:55 <jwb> like, a 3.7 kernel rebase
19:45:15 <notting> so we are ok with moving the 'final change deadline' *up*?
19:45:16 * limburgher has to go in 2 minutes.
19:45:17 <jreznik> nirik: that's why we have blocker bug process...
19:45:34 <jwb> notting, apparently, yes
19:45:44 <nirik> yes, seems so
19:46:04 <notting> i think this will go over poorly. but ok...
19:46:13 <mitr> notting: You're right
19:46:23 <mitr> nirik: changing vote to -1 , if that matters
19:46:27 <jwb> notting, for once i hope you're wrong :)
19:46:51 <mitr> Having two weekends for testers would be fine, freezing 2 days after the second one is too early to fix anything
19:46:56 <jreznik> 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 <jreznik> mitr: ?
19:47:16 <t8m> ok, then reverting to -1 as well
19:47:48 <mitr> jreznik: Nov 27 release, 2nd weekend is Dec 8-9, proposal is to freeze on dec 11
19:47:54 <pjones> 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 <notting> jreznik: final change deadline we've given to packagers/developers
19:48:36 <notting> jreznik: and telling them they as of today now have 6 days instead of 13
19:48:37 <adamw> pjones: eh? can't unpack that sentence.
19:48:44 <pjones> adamw: I think we blew it.
19:48:46 <jreznik> notting: for testing - there's blocker bug process... for developers - do we want more development on nearly final?
19:48:54 <nirik> 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 <pjones> 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 <nirik> adamw: he's refering to secure boot
19:49:12 <adamw> pjones: oh.
19:49:12 <jreznik> notting: on the other hand, I don't disagree...
19:49:25 <notting> in any case, we're at +6 -3 at this point. if people are ok with that, we can move on?
19:49:34 <nirik> please
19:49:43 <mitr> sure
19:50:11 <notting> #agreed (960) Final change deadline moved from 12/18 to 12/11. Release date remains 01/08. (+:6, -:3 0:0)
19:50:15 <notting> jreznik: you will announce?
19:50:19 <jreznik> notting: yes
19:50:47 <notting> ok
19:51:03 <notting> #topic 940 - The /tmp-on-tmpfs feature should be disabled by default
19:51:05 <notting> .fesco 940
19:51:08 <zodbot> notting: #940 (The tmp-on-tmpfs feature should be disabled by default) – FESCo - https://fedorahosted.org/fesco/ticket/940
19:51:26 <pjones> I think we shouldn't discuss this.
19:51:36 <pjones> It was tacked on at the last minute with no additional details.
19:51:52 <mmaslano> imho close it if no-one changed opinion
19:51:54 <pjones> 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 <notting> the ticket had been sitting in the queue with "postponed until future [post-beta] meeting when fedora is more tested"
19:52:35 <pjones> I could get behind just closing it.
19:52:36 <notting> this is the last such meeting, per the prior discussion
19:52:46 <nirik> 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 <t8m> Did anybody change their opinion?
19:53:12 <mjg59> nirik: 873831 looks like a trivial anaconda patch
19:53:22 <nirik> could well be.
19:53:23 <mjg59> pyanaconda/packaging/yumpayload.py:_yum_cache_dir = "/tmp/yum.cache"
19:53:34 <t8m> AFAIK there are at least 3 votes (mitr, me, mmaslano) for revert.
19:53:41 <t8m> anybody else would like to revert?
19:53:46 <nirik> also, those bugs aren't on the tmfs tracker...
19:53:53 <pjones> t8m: this is awful, processwise.
19:54:06 <pjones> if nobody has brought it up /because/ they changed their mind, there's no reason to hold a new vote.
19:54:09 <t8m> pjones, I can live with that
19:54:11 <pjones> it has failed a vote several times.
19:54:18 <mjg59> Making 873831 a blocker seems reasonable
19:54:32 <mmaslano> so close it
19:54:34 <nirik> it was rejected based on the info at the time... but sure it could be revisited.
19:54:45 <notting> the last time, we postponed a vote until after beta
19:54:59 <notting> so it's probably worth just having a vote and being done with it
19:55:05 <t8m> notting, +1
19:55:31 <t8m> I promise I won't propose the revert again if we vote today to reject the revert. :D
19:55:40 <notting> proposal: Fedora 18 defaults to /tmp on tmpfs.
19:55:54 <mjg59> +1
19:55:56 <t8m> notting, that's wrong proposal - that is the current situation
19:55:56 <nirik> +1. Please file bugs and attach them to the tracker for concrete cases we need to fix.
19:56:02 <mitr> -1 for the record
19:56:06 <pjones> notting: +1 (though I still disagree with giving this another vote instead of just closing it based on the previous ones.)
19:56:06 <mitr> t8m: whatever :)
19:56:13 <t8m> but -1 anyway
19:56:23 <mmaslano> -1 just for the record
19:56:47 <BobJensen> Isn't there supposed to be a Board meeting taking place in here right now?
19:56:55 <mjg59> BobJensen: See -1
19:56:56 <jwb> BobJensen, moved to fedora-meeting-1
19:56:56 <pjones> BobJensen: it's in #fedora-meeting-1
19:56:57 <gholms> BobJensen: It's in -1 at the moment.
19:58:20 * notting goes looking for limburgher's prior vote
19:58:37 <jwb> +1
19:59:04 <jreznik> BobJensen: so many -1 votes on your question for tmpfs :) *joking*
19:59:36 <notting> 18:04:35 <limburgher> mjg59:  I've gone from +1 for default to +-0.  really on the fence.
19:59:40 <notting> well, THAT helps.
19:59:52 <pjones> that's 5:3 if we assume notting is for his proposal.
20:00:13 <notting> pjones: not necessarily. just stated it
20:00:27 <pjones> notting: that's why I singled it out, yes.
20:00:42 <mjg59> Well, we're not going to reach 5 for reverting
20:01:15 <mitr> right, so close it and move on?
20:01:34 <t8m> 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 <notting> 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 <notting> although reverting does make the systemd private /tmp support... messier.
20:02:26 <notting> ah, nm. they're in /var/tmp
20:02:33 <pjones> and it's a hell of a thing to do right before freeze.
20:03:03 <t8m> pjones, that's why you argued that the decision should be postponed after beta didn't you? :D
20:03:06 <jwb> pjones, well, we did say we'd revisit it after beta
20:03:24 <jwb> helpfully, we just moved freeze up after slipping beta by a lot
20:03:45 <notting> as it stands now, neither the affirmative to keep nor the affirmative to revert will pass. hooray?
20:04:18 <t8m> affirmative to keep is not needed - keep is the default
20:04:32 <mitr> I think so as well - anybody arguing otherwise?
20:04:34 <notting> (unless any of the -1-to-have-as-default are also -1-to-revert)
20:05:08 <t8m> proposal: close the ticket because there is not and will not be enough votes before F18 final freeze to revert
20:05:13 <notting> t8m: shall i phrase it for the record in the inverse, then (proposal: revert /tmp-on-tmpfs as default)
20:05:27 <t8m> notting, I don't care
20:06:37 <notting> #agreed #940 (The tmp-on-tmpfs feature should be disabled by default) does not pass. (+:4, -:4, 0:1)
20:06:38 <pjones> t8m: no, I think it's wrong either way tbh
20:06:49 <pjones> t8m: hence I'm still voting against reverting it
20:07:38 <notting> moving on
20:07:42 <notting> #topic Open Floor
20:07:48 <jwb> chair?
20:07:52 <notting> #info Elections going on now - please vote.
20:07:55 <notting> whoops
20:07:57 <jwb> i'll chair next week
20:08:00 <jwb> keep topic current
20:08:09 <notting> #info Next week's chair is jwb
20:08:11 <notting> thx
20:08:14 <notting> anything else?
20:09:22 <notting> if not, will close meeting in two minutes
20:11:34 <notting> #endmeeting