--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
* nirik will be here as long as the EVDO coverage lasts.
jwb is here
* abadger1999 grabs a seat in the bleachers
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* warren here
tibbs here
nirik is here
* jwb is here
* dwmw2 here
stickster here
bpeppleok, I see eight fesco members, so we can probably get started.
--- bpepple has changed the topic to: FESCO-Meeting -- Features - http://fedoraproject.org/wiki/Features/F10PolicyReview -- all
bpeppleLooks like there are four proposal regarding features we need to look at.
--- bpepple has changed the topic to: Features - Tracking Bugs - all
poelcatbpepple: maybe before starting check to see if there are any other things people feel need to be changed
poelcatif not that is fine... move on :)
that last bit seems odd to me
"Reducing FESCo overhead"
* poelcat just thought it best to collect the issues first and then discuss in order
jds2001id like to see plans in testopia - not just on the feature page
nottingjds2001: is testopia live for all to use, and won't have it's db wiped?
jwbpoelcat, that seems fine
jds2001notting: yeppers
jwbwe should probably do what bpepple and poelcat said and address them one at a time
notting'Firefox can't find the server at testopia.fedoraproject.org.'
tibbsSo, tracking bugs?
* notting saves more test comments for that entry
poelcatyes, first question is... does creating tracking bugs for each new feature make sense?
nottingone concern is whether tracking bugs or wiki is the proper place for discussion
tibbsIs it worth the additional overhead?
poelcatis it managable and useful?
jwbf13, ?
tibbsWho would be creating them?  The feature owners?  Don't they have enough process to work through?
jds2001if the feature is large it makes sense
jwbjds2001, why?
jds2001just for the sanity of the feature owner
jwbwhat does it buy you that the feature wiki page doesn't?
f13jwb: hrm?
jwb: visiblity in the F9-blocker but lists
jds2001but it would be at their discretion i guess
f13jwb: for lack of a better tool, we use bugzilla as a release management tool
jds2001ok, that makes sense too f13
f13and so being able to mark important bugs as blocking a feature that helps us to see what state features are in and what work needs to be done
jwbf13, i can buy that.  but if we do it via bugzilla, doing it in the wiki seems redundant
* nirik thinks tracking bugs are a good idea... then a feature won't be totally forgotten.
poelcatjwb: i'd create a tracking bug after the feature is accepted... everything else remains on the wiki
f13jwb: right, I'd say the wiki should just point to the tracker bug for any 'ongoing issues'
nirikthe wiki is better for documentation after release.
poelcatif bugs come in for that feature you block the tracker
jwbpoelcat, so the tracking bug is something that you would manage as the Feature Overlord?
poelcatjwb: i would see myself creating it... others would add to it, watch it, use it, etc.
f13triagers in particular could make use of it
jwbmy biggest concern is what tibbs alluded to.  feature owners have enough hoops
poelcatjwb: there is no hoop for the feature owner
jwbso as long as it isn't a burden to the feature owners, i'm cool with it
f13jwb: honestly I think it would /help/ feature owners keep track of bugs related to their feature
if I were a feature owner, I'd create my own tracker anyway
jwbf13, sure.  as long as we aren't keeping duplication information in multiple places, etc
bpeppleany other questions, or should we vote on this?
notting+1 from me
jwb+1 with the caveats i said
dwmw2+quote capab identify-msg :)
* dgilmore is here
bpeppleok, I count seven votes, so we'll use bug trackers for features.
--- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans
bpepple+1, seems like a reasonable request.
jds2001and for them being in testopia?
poelcatthe big issue to consider here is slowing down the process
i agree it is a good idea and would be useful
nirik+1 from me, it seems reasonable... do we have a testopia contact to point them at to help them with it?
poelcatbut what does the workflow look like?
f13jds2001: since testopia itself hasn't been fully accepted by FESCo that's putting the card in front of the horse a bit
notting+1 to have them, slight -1 for testopia
jds2001f13: ok :)
nottingfor example, testopia is still on a publictest instance, doesn't use FAS, etc.
f13IMHO the test case being in the feature page is fine by me
* jwb has no idea what testopia is
* bpepple only has a vague idea.
f13us testopia people could cut/paste it into testopia for our needs if necessary
nirikyeah, test plans good, implentation doesn't matter much to me.
jds2001im easily convinced that its too early :)
poelcatbut who makes the judgement call as to whether the test plan is sufficient and how I do know that so that I can put forward for fesco acceptance vote?
just so we all have clear expectations
nirikpoelcat: qa contact? or ?
f13poelcat: could we give QA a chance to mark in teh wiki if more/less is wanted?
f13I don't think it would block on getting the feature in, but it would give QA a chance/place to have back/forth with the feature owner
poelcatokay... so page is added to CategoryProposedF10--> get QA Review--> if good then to FESCo/ if not back to feature owner?
f13but maybe wwoods has a better diea.
nottingor just have a qa contact in the feature meeting who can sign off before vote?
poelcatthat is the tough part... it is easy to get people's help updating pages before they are accepted
f13so here is my opinion
wwoodsEither is good. Feature owners need to be aware that test plans are necessary for feature acceptance, though
f13I absolutely think we want a/better test cases for features.
poelcatafter they are "in" i have to usually try several sizes of hammers :)
f13however I don't necessarily think we need to make it a barrier to getting the feature accepted.
f13(but I'm willing to let others outvote me (:  )
wwoodsI disagree - if the feature owners won't tell us how to test the feature, how are we supposed to evaluate its readiness?
jds2001it should be a barrier imho
nottingwwoods: well, i can see the test plan being slight vague before feature-near-completeness
wwoods: but it still should be able to be described
wwoodssure, I'm OK with vague, but like. The entire point of the feature process is: "Here's what we're gonna do"
jds2001vague is fine - non-existant isnt (again imho)
wwoodsIf you can't also add: "Here's how to check to see if it's working as described"
bpepplealright, I see four '+1' to this proposal so far.  any other fesco members wish to vote?
wwoodsthen you're doing something wrong
f13wwoods: hrm, should there be a dual layer approval then?
jwbjds2001, FESCo is all about opinions.  you don't have to repeatedly state that it's your opinion :)
tibbsSorry, I keep getting called away.
jds2001should be fleshed out by feature freeeze id think
f13sort of one approval to even work on the feature, another to consider it "done" and not necessary to enact the rollback plan?
wwoodsf13: dual layer? like, loose requirements early on, tighter requirements post-freeze?
f13poelcat: do you think that's workable at all?
poelcathmm.. dual approval... how about rough test plan for acceptance
and by feature freeze solid test plan?
wwoodsyeah I don't need full IEEE test plans, but the first pass has to at least give me some suggestion on how to test the thing
f13the case I'm thinking of is a feature owner may just start working on something, and A) it's totally not testable, and B) it may not totally be clear how to test it yet, until the feature is more ready
poelcatIOW the QA team can do a review at feature freeze and kick back the ones that need more
f13poelcat: that would work for me
wwoodsQA (with help from feature owners) will want to write a F10 Feature Test Plan that includes multiple specific test cases for every new feature
so if I don't have enough info to write a simple test case - to tell someone *else* how to test your feature - then there'll be problems
so lets turn this into a votable proposal
Proposal: Minimum test case information necessary for feature acceptance. More robust test case necessary for completion acceptance at feature freeze.
(and we give QA the task of approving the test case status)
niriksounds good to me. +1 still.
f13+1 from me obviously
* wwoods sez +1, yeah
poelcatso if test cases are non-robust at feature freeze, feature could be proposed for de-listing if feature owner does not come through?
* poelcat just stating the obvious
f13that would be my interpretation.
poelcat: and QA should step up to offer to help feature owners in creating their test plans
* f13 throws QA under the bus
tibbsTest plans aren't generally that complicated, are they?
f13tibbs: depends on the feature
jds2001thats ok, f13 - we're used to it :)
poelcattibbs: is that a loaded question?
tibbsIf the feature is "Firefox 8", would "make sure firefox 8 installs, runs and visits a few web pages" be sufficient?
f13tibbs: You'd probably want something more extensive, involving firefox dependant packages, popular extension testing, etc..
tibbsThen they're complicated.
f13like I said, depends on the feature
wwoods"installs" isn't up to firefox.
tibbsIt's up to the packaging, which is tough to disengage from firefox itself in the context of Fedora.
But that's minor.
wwoods"runs" - define. Something closer to: "Click the firefox icon in the $WHATEVER menu. Firefox should start within ~30 seconds"
* poelcat thinks we should move on
wwoods"visits a few web pages" - define some web pages and expected results
bpepplewe've only got six '+1' to this proposal, as far as I can tell.
wwoodsbaseic test case = purpose, actions, expected results
but yes move on.
there's 7
bpeppleok, let's move on then.
--- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections
notting... "or other sections"?
poelcatbig picture, i'm asking that we collect a little more information for these sections in advance
tibbsI agree that it would be preferable to make sure the necessary info is there before things get to FESCo.
f13I'm OK with that
poelcati've been a little soft on this in the past
nottingi'm not sure release notes can reliably be written pre-approval
poelcatnotting: why not?
can at least take a stab at them
f13notting: information about the release notes could.
who would need to be addressed, what effect it has upon them in high level ideas
* poelcat is trying to move away from "doesn't need a release note" or "add stuff later" (which takes a lot of time to track down)
so what I'm looking for a vote/agreement on is that we tighten up needing to have some substance for documentation and release notes
spoti'm ok with that.
bpeppleOk, let's get a show of hands on this proposal then.
nottingyeah, sounds ok. when phrased that way
tibbsDo we need to define which fields on the form we require, or are you just asking for fesco approval for being tighter in vetting feature requests?
nirikseems fine to me. +1
poelcati'm proposing that all fields are rquired
dwmw2yeah, ok. +1
tibbsOK, +1
bpepplealright, I count seven "+1' so this proposal has been approved.
moving on...
--- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Reduce_FESCo_overhead
poelcatbpepple: i snuck one more in too
jwbi vote we not discuss this now
tibbsI think there's no need for this given the previous vote.
bpepplepoelcat: didn't see that.
--- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Reduce_FESCo_overhead
--- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Feedback_for_incomplete_feature_pages
jwbthat all seems fine to me
poelcatjust planning to add another section at the bottom of each page with the "Feature Wrangler's Review" for pages that aren't ready
tibbsActually, can't we use the discussion section?
f13I was just going to ask that
might not be obvious to people
f13since we now have mediawiki, the discussion tab seems perfect for this
tibbsI have always found interspersing comments into the text that's supposed to be reviewed to be counterproductive.
It makes diffs useless, for one.
jds2001maybe a template to refer to it is in order though
poelcattibbs: good point
let's try the "discussion" pages
warrenI forgot that we had discussion pages
should be useful
poelcatjds2001: already in the policy
jds2001awesome youre  a step ahead :)
poelcatjds2001: a blank template + a filled out example
jds2001no no
poelcatokay, that is all I have :)
thanks for your feedback and support
jds2001i mean like a box that syas "this feature is not complete, refer to the discussion page"
to draw attention to it
poelcatjds2001: okay
one other quick thing... sparks is going to be helping me wrangle the pages for F10
tibbsWho is sparks?
* stickster is the official Fedora Yenta... another love connection made.
bpeppletibbs: no idea.
poelcatEric Christensen
sticksterFellow Virginian, docs guy, security, etc....
bpeppleanything else on Features, or should we move on?
poelcatbpepple: thanks we're good
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleThat's it for the scheduled items.  Anyone has anything else they wish to discuss?
jwbwhen is the election again?
* dgilmore has nothing
dgilmorejwb: next week?
jwbdo we have enough to even hold an election?
bpeppleI believe it starts on the 15th, but I would have to check my email.
nirikwhen is nominations over?
tibbsI will be on vacation from July 16 until August 6, BTW.
sticksterWhere are the nominations kept?
we only have 8 nominations. we're electing 9 seats
tibbsI will most likely put my hat in the ring again.
jwbgood to see some of the outgoing Board members on there
bpeppleok, if there's nothing else I think we can wrap up for this week.
dgilmorejwb: and the botton 4 get 6 month terms
jwbdgilmore, what?
tibbsI would also like to start up a package review sig, but won't be able to start on it until after vacation.
dgilmorebottom 4 as far as number of votes
jwbtibbs, cool
spottibbs: excellent
jwbdgilmore, did we agree on that?
tibbsI think a sig is needed to coordinate improving the documentation,
dgilmoreor  did we decide not to stager things
jwbtibbs, agreed
dgilmorejwb: I thought so
poelcatwhen do abominations end?
bpepplejwb: we decided on that back in March I believe.
jwbok, i must have forgotten
tibbsand to get some proper flow between the packaging committee and the reviewers.
dgilmorejwb: so that there was not the chance of having all of fesco getting switched at once
bpepplejwb: It's in the election guidelines, which I asked people to review.
dgilmorebpepple: im not insane then :)
tibbsI love how our pages are still under Extras.
bpeppledgilmore: nope.
tibbsWell, some of them are.
jwbtibbs, there is a duplicate empty page under development too
not confusing at all...
* spot has to bail, thanks all
dgilmore need to get back to replacing windows
* bpepple will end the meeting in 60
jwbbpepple, not running again?
* bpepple will end the meeting in 30
bpepplejwb: I don't know yet if I want to or not.  I'll probably wait to the last second to make a decision.
* bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!