| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| Hi everybody; who's around? | ||
| * tibbs here | ||
| poelcat here | ||
| notting is here | ||
| caillon | ||
| jeremybb | On my way back from lunch (as is spot) | |
| * nirik stops cursing at the POS vmware-server-console rpm and is here. | ||
| f13 | I'm here. | |
| bpepple | ok, let's get started since we've got quite a bit on the schedule this week. | |
| --- bpepple has changed the topic to: Misc - Feature Process - https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00003.html - poelcat | ||
| poelcat | We are gathered here today to discuss the feature process. I like it pretty well and think it is mostly fine the way it is, but then I wrote most of it ;-) | |
| For F9 I'd like FESCo to fix the parts they don't like now so that once the feature reviews kick in we can focus our energy on the features instead of complaining about parts of the process some voting FESCo members don't like or agree with. | ||
| With that in mind I will guide us through the issues collected on this page: http://fedoraproject.org/wiki/Features/F9PolicyReview | ||
| any objections so far? | ||
| f13 | none from me. | |
| tibbs | Nope. | |
| --- poelcat has changed the topic to: feature definition http://fedoraproject.org/wiki/Features/F9PolicyReview#definition | ||
| poelcat | Are we happy with the current defition of a 'Feature'? If 'no', what needs to change? | |
| * nirik is ok with the current def | ||
| bpepple | for the most part, I think are current definition is good. | |
| * dwmw2_BOS wakes up | ||
| bpepple | s/are/our/ | |
| caillon | poelcat, what about mclasen's input here? | |
| * dgilmore is here | ||
| caillon | i guess it's not entirely clear that's been incorporated to me | |
| f13 | So my toughts on that | |
| mclasen | its been incorporated in the review page, at least | |
| f13 | he seems mostly concerned that some features all the required Feature stuff doesn't make sense. | |
| I agree, and I think that exceptions can be made on a case by case basis | ||
| poelcat | maybe asked a different way "what is not a feature?" | |
| f13 | I think it would be silly to try and enumerate all the different itereations of what a "feature" can be and instead rely upon reasonable humans doing the creation/review process to do what's right for a given feature instance. | |
| poelcat | caillon: i'm trying to get at the bookmarks feature I chased you down after :) | |
| mclasen | f13: I'm not asking for exceptions from a uniform 1-size-fits-all feature definition | |
| I'm asking for recognizing that there are just different things | ||
| that we all collect under the term feature | ||
| poelcat | caillon: that in the end you said wasn't a feature | |
| f13 | mclasen: how cna we "recognize" this? | |
| mclasen: what can we do that makes you feel like we've recognized this? | ||
| caillon | poelcat, nor did I submit or know existed (which is something else that in retrospect I'd like to make sure we avoid putting people on the hook without their knowledge) | |
| mclasen | f13: that is a good question | |
| f13 | mclasen: if you can't answer that, I'm not sure we can either :/ | |
| poelcat | should we move on then? | |
| jeremybb | Making sure a feature owner knows they are the owner is very important, yes | |
| mclasen | f13: in the end, we'll do what is right for the feature at hand, anyway; we could just try to avoid unnecessary friction with the process while doing so | |
| f13 | mclasen: absolutely. | |
| poelcat | mclasen: has that been a problem? | |
| f13 | mclasen: perhaps in the marketing we can try to come up with some classifications of features to help with promotion and such. | |
| * c4chris is here now | ||
| poelcat | caillon: okay so we agree that someone should not volunteer someone else as a feature owner | |
| notting | ... except their manager ;) | |
| * poelcat is trying to keep things moving... looks like our current feature definition stands | ||
| mclasen | poelcat: not sure I would call it a problem per se, but e.g the feature template is not necessary ideal for "incremental improvement" features | |
| poelcat: I have been setting up a fair number (all ?) of the desktop feature pages so far | ||
| but I have always informed people when I made them the owner of a feature... | ||
| caillon | poelcat, no, its fine to do that if the owner is aware of it | |
| poelcat | caillon: fair enough | |
| i guess i wonder if incremental improvements should wait until their are more fully defined | ||
| --- poelcat has changed the topic to: feature definition http://fedoraproject.org/wiki/Features/F9PolicyReview#page-purpose | ||
| poelcat | Thoughts and comments on the purpose of feature pages? | |
| caillon | were we ready to move on just now? | |
| poelcat | caillon: sorry... we've got a lot to cover and it was silent | |
| caillon | okay. | |
| nirik | I think the purpose is all of those things... so thats fine. Perhaps hounding of feature owners could be on an increasing scale? ie, not much at the start of a cycle, and more often getting to alpha/beta/pr | |
| warren | ack, sorry here now. Went out for lunch, and managed to lock myself out. :/ | |
| jmtaylor | I know from a -doc standpoint feature pages would be nice if they were done for release notes and had some uniformity as to content | |
| so we can get a better idea of new things to that release, which at this point is quite difficult, I know Rahul has a time of it tracking things down | ||
| caillon | poelcat, btw i don't see any discussion of how often to hound people on the topics for discussion. i know i made a few comments in reply to your fedora-devel-list post | |
| poelcat | caillon: it's coming up :) | |
| caillon | poelcat, oh wait, i'm blind. it wasn't a main heading | |
| bpepple | poelcat: I'm fine with the page purpose. | |
| c4chris | I don't think we can clearly "define" what we mean by feature | |
| tibbs | Yes, I think "all of the above" applies. | |
| c4chris | it's just something we feel like calling a feature, because we can point it out and talk about it | |
| caillon | c4chris, then how do we expect Feature engineers to define it? | |
| I think we have to define it | ||
| tibbs | I was happy with letting them define it. | |
| c4chris | tibbs: yes | |
| caillon | c4chris, then that's our definition. | |
| f13 | "Are you going to need cooperation from other people?" "Do you want something advertised at the release?" "Do you think the work you're doing is really cool?" --> Propose it as a Feature. | |
| bpepple | f13: +1 | |
| caillon | c4chris, "if we don't like your project enough to talk about it, it's not a feature" | |
| c4chris | caillon: yes, and I think it's fine | |
| tibbs | The problem comes when F9 release is looming and we say "that should have been a feature". | |
| mclasen | if I work on something cool, I don't want it to be "approved" by somebody else... | |
| f13 | so there are 2 things. | |
| 1) what can be proposed as a feature. | ||
| 2) what does it mean for something to /be/ a Feature | ||
| 2 can largely help define what is suitable for 1 | ||
| caillon | c4chris, and how do we determine what we want to talk about? | |
| f13 | mclasen: right, I don't want that to be the message. | |
| jmtaylor | is there a feature page template? | |
| poelcat | mclasen: agreed | |
| f13 | mclasen: I want the message to be "is your cool thing cool enough for the project to spend the effort to do whatever it is we do with the listed "Features"?" | |
| c4chris | caillon: we make sure it's ready, works as advertised, and get some reasonable blurb about it that can be put in the announcement | |
| poelcat | jmtaylor: http://fedoraproject.org/wiki/Features/Template | |
| f13 | without having a clear definition of what it means to /be/ a Feature, it's hard to decide other things. | |
| poelcat | f13: yes, that is what i'm trying to get at | |
| caillon | f13, which really undermines alot of the work that people do on non-cool things. | |
| notting | f13: unfortunately, it's hard to quantify, and different for different things | |
| 'make yum 50% faster' -> feature. 'make awk 50% faster' -> probably not 'feature'. | ||
| mclasen | caillon: but it is cool that somebody else is doing the uncool work... | |
| f13 | caillon: but it makes it easier to tell people that we're not going to do whatever it is we do for Features for their thing, if we have a clear list of what it is we actually do. | |
| caillon | notting, that guy is pretty cool btw. i met him in prague last weekend. | |
| warren | notting, given that yum is an often complained about component, even if what we do is truly not novel, the PR value might be worthwhile. | |
| f13 | mostly the approval process is to make sure somebody doesn't do something stupid like "Hey, Fedora 9 is goign to ship all the Windows codecs, and large chunks of Windows source code for review! LOL!" and have it listed as an official feature. | |
| warren | notting, of it being part of the announcement | |
| mclasen | notting: I kinda disagree btw, even if speeing up awk is something that we would not put on the fedora frontpage, it is still cool for people who use awk a lot, and my deserve its mention | |
| f13 | that's /why/ we have a step between proposed and accepted features. Accepted features is what we point press and such at, not proposed. | |
| tibbs | Frankly, I would say "make awk 50% faster" is a feature. Maybe not a top-of-the-page feature, but certainly something we should tell the world about. | |
| warren | f13, +1 | |
| abadger1999 | mclasen: +1 | |
| poelcat | f13: that is nice distinction... maybe we should call them 'accepted' instead of 'approved' | |
| f13 | and I would totally +1 a 50% awk speedup as a feature. | |
| poelcat: I'm OK with that, if it helps. | ||
| warren | +1 to make awk -50% slower | |
| mclasen | it might also call for a distinction between "major features" and minor ones | |
| caillon | warren, fwiw, stepan kasal already did that for f8 | |
| warren | caillon, I was joking. | |
| caillon | I wasn't | |
| He's a really smart guy | ||
| warren | well that's cool | |
| caillon | but it wasn't a 'feature' | |
| warren | Perhaps minor features don't really need a full feature page, but we still need some kind of simple approval process for it to be listed as one-liners in the announcements. | |
| poelcat | mclasen: but then you have to decide bwetween major and minor and we can't even decide on major :) | |
| nirik | well, everything can't be a feature... features should be high visibility, major things... | |
| caillon | nirik, why should they be? | |
| warren | "Evolution IMAP no longer sucks" is a notable feature, but doesn't need a feature page. | |
| caillon | that's what i'm trying to figure out. what exactly do we think a "feature" is | |
| f13 | nirik: You've seen apple's 300 features page right? | |
| mclasen | poelcat: I'm personally fine to leave the decision of major vs minor to the people writing the release notes | |
| warren | (too bad it will never happen) | |
| nirik | upgraded libfoobar from 1.0.0.1 to 1.0.0.2! FEATURE! | |
| notting | hm, i'm convinced. my only concern is that if the feature list grows to 100, is it manageable by our process? | |
| c4chris | a "feature" needs to bring some kind of "change" I think | |
| mclasen | poelcat: but really, it should be pretty obvious what the major features are, in most cases | |
| f13 | nirik: that all depends on what changed between 1001 adn 1002 | |
| warren | Minor features should list only notable things. Bigger number isn't notable in of itself. | |
| dgilmore | f13: we added funk to it :) | |
| * poelcat wonders if we can really get concensus on this here/now ? | ||
| f13 | here is what I propose. | |
| nirik | well, if it's any change, then we 'rpm -qa --changelog > featurepage' and I don't think thats what we want... | |
| f13 | for F9, change verbage from "approved" to "accepted". LIst somewhere the reason we accept is to prevent illegal or otherwise naughty features from being picked up by the media and getting usn in trouble. | |
| for F9+ investigate ways to make Feature process lighter weight for minor features. | ||
| warren | To simplify this, we should have major features require a feature page and proposed/approved. Minor features don't need all that, and are listed as one-liners in the press. Since it is only a PR thing, someone is appointed as minor feature editor and has final say. Simple? | |
| poelcat | i like that... single pages for each major feature... a running single page for all minor features? | |
| caillon | nirik, no. but how do we tell joe fedora contributor that his work to make foo better isn't good enough to make the news? that could potentially lose him as a future contributor | |
| c4chris | fine with me | |
| jmtaylor | could we make "enhancement" as a go between feature? and make that our information dump for minor changes? | |
| caillon | f13, i think that sounds pretty reasonable. | |
| warren | poelcat, yes, and the appointed minor feature editor for the release chooses which to keep for the press... whittle it down to the truly notable. | |
| wwoods | If we want pretty announcements, we should just pick a number (say, 100) and list the top 100 improvements | |
| f13 | we're in the weeds here. | |
| we need to get back on track. | ||
| bpepple | f13: agreed. | |
| caillon | f13, i think i'd like it somewhat better if the feature is proposed to be accepted first and we say minor/major before the feature page is written. | |
| I don't want people to waste time writing up a huge page that we'll only do a blurb for | ||
| warren | poelcat, perhaps in order to keep everyone happy, the full list of minor features is only edited for accuracy, not how awesome it is. So people can be directed there if they really want all 2000 banal details. | |
| caillon | f13, but in general i like that | |
| poelcat | okay... moving on | |
| warren | caillon, it would be a more huge waste of time to write full feature pages and put them through approval for every little one-liner | |
| --- poelcat has changed the topic to: feature definition http://fedoraproject.org/wiki/Features/F9PolicyReview#page-update | ||
| poelcat | Does updating feature pages matter and how often should the Feature Wrangler nag the owners? | |
| f13 | caillon: sure, but I suppose something I do like about having a page written before acceptance is making sure there is a well thought out contengency plan. | |
| caillon: but I see your point. | ||
| notting | poelcat: 1) updating matters 2) before beta, i'm not sure it matters *that much* | |
| f13 | caillon: that could easily be done as "we like what you're proposing in principle, please do a major feature request and we'll do the final approval" | |
| tibbs | notting: +1 | |
| caillon | warren, um what? i'm trying to avoid exactly what yuo just said | |
| jmtaylor | notting: +1 | |
| c4chris | notting: +1 | |
| caillon | f13, +1 | |
| bpepple | notting: agreed. | |
| f13 | poelcat: Updating matters. | |
| nirik | notting: +1 | |
| poelcat | notting: give me something specific I can implement :) | |
| tibbs | Once we get into beta, though, it becomes really important because we need some basis for deciding whether we need to revert stuff. | |
| f13 | poelcat: updating for advertised releases, matters. | |
| (alpha/beta/PR) | ||
| dgilmore | nirik: indeed | |
| * poelcat worries those increments are too far apart | ||
| f13 | poelcat: updating and signaling FESCo or releng or somebody that it would be great to do a snapshot with the freshly updated bits matters a lot too | |
| caillon | poelcat, if you make people update every two weeks, they'll just wait for a while to do the feature page. | |
| mclasen | on the contingency plans, have we had any that were different from "go back to status quo ante" ? | |
| notting | poelcat: ok, maybe... 1) update is required before beta. 2) updates are preferred before alpha. 3) *after* beta, updates are required every N weeks? | |
| caillon | poelcat, I don't think so. We're trying to gather data, not police people. | |
| f13 | mclasen: in general, perhaps not, but that's where we'd want specifics, like for NM it would be good to know what all bits would have to be rolled back of NetworkMangaer itself was rolled back. | |
| caillon | poelcat, we're trying to pull too much. features should be pushed. | |
| f13 | notting: +1 | |
| caillon | notting, unless finished ;) | |
| bpepple | notting: +1 | |
| mclasen | f13: thats a fair point | |
| poelcat | caillon: i hear your concerns, but you keep saying things need to be different, but w/o ways on how to do it | |
| notting | mclasen: speaking of, should xorg 1.4 have a feature page? | |
| poelcat | caillon: how can features be push? | |
| jmtaylor | ideally updated in time for translators to hack away without deadline crush | |
| caillon | poelcat, notting already gave the plan i support. | |
| poelcat, i meant updates need to be pushed by the engineer. not pulled from them. | ||
| poelcat | ERROR: N is undefined | |
| f13 | poelcat: 2 | |
| caillon | and we're really doing policing right now as it is. | |
| mclasen | notting: pretty sure it should, yeah | |
| caillon | which is bad | |
| 2 weeks is fine for me | ||
| poelcat | caillon: so what is the oposite of policing? | |
| c4chris | caillon: you mean: if they don't push, we simply remove the feature ? | |
| poelcat | caillon: if i hadn't hounded the NetworkManager guys to update the page it would still be dated august 2007 ;-) | |
| mclasen | there is only one guy, unfortunately | |
| caillon | poelcat, actually no. if *I* hadn't phoned him, it would be still dated that. ;-) | |
| * poelcat adds another nag routine to the toolbelt | ||
| poelcat | "now we require your phone number" | |
| :) | ||
| c4chris | and a voodoo doll :) | |
| poelcat | yes! | |
| caillon | c4chris, that's what we need to decide... | |
| tibbs | Erm, so we're still on topic 1 of this meeting. | |
| caillon | c4chris, what if we have this really awesome feature, which is done, but nobody wants to update/create a feature page for it? | |
| do we still talk about it? | ||
| f13 | tibbs: yeah :/ | |
| c4chris | caillon: how do we know it is awesome if we don't know its status ? | |
| caillon | c4chris, we're the ones that want to talk about the features. the maintainers of packages might not want to do so too much. some people prefer to just do their work and go. | |
| c4chris | if we know the status is good somehow, then I guess it's fine | |
| poelcat | caillon: you are advocating no policing, but what are your proposing in its place? | |
| caillon | c4chris, let's say that NetworkManager cured cancer, but even with all the phone calls and hounding, dcbw didn't udpate the page. do we revert it? | |
| all our testing in rawhide for this example shows that it does indeed cure cancer | ||
| abadger1999 | caillon: Does he update us but just not the page? | |
| c4chris | I suppose if the feature owner went to the trouble of creating the page in the first place... | |
| caillon | c4chris, mclasen created the page on his behalf | |
| mclasen | no, I did | |
| c4chris | he could at least let someone know when it's supposed to be working... | |
| dwmw2_BOS | NetworkManager is supposed to be working? | |
| bpepple | caillon: I would hope in that case mclasen would be willing to do the page update. | |
| c4chris | then I guess you were on the hook too to get its status :) | |
| * poelcat thinks we should move on... objections? | ||
| nirik thinks we are trying to do too much ISO9000 over engineering here... what really needs any clarification here? | ||
| poelcat | 2 more issues | |
| c4chris | I'm happy to have a go-between acting as "feature operator" | |
| mclasen | bpepple: sure I can set the completion percentage to 100 - days till GA, if that helps... | |
| abadger1999 | Because there needs to be communication of some sort... in NM's case we probably should have been telling the KDE SIG that we were going to forge ahead with NM and their upstream wasn't being responsive to our schedule. | |
| caillon | nirik, we're trying to figure out what happens when the feature page is not updated | |
| f13 | abadger1999: I'm pretty sure they knew, we kept rdieter in the loop | |
| caillon | which is pretty important if we're going to go through this whole process | |
| rdieter | yep, we knew. | |
| * c4chris thinks we should move on... | ||
| --- poelcat has changed the topic to: feature definition http://fedoraproject.org/wiki/Features/F9PolicyReview#freeze | ||
| poelcat | What does feature freeze mean? | |
| caillon | (what does moving on mean, that we're in agreement with the current policy?) | |
| dwmw2_BOS | what does agreement mean? | |
| c4chris | I think we mostly agreed to notting's idea | |
| bpepple | btw, for clarification when I write the minutes, did we decide to do notting's suggestions? (1) update is required before beta. 2) updates are preferred before alpha. 3) *after* beta, updates are required every N weeks) | |
| poelcat | bpepple: yes, where N = 2 | |
| bpepple | poelcat: great. thanks. | |
| * nirik isn't sure what the current policy says about pages that don't get updated... dropped? | ||
| dgilmore | bpepple: i say +1 to that | |
| caillon | c4chris, yes but that was about a different topic. what about the contingency plan? | |
| poelcat | nirik: that is the last topic | |
| tibbs | bpepple: +1 BTW. | |
| nirik | bpepple: +1 on notting's suggestion | |
| f13 | is there anybody still hung up on the previous topic of hunting down updates? | |
| caillon | i agree to (1) update is required before beta. 2) updates are preferred before alpha. 3) *after* beta, updates are required every 2 weeks) | |
| warren | hunting? | |
| f13 | warren: whatever. | |
| bpepple | poelcat: I agree that we need to be more disciplined than we were for F8 in regard to feature freeze. | |
| f13 | poelcat: IIRC "Feature Freeze" meant that all accepted features had to be in a testable state, or they needed to make other arrangements for extentions. | |
| poelcat: and that no /new/ features would be reviewed after that point. | ||
| jeremy | I think that we're always going to have the one or two stragglers that we agitate over and end up having extensions for | |
| caillon | f13, +1 | |
| jeremy | I actually think we did shocking well for a first time in f8 | |
| f13 | me too | |
| poelcat | f13: that was we changed to when 4 features were ready at feature freeze :) | |
| jmtaylor | f13: can that be included to mean that docs must be up to date with features? | |
| poelcat | which is okayu | |
| i just want restate the policy to say what we are going to do this time | ||
| f13 | poelcat: no, I distinctly remember from the first conversations I was involved with regarding hte feature freeze was that features had to be 'testable' by feature freeze. | |
| caillon | poelcat, fwiw, f13's statement is pretty close to RHEL's. There've been some late features sneaking in to past releases. they just are more closely watched. | |
| notting | poelcat: yell at you a lot and review for possible exception? | |
| where you == feature owner? | ||
| poelcat | http://fedoraproject.org/wiki/Features/Policy#drop | |
| f13 | jmtaylor: that goes back to previous topic, feature page update required before beta (which is the feature freeze) | |
| notting | NM was granted an exception. KDE4 was dropped. | |
| f13 | as was detalrpms | |
| deltarpms | ||
| notting | what other cases were there? | |
| mclasen | bookmarks | |
| nirik | xulrunner? | |
| caillon | yea, xulrunner was dropped | |
| mclasen | betterstartup | |
| caillon | poelcat, I don't think we should drop if: # | |
| # Feature owner fails to consistently provide status or attend IRC meetings (if held). | ||
| poelcat | f13: the word "testable" is not found on the page... we could add it, but that term seems very subjective | |
| f13 | also, it should be "Feature is not in a testable state at feature freeze" | |
| rather than "complete" | ||
| the third item doesn't make sense either. If the feature were conflicting, we wouldn't have accepted it in the first place. | ||
| caillon | the feature could be done, and they may have taken a job at $foo and just don't want to deal with us anymore as one possible case. we shouldn't not market it just based on one person's unwillingness to provide updates | |
| f13 | caillon: right, we jsut find somebody else to "manage" that feature. | |
| c4chris | f13: +1 | |
| f13 | *cough* orphaned features process | |
| caillon | heh | |
| c4chris | aieeee | |
| dgilmore | brb | |
| c4chris | testable means the package is in and runs (at least for a while) | |
| f13 | c4chris: and that the feature owner is interested in the failures rather than "yes, I know it's broken, please don't bother me about it" | |
| caillon | poelcat, i don't think testable really is subjective. it means it's in. it works more or less. and users can provide feedback. | |
| c4chris | f13: obviously | |
| caillon: nice definition | ||
| f13 | poelcat: "Testable" is somewhat vague on purpose, but mostly it means that the feature owner feels that the feature is in a state where we can point hordes of people at it and ask for their feedback about it. | |
| (which is something of the entire point of say a Beta release...) | ||
| caillon | yeah | |
| poelcat | f13: okay... that makes me feel a little better | |
| okay one last question.... | ||
| when does something need to be at 100% then? | ||
| caillon | RC | |
| poelcat | caillon: -1 | |
| mclasen | I disagree with that somewhat | |
| f13 | final freeze I would think | |
| mclasen | oftentimes it makes sense to reach a milestone and leave it at that | |
| f13 | if it's not 100% at final freeze, special care/attention is going to be needed. | |
| mclasen | and pick the rest up for the next release | |
| like we do for NM or bluetooth | ||
| f13 | mclasen: that is a good point. | |
| mclasen | maybe that should be handled by adjusting the feature page at feature freeze time | |
| to reflect whats going to be in the release | ||
| wwoods | final freeze -> PR | |
| bpepple | mclasen: +1 | |
| f13 | and we'll have to figure out some way of communicating that in the feature page, so that translaters know what's goign on and such. | |
| poelcat | mclasen: +1 | |
| c4chris | I think we should equate 100% with "good enough for useage" | |
| poelcat | c4chris: -1 | |
| caillon | c4chris, actually i think we should not have percentages for rolling things like this. | |
| poelcat | "i'm 100% done, but I am only 30% done with 75% of the fixes" ;-) | |
| f13 | caillon: I tend to agree for the ongoing improvement type features | |
| c4chris | caillon: also a possibility. Just use ready / not ready (eta N weeks) | |
| f13 | for those it just comes down to "this is the set that I accomplisehd for this release" | |
| caillon | I've never really liked the 100% thing. when is software _ever_ 100% done? | |
| f13 | heh | |
| notting | caillon: when it's removed | |
| nirik | could go to tags? development/beta/complete or something? | |
| c4chris | poelcat: I wouldn't call that "good enough" :) | |
| poelcat | c4chris: lol | |
| wwoods | feature-complete! that gives people leeway to just change the feature list and thus hit 100% whenever they feel like it | |
| ho ho fun. | ||
| nirik | yeah. ;( | |
| caillon | wwoods, which they can do anyway. | |
| wwoods | yeah, I know. seems like as good a metric as any, then. | |
| bpepple | ok, where are we on this? | |
| caillon | if we don't do QA, we're at develoeprs mercy. | |
| c4chris | at final freeze, I think | |
| bpepple | c4chris: with the clarification that mclasen had? | |
| caillon | yeah. I guess I equated final freeze with RC for some reason. but freeze sounds right if we make sure that rolling ones don't have percentages. | |
| c4chris | I'd say yea | |
| bpepple | does anyone object to that? | |
| wwoods | final freeze -> "Preview Release" (which we used to call RC in previous drafts but decided that was misleading since there's no way in hell we'll release the whatever we have at final freeze) | |
| f13 | does that give marketing folks enough time to fix things up? | |
| wwoods: final freeze is actually 4 days before the PR | ||
| caillon | wwoods, ah, yeah i think that's what i was thinking of. | |
| poelcat | f13: 21 days between final freeze and GA | |
| wwoods | right, final freeze -> compose/smoke test/sync/release | |
| * poelcat thinks so | ||
| poelcat | http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html | |
| item 1.2.4.1 | ||
| f13 | ok, I think we reached something of agreement on that one | |
| c4chris | w00t | |
| poelcat | vote: all at 100% at final freeze? | |
| nirik | +1 here. | |
| f13 | +1 | |
| c4chris | +1 | |
| bpepple | +1. | |
| warren | +1 | |
| tibbs | +1 | |
| notting | 0, in that you'll likely be redefining what 100% is at final freeze time. | |
| jeremy | +1 | |
| notting: well, yes | ||
| wwoods | the same way we redefine "blocker" at final freeze time | |
| f13 | notting: that's fine, so long as we know what to expect of that feature in the final release. | |
| wwoods | doesn't mean the process is not useful. | |
| jeremy | notting: but the plus of that is that you can know that what the list is at freeze time can be (relatively) accurately used for marketing fluff | |
| f13 | and knwo that the stuff that isn't 100% may have some changes happening to it before the final release | |
| poelcat | wwoods: the useful part is that the feature page reflects 100% of what was done | |
| caillon | and that not all features can be 100% | |
| f13 | caillon: they can be "100% for this release" | |
| caillon | so those should start at 100% then? | |
| nirik | anything more on ongoing features can then open a FN+1 feature page with the todo they didn't get done for the next cycle. | |
| bpepple | ok, we're already past the hour-point for the meeting. Is there anything else in regard to feature to discuss? | |
| caillon | i guess we can move on | |
| * poelcat will update the feature policy and post to the list | ||
| bpepple | poelcat: great, thanks. | |
| poelcat | BTW which list should "feature" related announcements and requests go to? | |
| bpepple | poelcat: devel? | |
| poelcat | not devel-announce? | |
| notting | poelcat: related to the *process*? devel. | |
| hm, maybe devel-announce, followup to -devel | ||
| f13 | deadlines devel-announce | |
| wwoods | -devel-list.. maybe -devel-announce | |
| poelcat | what about "please update your pages" ? | |
| nirik | direct to feature owners? | |
| c4chris | nirik: yes | |
| bpepple | f13: you had a bunch of topics to discuss? Since we probably can't get to all of them, which do you want to try to squeeze in this week? | |
| caillon | actually, a list is better. | |
| warren | direct and personal | |
| f13 | poelcat: if you word it as a "Info, here is a deadline, please make sure your pages are updated" than devel-announce or directly at feature owners. | |
| f13 | bpepple: F9 schedule | |
| caillon | personal mails are much easier to read and then forget about | |
| --- bpepple has changed the topic to: MISC - Proposed F9 Schedule - f13 | ||
| bpepple | f13: floors yours. | |
| f13 | poelcat linked to it above | |
| caillon | to a list, you can't then say that yuo never saw the nag mail | |
| warren | caillon, then both | |
| caillon | because people will know you have ;) | |
| --- bpepple has changed the topic to: MISC - Proposed F9 Schedule http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html - f13 | ||
| warren | caillon, many other people are the opposite way | |
| caillon | warren, sure okay. | |
| i'd be fine with that | ||
| f13 | the overview might be a bit hard to read, but all the dates are there. | |
| this is making use of the development cycle changes we approved last session | ||
| rel-eng has already given their approval of the schedule | ||
| poelcat | a more traditional view is here: http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html | |
| warren | f13, just one thought | |
| f13 | warren: yes? | |
| warren | f13, Alpha Release, might it be easier to understand if it said "Alpha" or maybe "Alpha Phase"? | |
| f13 | ... | |
| wwoods | that's poelcat's schedule | |
| warren | f13, it says Alpha Release and two dates next to it | |
| f13 | warren: read http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html instead. | |
| warren | f13, yes, this has the same problem | |
| --- bpepple has changed the topic to: MISC - Proposed F9 Schedule http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html - f13 | ||
| warren | only a label confusion | |
| f13 | warren: I care more about acceptance of the dates than any wording around it. | |
| warren | dates are fine to me | |
| bpepple | +1 to schedule. | |
| nirik | poelcat: .ics or other way people could subscribe and have them appear on calendars? that would be nice... | |
| warren | I'm just commenting that the label could be made clearer | |
| f13 | nirik: look at the top | |
| nirik | +1 on schedule here. | |
| warren | +1 to schedule | |
| poelcat | nirik: it is already there | |
| nirik | oh, sweet. | |
| caillon | (it would be nice if these would all appear in chronological order for future reference) | |
| f13 | caillon: they do in the milestones view | |
| caillon: and they will in the wiki schedule page | ||
| c4chris | +1 to schedule | |
| warren | f13, except they don't | |
| caillon | f13, 2 is 2008-Mar-04 and 3 is 2007-Nov-22 | |
| warren | f13, 7. Alpha Release 2008-Mar-11 | |
| f13, makes one think the alpha release is March 11th | ||
| f13 | whatever. | |
| poelcat | f13: +1 | |
| f13 | the discussion is about the actual dates, not whatever method is used to deliver them. | |
| would ya'll like it on blue color too? | ||
| poelcat | or another choise http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-details.html :) | |
| bpepple | ok, I see five (+1), under the assumption f13 is for it. anyone else want to vote? | |
| caillon | f13, maybe you've looked at these types of charts before, but i agree with warren. it's really hard to read for the untrained. | |
| warren | Any objections to possibly changing the labels (not dates) after the meeting? It would be a waste of everyone's time to discuss that here. | |
| * nirik tries to import into google calendar and it seems to be hanging. Oh well. | ||
| caillon | i'm starting to get it, but it's just taking a while to figure it out. | |
| f13 | caillon: WHATEVER. These are for poelcat to work with and deliver out ical files. This isn't going to be what we link to in the wiki. | |
| caillon | f13, um, how the fuck am i supposed to vote if I can't figure it out then? | |
| warren | I think these taskjuggler rendered layouts are OK, except it could represent the hierarchical sections in some clearer way. | |
| But this isn't FESCO's problem. | ||
| Did we ratify the dates? | ||
| bpepple | warren: I only saw five people voting for it. Less than 50% of FESCo. | |
| notting | +1 | |
| tibbs | +1 to schedule | |
| caillon | dates seem fine. +1 | |
| but still. geez. | ||
| bpepple | ok, that's a majority voting for it. | |
| nirik | caillon: yeah, it is hard to read... importing the ics will be much nicer... | |
| warren | It would be slightly better if the background row color were different at each level of the hierarchy | |
| or *something* | ||
| notting | offf... topic. next? | |
| caillon | I don't care about the color. I just couldn't figure out the dates. | |
| f13 | nirik: that's all that is necessary for this week. The rest can wait. | |
| caillon | and since I'm running at 12 hrs at the office now, it's 830, i'm hungry, and getting warm fuzzies when trying to vote, i'm outta here. | |
| bpepple | f13: ok, let's wrap up the meeting then. Anything else we must discuss before calling it quits? | |
| bpepple | topic FESCo meeting -- Free discussion around Fedora | |
| going once..... | ||
| poelcat | bpepple: change to bugzilla versions? | |
| bpepple | poelcat: ok. | |
| tibbs | I move that we do the feature discussion closer to the end of the meeting. | |
| --- bpepple has changed the topic to: MISC - Minor changes to bugzilla https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01161.html - poelcat | ||
| tibbs|h tibbs | ||
| f13 | I move that we discuss the bug changes on list and instead of in the meeting right now | |
| bpepple | tibbs: I was going to suggest maybe having a separate meeting for them, but I'll move that discussion to the mailing list. | |
| f13 | I would like to see some more input from other maintainers. | |
| f13 fab | ||
| bpepple | f13: I'm fine with that. poelcat? | |
| poelcat | which list ? I already posted to devel and test? | |
| tibbs | I agree with the bugzilla changes in any case. | |
| c4chris | +1 bz change | |
| notting | +0.5. might need to message where bugs against alpha/beta go | |
| c4chris | for the rest, I think we shoud adjourn | |
| wwoods | alpha and beta are rawhide snapshots | |
| that's the message | ||
| I think that's simple enough.. right? | ||
| anyway, discuss further on-list | ||
| bpepple | ok, so we're going to discuss further on-list, and vote on it next week. Is everyone alright with that? | |
| f13 | I am. | |
| c4chris | bpepple: +1 | |
| f13 | poelcat: devel is fine, but you might echo to the internal equiv. | |
| poelcat | f13: okay | |
| so we'll bring to a final vote next week? | ||
| bpepple | poelcat: yup. I'll make it our first item next week. | |
| poelcat | bpepple: thanks | |
| bpepple | alright, let's call it quits for today. | |
| * bpepple will end the meeting in 60 | ||
| warren | I like that plan. | |
| * bpepple will end the meeting in 30 | ||
| poelcat | f13: good reminder btw | |
| * bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!