--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo 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
jeremybbOn my way back from lunch (as is spot)
* nirik stops cursing at the POS vmware-server-console rpm and is here.
f13I'm here.
bpeppleok, 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
poelcatWe 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?
f13none from me.
--- poelcat has changed the topic to: feature definition http://fedoraproject.org/wiki/Features/F9PolicyReview#definition
poelcatAre we happy with the current defition of a 'Feature'?  If 'no', what needs to change?
* nirik is ok with the current def
bpepplefor the most part, I think are current definition is good.
* dwmw2_BOS wakes up
caillonpoelcat, what about mclasen's input here?
* dgilmore is here
cailloni guess it's not entirely clear that's been incorporated to me
f13So my toughts on that
mclasenits been incorporated in the review page, at least
f13he 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
poelcatmaybe asked a different way "what is not a feature?"
f13I 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.
poelcatcaillon: i'm trying to get at the bookmarks feature I chased you down after :)
mclasenf13: 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
poelcatcaillon: that in the end you said wasn't a feature
f13mclasen: how cna we "recognize" this?
mclasen: what can we do that makes you feel like we've recognized this?
caillonpoelcat, 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)
mclasenf13: that is a good question
f13mclasen: if you can't answer that, I'm not sure we can either :/
poelcatshould we move on then?
jeremybbMaking sure a feature owner knows they are the owner is very important, yes
mclasenf13: 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
f13mclasen: absolutely.
poelcatmclasen: has that been a problem?
f13mclasen: 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
poelcatcaillon: 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
mclasenpoelcat: 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...
caillonpoelcat, no, its fine to do that if the owner is aware of it
poelcatcaillon: 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
poelcatThoughts and comments on the purpose of feature pages?
caillonwere we ready to move on just now?
poelcatcaillon: sorry... we've got a lot to cover and it was silent
nirikI 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
warrenack, sorry here now.  Went out for lunch, and managed to lock myself out. :/
jmtaylorI 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
caillonpoelcat, 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
poelcatcaillon: it's coming up :)
caillonpoelcat, oh wait, i'm blind.  it wasn't a main heading
bpepplepoelcat: I'm fine with the page purpose.
c4chrisI don't think we can clearly "define" what we mean by feature
tibbsYes, I think "all of the above" applies.
c4chrisit's just something we feel like calling a feature, because we can point it out and talk about it
caillonc4chris, then how do we expect Feature engineers to define it?
I think we have to define it
tibbsI was happy with letting them define it.
c4christibbs: yes
caillonc4chris, 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.
bpepplef13: +1
caillonc4chris, "if we don't like your project enough to talk about it, it's not a feature"
c4chriscaillon: yes, and I think it's fine
tibbsThe problem comes when F9 release is looming and we say "that should have been a feature".
mclasenif I work on something cool, I don't want it to be "approved" by somebody else...
f13so 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
caillonc4chris, and how do we determine what we want to talk about?
f13mclasen: right, I don't want that to be the message.
jmtayloris there a feature page template?
poelcatmclasen: agreed
f13mclasen: 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"?"
c4chriscaillon: we make sure it's ready, works as advertised, and get some reasonable blurb about it that can be put in the announcement
poelcatjmtaylor: http://fedoraproject.org/wiki/Features/Template
f13without having a clear definition of what it means to /be/ a Feature, it's hard to decide other things.
poelcatf13: yes, that is what i'm trying to get at
caillonf13, which really undermines alot of the work that people do on non-cool things.
nottingf13: unfortunately, it's hard to quantify, and different for different things
'make yum 50% faster' -> feature. 'make awk 50% faster' -> probably not 'feature'.
mclasencaillon: but it is cool that somebody else is doing the uncool work...
f13caillon: 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.
caillonnotting, that guy is pretty cool btw.  i met him in prague last weekend.
warrennotting, given that yum is an often complained about component, even if what we do is truly not novel, the PR value might be worthwhile.
f13mostly 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.
warrennotting, of it being part of the announcement
mclasennotting: 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
f13that's /why/ we have a step between proposed and accepted features.  Accepted features is what we point press and such at, not proposed.
tibbsFrankly, 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.
warrenf13, +1
abadger1999mclasen: +1
poelcatf13: that is nice distinction... maybe we should call them 'accepted' instead of 'approved'
f13and 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
mclasenit might also call for a distinction between "major features" and minor ones
caillonwarren, fwiw, stepan kasal already did that for f8
warrencaillon, I was joking.
caillonI wasn't
He's a really smart guy
warrenwell that's cool
caillonbut it wasn't a 'feature'
warrenPerhaps 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.
poelcatmclasen: but then you have to decide bwetween major and minor and we can't even decide on major :)
nirikwell, everything can't be a feature... features should be high visibility, major things...
caillonnirik, why should they be?
warren"Evolution IMAP no longer sucks" is a notable feature, but doesn't need a feature page.
caillonthat's what i'm trying to figure out.  what exactly do we think a "feature" is
f13nirik: You've seen apple's 300 features page right?
mclasenpoelcat: 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)
nirikupgraded libfoobar from to! FEATURE!
nottinghm, i'm convinced. my only concern is that if the feature list grows to 100, is it manageable by our process?
c4chrisa "feature" needs to bring some kind of "change" I think
mclasenpoelcat: but really, it should be pretty obvious what the major features are, in most cases
f13nirik: that all depends on what changed between 1001 adn 1002
warrenMinor features should list only notable things.  Bigger number isn't notable in of itself.
dgilmoref13: we added funk to it :)
* poelcat wonders if we can really get concensus on this here/now ?
f13here is what I propose.
nirikwell, if it's any change, then we 'rpm -qa --changelog > featurepage' and I don't think thats what we want...
f13for 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.
warrenTo 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?
poelcati like that... single pages for each major feature... a running single page for all minor features?
caillonnirik, 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
c4chrisfine with me
jmtaylorcould we make  "enhancement" as a go between feature? and make that our information dump for minor changes?
caillonf13, i think that sounds pretty reasonable.
warrenpoelcat, yes, and the appointed minor feature editor for the release chooses which to keep for the press... whittle it down to the truly notable.
wwoodsIf we want pretty announcements, we should just pick a number (say, 100) and list the top 100 improvements
f13we're in the weeds here.
we need to get back on track.
bpepplef13: agreed.
caillonf13, 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
warrenpoelcat, 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.
caillonf13, but in general i like that
poelcatokay... moving on
warrencaillon, 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
poelcatDoes updating feature pages matter and how often should the Feature Wrangler nag the owners?
f13caillon: 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.
nottingpoelcat: 1) updating matters 2) before beta, i'm not sure it matters *that much*
f13caillon: 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"
tibbsnotting: +1
caillonwarren, um what?  i'm trying to avoid exactly what yuo just said
jmtaylornotting: +1
c4chrisnotting: +1
caillonf13, +1
bpepplenotting: agreed.
f13poelcat: Updating matters.
niriknotting: +1
poelcatnotting: give me something specific I can implement :)
tibbsOnce we get into beta, though, it becomes really important because we need some basis for deciding whether we need to revert stuff.
f13poelcat: updating for advertised releases, matters.
dgilmorenirik: indeed
* poelcat worries those increments are too far apart
f13poelcat: 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
caillonpoelcat, if you make people update every two weeks, they'll just wait for a while to do the feature page.
mclasenon the contingency plans, have we had any that were different from "go back to status quo ante" ?
nottingpoelcat: ok, maybe... 1) update is required before beta. 2) updates are preferred before alpha. 3) *after* beta, updates are required every N weeks?
caillonpoelcat, I don't think so.  We're trying to gather data, not police people.
f13mclasen: 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.
caillonpoelcat, we're trying to pull too much.  features should be pushed.
f13notting: +1
caillonnotting, unless finished ;)
bpepplenotting: +1
mclasenf13: thats a fair point
poelcatcaillon: i hear your concerns, but you keep saying things need to be different, but w/o ways on how to do it
nottingmclasen: speaking of, should xorg 1.4 have a feature page?
poelcatcaillon: how can features be push?
jmtaylorideally updated in time for translators to hack away without deadline crush
caillonpoelcat, notting already gave the plan i support.
poelcat, i meant updates need to be pushed by the engineer. not pulled from them.
poelcatERROR: N is undefined
f13poelcat: 2
caillonand we're really doing policing right now as it is.
mclasennotting: pretty sure it should, yeah
caillonwhich is bad
2 weeks is fine for me
poelcatcaillon: so what is the oposite of policing?
c4chriscaillon: you mean: if they don't push, we simply remove the feature ?
poelcatcaillon: if i hadn't hounded the NetworkManager guys to update the page it would still be dated august 2007 ;-)
mclasenthere is only one guy, unfortunately
caillonpoelcat, 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"
c4chrisand a voodoo doll :)
caillonc4chris, that's what we need to decide...
tibbsErm, so we're still on topic 1 of this meeting.
caillonc4chris, 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?
f13tibbs: yeah :/
c4chriscaillon: how do we know it is awesome if we don't know its status ?
caillonc4chris, 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.
c4chrisif we know the status is good somehow, then I guess it's fine
poelcatcaillon: you are advocating no policing, but what are your proposing in its place?
caillonc4chris, 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
abadger1999caillon: Does he update us but just not the page?
c4chrisI suppose if the feature owner went to the trouble of creating the page in the first place...
caillonc4chris, mclasen created the page on his behalf
mclasenno, I did
c4chrishe could at least let someone know when it's supposed to be working...
dwmw2_BOSNetworkManager is supposed to be working?
bpepplecaillon: I would hope in that case mclasen would be willing to do the page update.
c4christhen 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?
poelcat2 more issues
c4chrisI'm happy to have a go-between acting as "feature operator"
mclasenbpepple: sure I can set the completion percentage to 100 - days till GA, if that helps...
abadger1999Because 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.
caillonnirik, we're trying to figure out what happens when the feature page is not updated
f13abadger1999: I'm pretty sure they knew, we kept rdieter in the loop
caillonwhich is pretty important if we're going to go through this whole process
rdieteryep, we knew.
* c4chris thinks we should move on...
--- poelcat has changed the topic to: feature definition http://fedoraproject.org/wiki/Features/F9PolicyReview#freeze
poelcatWhat does feature freeze mean?
caillon(what does moving on mean, that we're in agreement with the current policy?)
dwmw2_BOSwhat does agreement mean?
c4chrisI think we mostly agreed to notting's idea
bpepplebtw, 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)
poelcatbpepple: yes, where N = 2
bpepplepoelcat: great. thanks.
* nirik isn't sure what the current policy says about pages that don't get updated... dropped?
dgilmorebpepple: i say +1 to that
caillonc4chris, yes but that was about a different topic.  what about the contingency plan?
poelcatnirik: that is the last topic
tibbsbpepple: +1 BTW.
nirikbpepple: +1 on notting's suggestion
f13is there anybody still hung up on the previous topic of hunting down updates?
cailloni agree to  (1) update is required before beta. 2) updates are preferred before alpha. 3) *after* beta, updates are required every 2 weeks)
f13warren: whatever.
bpepplepoelcat: I agree that we need to be more disciplined than we were for F8 in regard to feature freeze.
f13poelcat: 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.
jeremyI think that we're always going to have the one or two stragglers that we agitate over and end up having extensions for
caillonf13, +1
jeremyI actually think we did shocking well for a first time in f8
f13me too
poelcatf13: that was we changed to when 4 features were ready at feature freeze :)
jmtaylorf13: can that be included to mean that docs must be up to date with features?
poelcatwhich is okayu
i just want restate the policy to say what we are going to do this time
f13poelcat: 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.
caillonpoelcat, 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.
nottingpoelcat: yell at you a lot and review for possible exception?
where you == feature owner?
f13jmtaylor: that goes back to previous topic, feature page update required before beta (which is the feature freeze)
nottingNM was granted an exception. KDE4 was dropped.
f13as was detalrpms
nottingwhat other cases were there?
caillonyea, xulrunner was dropped
caillonpoelcat, I don't think we should drop if: #
# Feature owner fails to consistently provide status or attend IRC meetings (if held).
poelcatf13: the word "testable" is not found on the page... we could add it, but that term seems very subjective
f13also, 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.
caillonthe 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
f13caillon: right, we jsut find somebody else to "manage" that feature.
c4chrisf13: +1
f13*cough* orphaned features process
c4christestable means the package is in and runs (at least for a while)
f13c4chris: 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"
caillonpoelcat, i don't think testable really is subjective.  it means it's in.  it works more or less.  and users can provide feedback.
c4chrisf13: obviously
caillon: nice definition
f13poelcat: "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...)
poelcatf13: okay... that makes me feel a little better
okay one last question....
when does something need to be at 100% then?
poelcatcaillon: -1
mclasenI disagree with that somewhat
f13final freeze I would think
mclasenoftentimes it makes sense to reach a milestone and leave it at that
f13if it's not 100% at final freeze, special care/attention is going to be needed.
mclasenand pick the rest up for the next release
like we do for NM or bluetooth
f13mclasen: that is a good point.
mclasenmaybe that should be handled by adjusting the feature page at feature freeze time
to reflect whats going to be in the release
wwoodsfinal freeze -> PR
bpepplemclasen: +1
f13and 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.
poelcatmclasen: +1
c4chrisI think we should equate 100% with "good enough for useage"
poelcatc4chris: -1
caillonc4chris, 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" ;-)
f13caillon: I tend to agree for the ongoing improvement type features
c4chriscaillon: also a possibility.  Just use ready / not ready (eta N weeks)
f13for those it just comes down to "this is the set that I accomplisehd for this release"
caillonI've never really liked the 100% thing.  when is software _ever_ 100% done?
nottingcaillon: when it's removed
nirikcould go to tags? development/beta/complete or something?
c4chrispoelcat: I wouldn't call that "good enough" :)
poelcatc4chris: lol
wwoodsfeature-complete! that gives people leeway to just change the feature list and thus hit 100% whenever they feel like it
ho ho fun.
nirikyeah. ;(
caillonwwoods, which they can do anyway.
wwoodsyeah, I know. seems like as good a metric as any, then.
bpeppleok,  where are we on this?
caillonif we don't do QA, we're at develoeprs mercy.
c4chrisat final freeze, I think
bpepplec4chris: with the clarification that mclasen had?
caillonyeah.  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.
c4chrisI'd say yea
bpeppledoes anyone object to that?
wwoodsfinal 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)
f13does that give marketing folks enough time to fix things up?
wwoods: final freeze is actually 4 days before the PR
caillonwwoods, ah, yeah i think that's what i was thinking of.
poelcatf13: 21 days between final freeze and GA
wwoodsright, final freeze -> compose/smoke test/sync/release
* poelcat thinks so
f13ok, I think we reached something of agreement on that one
poelcatvote: all at 100% at final freeze?
nirik+1 here.
notting0, in that you'll likely be redefining what 100% is at final freeze time.
notting: well, yes
wwoodsthe same way we redefine "blocker" at final freeze time
f13notting: that's fine, so long as we know what to expect of that feature in the final release.
wwoodsdoesn't mean the process is not useful.
jeremynotting: 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
f13and knwo that the stuff that isn't 100% may have some changes happening to it before the final release
poelcatwwoods: the useful part is that the feature page reflects 100% of what was done
caillonand that not all features can be 100%
f13caillon: they can be "100% for this release"
caillonso those should start at 100% then?
nirikanything more on ongoing features can then open a FN+1 feature page with the todo they didn't get done for the next cycle.
bpeppleok, we're already past the hour-point for the meeting.  Is there anything else in regard to feature to discuss?
cailloni guess we can move on
* poelcat will update the feature policy and post to the list
bpepplepoelcat: great, thanks.
poelcatBTW which list should "feature" related announcements and requests go to?
bpepplepoelcat: devel?
poelcatnot devel-announce?
nottingpoelcat: related to the *process*? devel.
hm, maybe devel-announce, followup to -devel
f13deadlines devel-announce
wwoods-devel-list.. maybe -devel-announce
poelcatwhat about "please update your pages" ?
nirikdirect to feature owners?
c4chrisnirik: yes
bpepplef13: 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?
caillonactually, a list is better.
warrendirect and personal
f13poelcat: 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.
f13bpepple: F9 schedule
caillonpersonal mails are much easier to read and then forget about
--- bpepple has changed the topic to: MISC - Proposed F9 Schedule - f13
bpepplef13: floors yours.
f13poelcat linked to it above
caillonto a list, you can't then say that yuo never saw the nag mail
warrencaillon, then both
caillonbecause 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
warrencaillon, many other people are the opposite way
caillonwarren, sure okay.
i'd be fine with that
f13the 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
poelcata more traditional view is here: http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html
warrenf13, just one thought
f13warren: yes?
warrenf13, Alpha Release, might it be easier to understand if it said "Alpha" or maybe "Alpha Phase"?
wwoodsthat's poelcat's schedule
warrenf13, it says Alpha Release and two dates next to it
f13warren: read http://poelstra.fedorapeople.org/schedules/f9/f9-milestones.html instead.
warrenf13, 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
warrenonly a label confusion
f13warren: I care more about acceptance of the dates than any wording around it.
warrendates are fine to me
bpepple+1 to schedule.
nirikpoelcat: .ics or other way people could subscribe and have them appear on calendars? that would be nice...
warrenI'm just commenting that the label could be made clearer
f13nirik: look at the top
nirik+1 on schedule here.
warren+1 to schedule
poelcatnirik: it is already there
nirikoh, sweet.
caillon(it would be nice if these would all appear in chronological order for future reference)
f13caillon: they do in the milestones view
caillon: and they will in the wiki schedule page
c4chris+1 to schedule
warrenf13, except they don't
caillonf13, 2 is 2008-Mar-04 and 3 is 2007-Nov-22
warrenf13, 7.   Alpha Release   2008-Mar-11
f13, makes one think the alpha release is March 11th
poelcatf13: +1
f13the discussion is about the actual dates, not whatever method is used to deliver them.
would ya'll like it on blue color too?
poelcator another choise http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-details.html :)
bpeppleok, I see five (+1), under the assumption f13 is for it.  anyone else want to vote?
caillonf13, maybe you've looked at these types of charts before, but i agree with warren.  it's really hard to read for the untrained.
warrenAny 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.
cailloni'm starting to get it, but it's just taking a while to figure it out.
f13caillon: 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.
caillonf13, um, how the fuck am i supposed to vote if I can't figure it out then?
warrenI 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?
bpepplewarren: I only saw five people voting for it.  Less than 50% of FESCo.
tibbs+1 to schedule
caillondates seem fine.  +1
but still. geez.
bpeppleok, that's a majority voting for it.
nirikcaillon: yeah, it is hard to read... importing the ics will be much nicer...
warrenIt would be slightly better if the background row color were different at each level of the hierarchy
or *something*
nottingofff... topic. next?
caillonI don't care about the color.  I just couldn't figure out the dates.
f13nirik: that's all that is necessary for this week.  The rest can wait.
caillonand 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.
bpepplef13: ok, let's wrap up the meeting then.  Anything else we must discuss before calling it quits?
bpeppletopic FESCo meeting -- Free discussion around Fedora
going once.....
poelcatbpepple: change to bugzilla versions?
bpepplepoelcat: ok.
tibbsI 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
f13I move that we discuss the bug changes on list and instead of in the meeting right now
bpeppletibbs: I was going to suggest maybe having a separate meeting for them, but I'll move that discussion to the mailing list.
f13I would like to see some more input from other maintainers.
f13 fab
bpepplef13: I'm fine with that.  poelcat?
poelcatwhich list ? I already posted to devel and test?
tibbsI 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
c4chrisfor the rest, I think we shoud adjourn
wwoodsalpha and beta are rawhide snapshots
that's the message
I think that's simple enough.. right?
anyway, discuss further on-list
bpeppleok, so we're going to discuss further on-list, and vote on it next week.  Is everyone alright with that?
f13I am.
c4chrisbpepple: +1
f13poelcat: devel is fine, but you might echo to the internal equiv.
poelcatf13: okay
so we'll bring to a final vote next week?
bpepplepoelcat: yup.  I'll make it our first item next week.
poelcatbpepple: thanks
bpepplealright, let's call it quits for today.
* bpepple will end the meeting in 60
warrenI like that plan.
* bpepple will end the meeting in 30
poelcatf13: 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!