| --- 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 | ||
| bpepple | FESCo 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 | ||
| spot | here | |
| * jwb is here | ||
| * dwmw2 here | ||
| f13 | ||
| stickster here | ||
| stickster | (auditing) | |
| bpepple | ok, 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 | ||
| bpepple | Looks like there are four proposal regarding features we need to look at. | |
| --- bpepple has changed the topic to: Features - Tracking Bugs - all | ||
| poelcat | bpepple: maybe before starting check to see if there are any other things people feel need to be changed | |
| poelcat | if not that is fine... move on :) | |
| jwb | well | |
| 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 | ||
| jds2001 | id like to see plans in testopia - not just on the feature page | |
| notting | jds2001: is testopia live for all to use, and won't have it's db wiped? | |
| jwb | poelcat, that seems fine | |
| jds2001 | notting: yeppers | |
| jwb | we 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.' | |
| jds2001 | publictest2.fp.o/testopia | |
| tibbs | So, tracking bugs? | |
| * notting saves more test comments for that entry | ||
| poelcat | yes, first question is... does creating tracking bugs for each new feature make sense? | |
| notting | one concern is whether tracking bugs or wiki is the proper place for discussion | |
| tibbs | Is it worth the additional overhead? | |
| poelcat | is it managable and useful? | |
| jwb | f13, ? | |
| tibbs | Who would be creating them? The feature owners? Don't they have enough process to work through? | |
| jds2001 | if the feature is large it makes sense | |
| imho | ||
| jwb | jds2001, why? | |
| jds2001 | just for the sanity of the feature owner | |
| jwb | what does it buy you that the feature wiki page doesn't? | |
| f13 | jwb: hrm? | |
| jwb: visiblity in the F9-blocker but lists | ||
| jds2001 | but it would be at their discretion i guess | |
| f13 | jwb: for lack of a better tool, we use bugzilla as a release management tool | |
| jds2001 | ok, that makes sense too f13 | |
| f13 | and 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 | |
| jwb | f13, 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. | ||
| poelcat | jwb: i'd create a tracking bug after the feature is accepted... everything else remains on the wiki | |
| f13 | jwb: right, I'd say the wiki should just point to the tracker bug for any 'ongoing issues' | |
| nirik | the wiki is better for documentation after release. | |
| poelcat | if bugs come in for that feature you block the tracker | |
| jwb | poelcat, so the tracking bug is something that you would manage as the Feature Overlord? | |
| poelcat | jwb: i would see myself creating it... others would add to it, watch it, use it, etc. | |
| f13 | triagers in particular could make use of it | |
| jwb | my biggest concern is what tibbs alluded to. feature owners have enough hoops | |
| poelcat | jwb: there is no hoop for the feature owner | |
| jwb | so as long as it isn't a burden to the feature owners, i'm cool with it | |
| f13 | jwb: 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 | ||
| jwb | f13, sure. as long as we aren't keeping duplication information in multiple places, etc | |
| f13 | nod | |
| bpepple | any other questions, or should we vote on this? | |
| notting | +1 from me | |
| tibbs | +1 | |
| bpepple | +1 | |
| jwb | +1 with the caveats i said | |
| nirik | +1 | |
| dwmw2 | +1 | |
| f13 | +1 | |
| dwmw2 | +quote capab identify-msg :) | |
| * dgilmore is here | ||
| bpepple | ok, I count seven votes, so we'll use bug trackers for features. | |
| dgilmore | +1 | |
| --- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Better_Test_Plans | ||
| jwb | +1000 | |
| jds2001 | +20000 | |
| bpepple | +1, seems like a reasonable request. | |
| jds2001 | and for them being in testopia? | |
| poelcat | the 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? | |
| poelcat | but what does the workflow look like? | |
| f13 | jds2001: 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 | |
| jds2001 | f13: ok :) | |
| notting | for example, testopia is still on a publictest instance, doesn't use FAS, etc. | |
| f13 | IMHO 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. | ||
| f13 | us testopia people could cut/paste it into testopia for our needs if necessary | |
| nirik | yeah, test plans good, implentation doesn't matter much to me. | |
| jds2001 | im easily convinced that its too early :) | |
| stickster | https://publictest2.fedoraproject.org/testopia/ | |
| poelcat | but 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 | ||
| nirik | poelcat: qa contact? or ? | |
| f13 | poelcat: could we give QA a chance to mark in teh wiki if more/less is wanted? | |
| f13 | I 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 | |
| poelcat | okay... so page is added to CategoryProposedF10--> get QA Review--> if good then to FESCo/ if not back to feature owner? | |
| f13 | but maybe wwoods has a better diea. | |
| notting | or just have a qa contact in the feature meeting who can sign off before vote? | |
| poelcat | that is the tough part... it is easy to get people's help updating pages before they are accepted | |
| f13 | so here is my opinion | |
| wwoods | Either is good. Feature owners need to be aware that test plans are necessary for feature acceptance, though | |
| f13 | I absolutely think we want a/better test cases for features. | |
| poelcat | after they are "in" i have to usually try several sizes of hammers :) | |
| f13 | however 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 (: ) | |
| wwoods | I disagree - if the feature owners won't tell us how to test the feature, how are we supposed to evaluate its readiness? | |
| jds2001 | it should be a barrier imho | |
| jwb | testmb(); | |
| notting | wwoods: well, i can see the test plan being slight vague before feature-near-completeness | |
| wwoods: but it still should be able to be described | ||
| wwoods | sure, I'm OK with vague, but like. The entire point of the feature process is: "Here's what we're gonna do" | |
| jds2001 | vague is fine - non-existant isnt (again imho) | |
| wwoods | If you can't also add: "Here's how to check to see if it's working as described" | |
| bpepple | alright, I see four '+1' to this proposal so far. any other fesco members wish to vote? | |
| wwoods | then you're doing something wrong | |
| f13 | wwoods: hrm, should there be a dual layer approval then? | |
| jwb | jds2001, FESCo is all about opinions. you don't have to repeatedly state that it's your opinion :) | |
| tibbs | Sorry, I keep getting called away. | |
| jds2001 | should be fleshed out by feature freeeze id think | |
| f13 | sort of one approval to even work on the feature, another to consider it "done" and not necessary to enact the rollback plan? | |
| wwoods | f13: dual layer? like, loose requirements early on, tighter requirements post-freeze? | |
| yeah | ||
| jds2001 | bingo | |
| wwoods | sensible | |
| f13 | poelcat: do you think that's workable at all? | |
| poelcat | hmm.. dual approval... how about rough test plan for acceptance | |
| and by feature freeze solid test plan? | ||
| wwoods | yeah 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 | |
| f13 | the 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 | |
| poelcat | IOW the QA team can do a review at feature freeze and kick back the ones that need more | |
| f13 | poelcat: that would work for me | |
| wwoods | QA (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 | ||
| f13 | nod | |
| 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) | ||
| nirik | sounds good to me. +1 still. | |
| spot | +1 | |
| f13 | +1 from me obviously | |
| * wwoods sez +1, yeah | ||
| bpepple | +1 | |
| tibbs | +1 | |
| poelcat | so 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 | ||
| notting | +1 | |
| f13 | that 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 | ||
| tibbs | Test plans aren't generally that complicated, are they? | |
| f13 | tibbs: depends on the feature | |
| jds2001 | thats ok, f13 - we're used to it :) | |
| poelcat | tibbs: is that a loaded question? | |
| :) | ||
| tibbs | If the feature is "Firefox 8", would "make sure firefox 8 installs, runs and visits a few web pages" be sufficient? | |
| jwb | no | |
| f13 | tibbs: You'd probably want something more extensive, involving firefox dependant packages, popular extension testing, etc.. | |
| tibbs | Then they're complicated. | |
| f13 | like I said, depends on the feature | |
| wwoods | "installs" isn't up to firefox. | |
| tibbs | It'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 | ||
| jwb | yeah | |
| wwoods | "visits a few web pages" - define some web pages and expected results | |
| etc. | ||
| bpepple | we've only got six '+1' to this proposal, as far as I can tell. | |
| wwoods | baseic test case = purpose, actions, expected results | |
| but yes move on. | ||
| jwb | +1 | |
| there's 7 | ||
| bpepple | ok, let's move on then. | |
| poelcat | https://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections | |
| --- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Empty_Feature_Page_Sections | ||
| poelcat | ooops | |
| notting | ... "or other sections"? | |
| poelcat | big picture, i'm asking that we collect a little more information for these sections in advance | |
| tibbs | I agree that it would be preferable to make sure the necessary info is there before things get to FESCo. | |
| f13 | I'm OK with that | |
| poelcat | i've been a little soft on this in the past | |
| notting | i'm not sure release notes can reliably be written pre-approval | |
| poelcat | notting: why not? | |
| can at least take a stab at them | ||
| f13 | notting: 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) | ||
| poelcat | comment | |
| s | ||
| 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 | ||
| spot | i'm ok with that. | |
| bpepple | Ok, let's get a show of hands on this proposal then. | |
| +1 | ||
| spot | +1 | |
| notting | yeah, sounds ok. when phrased that way | |
| tibbs | Do 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? | |
| nirik | seems fine to me. +1 | |
| poelcat | i'm proposing that all fields are rquired | |
| dwmw2 | yeah, ok. +1 | |
| tibbs | OK, +1 | |
| jwb | +1 | |
| bpepple | alright, 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 | ||
| poelcat | bpepple: i snuck one more in too | |
| jwb | i vote we not discuss this now | |
| tibbs | I think there's no need for this given the previous vote. | |
| bpepple | poelcat: didn't see that. | |
| --- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Reduce_FESCo_overhead | ||
| bpepple | d'oh! | |
| --- bpepple has changed the topic to: Features: http://fedoraproject.org/wiki/Features/F10PolicyReview#Feedback_for_incomplete_feature_pages | ||
| jwb | that all seems fine to me | |
| poelcat | just planning to add another section at the bottom of each page with the "Feature Wrangler's Review" for pages that aren't ready | |
| tibbs | Actually, can't we use the discussion section? | |
| f13 | I was just going to ask that | |
| poelcat | could | |
| might not be obvious to people | ||
| f13 | since we now have mediawiki, the discussion tab seems perfect for this | |
| tibbs | I have always found interspersing comments into the text that's supposed to be reviewed to be counterproductive. | |
| It makes diffs useless, for one. | ||
| jds2001 | maybe a template to refer to it is in order though | |
| poelcat | tibbs: good point | |
| let's try the "discussion" pages | ||
| warren | I forgot that we had discussion pages | |
| should be useful | ||
| poelcat | jds2001: already in the policy | |
| jds2001 | awesome youre a step ahead :) | |
| poelcat | jds2001: a blank template + a filled out example | |
| jds2001 | no no | |
| poelcat | okay, that is all I have :) | |
| thanks for your feedback and support | ||
| jds2001 | i mean like a box that syas "this feature is not complete, refer to the discussion page" | |
| to draw attention to it | ||
| poelcat | jds2001: okay | |
| one other quick thing... sparks is going to be helping me wrangle the pages for F10 | ||
| f13 | rock | |
| tibbs | Who is sparks? | |
| * stickster is the official Fedora Yenta... another love connection made. | ||
| bpepple | tibbs: no idea. | |
| poelcat | Eric Christensen | |
| stickster | Fellow Virginian, docs guy, security, etc.... | |
| bpepple | anything else on Features, or should we move on? | |
| poelcat | bpepple: thanks we're good | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | That's it for the scheduled items. Anyone has anything else they wish to discuss? | |
| jwb | when is the election again? | |
| * dgilmore has nothing | ||
| dgilmore | jwb: next week? | |
| jwb | do we have enough to even hold an election? | |
| bpepple | I believe it starts on the 15th, but I would have to check my email. | |
| nirik | when is nominations over? | |
| tibbs | I will be on vacation from July 16 until August 6, BTW. | |
| bpepple | nirik:13th. | |
| stickster | Where are the nominations kept? | |
| jwb | http://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations | |
| we only have 8 nominations. we're electing 9 seats | ||
| tibbs | I will most likely put my hat in the ring again. | |
| jwb | good to see some of the outgoing Board members on there | |
| bpepple | ok, if there's nothing else I think we can wrap up for this week. | |
| dgilmore | jwb: and the botton 4 get 6 month terms | |
| jwb | dgilmore, what? | |
| tibbs | I would also like to start up a package review sig, but won't be able to start on it until after vacation. | |
| dgilmore | bottom 4 as far as number of votes | |
| jwb | tibbs, cool | |
| spot | tibbs: excellent | |
| jwb | dgilmore, did we agree on that? | |
| tibbs | I think a sig is needed to coordinate improving the documentation, | |
| dgilmore | or did we decide not to stager things | |
| jwb | tibbs, agreed | |
| dgilmore | jwb: I thought so | |
| poelcat | when do abominations end? | |
| bpepple | jwb: we decided on that back in March I believe. | |
| jwb | ok, i must have forgotten | |
| tibbs | and to get some proper flow between the packaging committee and the reviewers. | |
| dgilmore | jwb: so that there was not the chance of having all of fesco getting switched at once | |
| bpepple | jwb: It's in the election guidelines, which I asked people to review. | |
| dgilmore | bpepple: im not insane then :) | |
| tibbs | I love how our pages are still under Extras. | |
| bpepple | dgilmore: nope. | |
| tibbs | Well, some of them are. | |
| jwb | tibbs, 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 | ||
| jwb | bpepple, not running again? | |
| * bpepple will end the meeting in 30 | ||
| bpepple | jwb: 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!