From Fedora Project Wiki

Revision as of 16:48, 23 May 2009 by Pfrields (talk | contribs) (moved Board/Meetings/2008-11-18 to Meetting:Board meeting 2008-11-18: Move to Meeting: namespace)

Fedora Project Board Meeting :: Tuesday 2008-11-18

  • Public IRC Meeting

Topics Discussed

  • With the announcement of a Fedora Server special interest group (SIG), Will Fedora have a server release?
  • What about a searchable Fedora knowledge base?
  • What progress is being made on the Fedora 11 and Fedora 12 schedule discussion?
  • What about creating a history of past release schedules?

IRC Transcript

@stickster All right, just intro'd in the public channel, mizmo will bring questions in here 11:06
+mizmo from ongolaBoy, we have "hi, i'd like to know if with the creation of the SIG/server, we'll have a fedora 'server' release ?" 11:07
@stickster Oh, good question! 11:07
+notting .... that's up to the SIG, if they want to do a spin, I would guess. 11:07
+notting unlike most SIGs, I doubt they'd do a live one. 11:07
+f13 also, we tried this once 11:08
+f13 the only thing a room full of server folks could agree upon was that you have to start minimal and work your way up 11:08
+f13 that's essentially the boot.iso/netinst.iso 11:08
@stickster notting: Actually, that's an interesting question... because if you set up a facility for logging to an external host it would be a really cool idea from the standpoint of a secure baseline. 11:08
+f13 It allows you to start with a local boot media + installer image, and everything else is pulled from the network, allowing you to pick only exactly what you ant. 11:08
+spoleeba would the appliance "feature" idea be aligned with future server sig..deliverables instead of a traditional iso? 11:08
+f13 so we essentially already have a "server" spin, and it's just the product of taking everything else away. 11:09
+notting stickster: baseline, yes. but the live images don't adapt so well to each image adding the 5 necessary server packages of their own, plus maintaining the updates long term 11:09
+h\h don't steal all the nifty SIG discussions and ideas :) 11:09
@stickster notting: True, although there is USB to think of... 11:09
+spot i think we should let the server SIG state their plans and intentions and not speak on their behalf. 11:10
+spoleeba i thought part of the appliance concept was partly for virtualization needs..which screams server sig to me 11:10
@stickster So I think the answer in summary is, "There's no compelling reason they *couldn't*" 11:10
+mdomsch we've talked about an @Server group in kickstart too that is a minimal package set 11:10
+mizmo is6s brings up, "The server SIG discussion and the excellent summary on FWN did bring up the need to somehow capture critical knowledge in some form more accessable than the HOWTOs" 11:10
+f13 I think the SIG has a lot of cool ideas and possiblities, like recipies (kickstart files) for various task sets, like a LAMP set, a messaging set, etc.. 11:10
+notting spot: agreed. although just for the record, due to timing there won't be one at F10 release even if they do decide to do sometihng 11:11
+spot yeah. 11:11
+spoleeba f13, wasnt there a summer intern who would on a website for a kickstart gallery like last summer or the year before? 11:11
@stickster We'll make it easier on mizmo from here on out, and declare when we're done pontificating on one topic 11:11
+f13 I doubt we'll be seeing binary download representations of these sets, mostly because server folks are incredibly fickle and incredibly adverse to anything "extra" being on the spin. 11:11
+h\h and the "live" kickstart CD :-) 11:11
@stickster mizmo: We'll hit is6s's question in just a moment 11:11
+spoleeba stickster, was that a question? 11:11
@stickster whops 11:11
+spoleeba stickster, it looks like a jeapordy "answer" in search of a "question" 11:12
+mizmo :) how about, "is there a form more accessible than HOWTOS where we can capture critical knowledge?" 11:12
+f13 mdomsch: what would @server be that isn't satisified by @core (+ @base if you're so inclined) 11:13
+f13 spoleeba: I don't recall seeing anything actually working. 11:13
+quaid you know, what intrigued me from the statements/discussion around a Server SIG was the thesis that Fedora has moved to being desktop focused. 11:13
+f13 so a form more accessible. 11:13
+mdomsch f13, assuming there are a set of 'servers always have foo' features; @core might be sufficient 11:13
+quaid yet Desktop people make the opposite argument ... 11:14
+f13 what about whitepapers for various "server" functionality. 11:14
+f13 published through the docs project? 11:14
+f13 although whitepapers can tend to be HOWTOs by a different name. 11:14
+spoleeba f13, no..not actually working...im just suggesting obliguely that there was an idea to pull out of the trash heap and repurpose 11:14
+spoleeba mizmo, ? 11:15
+quaid is the SIG format going to fix this perceived schism of server/desktop? 11:15
+spoleeba mizmo, is there.... you mean a knowledge base? 11:15
+spoleeba mizmo, where would we host that? 11:15
@stickster spoleeba: No answering questions with questions. 11:15
+spoleeba stickster, really? 11:15
+spoleeba stickster, all i do is ask questions 11:15
@stickster really :-) 11:15
+skvidal stickster: can we wish for more wishes? 11:15
@stickster Only you Seth. 11:15
* stickster cracks the whip 11:16
+mizmo spoleeba, when ideating, you shouldnt play devils advocate! 11:16
+f13 quaid: I think a server SIG can play a role in showing the community that Fedora cares more about just the Desktop, or is working on more than just the Desktop 11:16
+spoleeba mizmo, this is a Board meeting 11:16
+quaid spoleeba: we've discussed kbase, it would be a good thing, but we are short on resources compared to other needs/ 11:16
@stickster A knowledgebase has been discussed before in Docs, but it was never clear that it offered a huge return over a decent search engine run against any random base of content. 11:17
+f13 quaid: I don't think it'll ever "fix" the rift between the two factions, but debate and disagreement can often be healthy 11:17
@stickster f13: no it's not 11:17
+quaid f13: we've made great progress on making "both" possible that's for sure 11:17
+spoleeba stickster, i should check with luke about his community oriented codebase he's working on 11:17
* stickster is being silly, sorry. 11:17
+spoleeba stickster, ive a theory..that what we are talking about there...would help organize this sort of information as well...maybe 11:18
+mizmo from jds2001, "is the "knowledge base" not the wiki?" 11:18
@stickster I think Luke's idea is possibly more task-centric than knowledge-centric 11:18
+notting i'm not sure the wiki is the right platform for the publishing of howtos, whitepapers, etc. 11:18
+spoleeba stickster, i think it hasnt been exploded 11:18
@stickster But there is probably a great deal of flexibility in the new Fedora Community application that J5 and others have been collaborating on. 11:18
+spoleeba err explored 11:18
+notting also, if we're going down the kbase road, we want something that's a whole lot more searchable than the wiki currently is 11:18
+quaid current wiki search isn't that bad, it's the page naming that is the problem 11:19
@stickster notting: Right. There's a fundamental problem of quality assurance, which is why... take it away quaid.... 11:19
+spoleeba notting, well regardless of the implementation.. is that the underlying desire for somethng better than a collection of howtos 11:19
+quaid all of our pages are not searchable with WikiCaseNames; they are not in good categories; and the 11:19
+spoleeba notting, whatever its implemented as....searchability and making sure the relevant infornation is easier to find..is the crux issue 11:20
+quaid main namespace is full of stuff such as old Security Alerts 11:20
+f13 if it's not a howto, what is it? 11:20
+f13 what is it that people are wanting? 11:20
+quaid the only thing a wiki doesn't have really is a sense of workflow and ability to expire automatically by rules. 11:20
+spoleeba stickster, f13 asked a question!!!!!! 11:20
+quaid ... back to the original asker, I guess 11:20
@stickster spoleeba: He's been sick, he gets one free pass ;-) 11:20
@stickster I think one of the points is, almost all documentation concerns how to do something. 11:21
+spoleeba quaid, yes... how is the wiki not good enough.. that's the question 11:21
+quaid f13: I would say some of our stuff that is in a how-to could more better be a wizard, such as joining 11:21
* f13 is confused 11:21
+mizmo f13, is6s says that spoleeba is articulating his main concern here, "searchability and making sure the relevant infornation is easier to find..is the crux issue" 11:21
+f13 what's the difference between a howto and a wizard? Both guide you through a process no? 11:21
+f13 mizmo: ok, that's a much much more reasonable target. 11:21
+f13 Is there an effort underway to make our existing wiki content easier to find? 11:22
@stickster is6s: The way to improve that is to join the Documentation group and help us ensure the wiki pages are (1) appropriately titled, and (2) contain correct and timely content 11:22
+quaid f13: sort of; I'm thinking wizards that gather and store in databases, v. telling people how to walk through each page of FAS app and add it themselves. 11:22
+quaid f13: yes 11:22
+quaid f13: gitwikirename :) 11:22
+quaid we are renaming entire swathes of pages 11:22
+f13 there we go, is6s should get in contact with them 11:23
+quaid join fedora-wiki-list for collaborating 11:23
+quaid if you have a group that has a large # of pages on the wiki, you should be on that lis and discussing. 11:23
@stickster quaid++ ... fedora-wiki-list is a cross-team group for getting the wiki into fighting shape 11:23
+spoleeba quaid, can you give me a two sentence summary of the work being done? 11:23
+quaid sure 11:23
+spoleeba quaid, single syllable words if possible 11:23
+quaid 1. creating a set of pipe separate values files for major Subsections/ of the wiki (DocsProject.* etc.); then wikibot can rename and relink automagically. 11:24
+quaid 2. Help:Wiki_structure enforcing so people name new pages right, add them to smart categories and sub-cats, etc. 11:24
+quaid 3. Edumacation! 11:24
+quaid <eol> 11:24
+spoleeba actually... i saw a ubuntu planet blog entry that sort of speaks to this.... navigating web resources from a noob's pov 11:24
+spoleeba http://www.ndeschildre.net/2008/11/17/community-infrastructure-the-newbie-test/ without getting into his qualitative analysis..i think the methodology is interesting 11:25
+f13 I also think there is room for improvement with the wiki search tool itself 11:26
+quaid could be 11:26
+quaid I can't really test that with the way pages are right now 11:26
+f13 it doesn't seem to want to match substrings of a page title. Searching for "foo" doesn't match a page named "bar/foo" 11:26
@stickster We should take some hints from OpenSuSE for this. They have an excellent organization imho 11:26
+f13 which means it wouldn't find a page named "BarFoo" either 11:26
+quaid f13: pages shouldn't be nested, that's the way it is 11:26
+quaid yep, that's how MediaWiki works 11:26
+quaid it all works best when pages are named naturally with spaces. 11:27
+f13 quaid: nested or not, if I search for 'package' I'd expect to find a page named 'packages' 11:27
+spoleeba quaid, in our wiki, is there any way to associate pages which cut across categories? 11:27
+quaid e.g. "How_to_join_the_Docs_Project" v. "DocsProject/Join/How" 11:27
+f13 or at least an option to substring search 11:27
+ctyler case in point: search for FUDConF11 11:27
+f13 right, is that FUD_Con_F11 or FUDCon_F11 or F_U_D_Con_F11 ? 11:27
+quaid f13: I might agree that it should pull strings from within words, but in the MW world that would get 11:28
+quaid 'package' -> 'packager', 'packages', 'packaged', etc. 11:28
+spot can my bikeshed be green? 11:28
+quaid FUDCon is one name 11:28
@stickster f13: Yes, that's a good point. There's probably a resource issue for substring searches but we could ask websites to investigate it. 11:28
+skvidal spot: if it is british racing green 11:28
+quaid spot: funny but orthogonal 11:28
+skvidal spot: and not ANY OTHER SHADE OF GREEN 11:28
+f13 quaid: that's how searching works. If you search too generic, you get a lot of results that will help you narrow down your search term 11:28
@stickster These are good topics to bring up on the fedora wiki list 11:28
+quaid +1 11:29
+spot the intelligent solution is community tagging of content in a way that the search engine can find. 11:29
+spot not repainting/renaming/reabusing the limitations 11:29
+quaid is the MW method 11:29
+quaid spot: renaming is more than that, though 11:29
+quaid you can't l10n nested pages as well for example 11:29
+spot quaid: do you care what the name is if you find what you're seeking? 11:29
* ctyler thinks won't help find FUDConF11 11:29
+quaid again take the example of "How_to_join_the_Docs_Project" v. "DocsProject/Join/How" 11:30
+quaid ctyler: yes, it will, if that is added to FUDCon_F11 page 11:30
+spoleeba stickster, right so basically... people have a plan... they need help... now its time to shame the person who asked the question to dig in and help.. ill make that my goal for the next month 11:30
+mizmo spoleeba, no need for shame, he is actually already on the docs team 11:31
@stickster Well, shame-- but otherwise yes, there are plenty of useful tasks contributors can help with. 11:31
+spoleeba mizmo, oh..so..it was an astroturfing question...i applaud the effort 11:31
@stickster quaid: What are we waiting for wrt. the wikibot. 11:31
@stickster sorry, s/\./?/ 11:31
+quaid stickster: completion of files in gitwikirename 11:31
+quaid I added a column to add pages to 1+ categories, too 11:32
+quaid so we can get a ton of motion with just one set of renames/recats 11:32
+mizmo (got another question in the queue when you guys are ready for it .. ) 11:32
+quaid spot: there isn't a "Tag this page" tool in MW as it is, but I'll look in to that; it would be easier than "edit and add category" for sure 11:32
@stickster I think the Board should be tremendously interested in that initiative reaching fruition. 11:32
@stickster And that we should set a target, post-F10 release, for it to be completed. 11:32
+quaid "we" 11:33
+quaid ? 11:33
+quaid which we 11:33
@stickster we the wiki gardeners. 11:33
+quaid +1 then 11:33
@stickster I think mizmo has another question, shall we move on? 11:33
+notting ah, ok. don't think the board can realistically set a target w/o resources to direct 11:33
+spoleeba stickster, im willing to set a target.. as long as im not expected to do the work..thats more than fair 11:33
@stickster sorry, I was switching Board hat with Docs hat there. 11:33
+quaid -1 ;-) 11:33
+quaid that was for spoleeba :D 11:34
+quaid anyway, to summarize 11:34
+spoleeba stickster, how about.. we try to drive a recruitment effort to put resources into the hands of docs to mold 11:34
+quaid the wiki is a bit of a thorn in the shoe of our contributors and needs more resolution; it's being worked on via f-wiki-l; join and help. 11:34
+spoleeba quaid, is there potential here to run a post F10 "classroom" session specifically on this work..as a recruitment effort? 11:34
+quaid sure 11:34
+ctyler that would be a win 11:35
+quaid more than a few; I know ianweller would want to lead some, too 11:35
@stickster quaid: there are signups at fp.o/wiki/IRC/Classroom 11:35
+spoleeba quaid, okay..so how about we set a target date for that... and board members try to line that up via some arm twisting 11:35
+spoleeba quaid, we cant set a target for completion of the work..but we can try to set a target for a recruitment drive 11:35
+quaid stickster: anyone mind if i rename that page? ha ha 11:36
@stickster quaid: sure, go right ahead, there's an automatic redirect. 11:36
@stickster OK, let's move on 11:36
* quaid notes that page doesn't actually go anywhere 11:37
@stickster Sorry, https://fedoraproject.org/wiki/Communicate/IRC/Classroom 11:37
+mizmo okay our next question comes from diauq, "Q: ... caveat -- we know it is FESCo that sets the schedule for F11/F12, but recent discussions on f-a-b have shown an opinion split amongst people who are on the Board and are now or have been on FESCo, in other words ... the very people who need to reach a consensus. Is there any progress in thinking toward a consensus?" 11:37
+skvidal sounds to me like it is up to fesco 11:38
+skvidal not people who USED to be on fesco 11:38
+skvidal I may have bitched and moaned about the timing but if fesco says okay 11:38
* quaid rolls his eyes 11:38
+skvidal then it is fescos 11:38
+skvidal decision to make 11:38
+f13 yeah, this is FESCo's decision to make 11:38
+quaid so your answer is to reaffirm the caveat? 11:38
+f13 and it should be on the list for the next meeting. 11:38
+quaid I'm not asking for an answer 11:38
+notting f13: have you sent to bpepple for tomorrow? 11:38
+skvidal quaid: my answer is to say 'it's not our job unless it is deeply screwed' 11:39
+quaid ok, see 11:39
+f13 FESCo has the responsibility to take input from their constituants as the basis of their decision making process, but ultimately we elected them to make decisions for us. 11:39
+quaid that diauq dude isn't asking the Board to make some decisions. 11:39
+f13 notting: I need to confirm it's on the list. 11:39
+skvidal quaid: he's asking for a status report to a group of people who don't have that info atm 11:39
+spoleeba im good at status reports... F11 will be released in 2012 11:40
+quaid can This Community have a consensus around that issue? 11:40
+f13 define "This Community" 11:40
+skvidal it's about fesco's consenseu 11:40
+skvidal err consensus 11:40
+quaid Fedora Project 11:40
+spoleeba quaid, some decisions require time sensitive judgement..and not consensous...release schedules are one of those things... 11:40
+quaid if there was nothing there to discuss, then why did it get to f-a-b etc.? 11:41
+skvidal quaid: it was cc'd a couple of places I think 11:41
@stickster It's important not to mistake a few thoughtful but disagreeing voices for a lack of consensus. 11:41
+spoleeba quaid, because fab is the only list where we can hold a public feedback discussion really 11:41
@stickster Right. 11:41
+f13 there is something to discuss, just like with almost every other FESCo topic 11:41
+spoleeba quaid, even if it comes down to a vote.. if fesco wants feedback...fab the place for it 11:41
+f13 and it's better to have some discussion in public before a short meeting to decide an issue. 11:41
@stickster The schedule discussion started quite a while ago in the rel-eng group 11:41
+f13 it has been the desire of many community folks that FESCo issues are posted for public discussion well prior to a meeting 11:42
@stickster f13 was trying to bring some solidity to the discussions and make sure it was seen by a larger group. 11:42
@stickster And we should also recognize John Poelstra who did a lot of work drafting and presenting different schedules as well. 11:42
+f13 also, I think it's very unrealistic to expect total consensus on every item from every community member. 11:42
+spoleeba quaid, so even if there isnt consensous..and the public discussion is contentious..its not bad to have it 11:42
+quaid hmm ... seems like "are we time based or feature based" is a pretty important discussion, and when you decide "time bsaed" 11:43
+quaid is it "passage of time or adherence to calendar" is also pretty fundamental. 11:43
+f13 and it depends on external factors too 11:43
+f13 I've always maintained that we have a hybrid schedule, that is both time and feature based. 11:43
+f13 We set a time to get a release done, then decide on a set of features that we should be able to complete within that time. 11:44
+f13 but we have and will adjust schedule according to feature status 11:44
+f13 so we're both time based, and feature based 11:44
+quaid true dat 11:44
+mdomsch likewise, we adjust features due to schedule status 11:45
+quaid well that's wonderfully clear for people outside 11:46
+mdomsch I thought rel-eng put forward a good argument 11:46
+mdomsch for their schedule proposal 11:46
+ctyler Yes, I thought it was well thought out too. 11:46
+ctyler In the big picture we have consensus on a roughly-six-month pace, we're talking about tweaks. 11:46
+quaid "We release at a specific time, but may bump that if some features are not ready, but you cannot know which features are going to be considered important enough to warrant a slip, and sometimes the calendar matters more than the length of the release cycle." 11:46
+quaid at the very least, can we have a field for Features that identifies them as blockers or not from the start? 11:47
+f13 sounds pretty terrible to somebody externally trying to plan around a Fedora release (: 11:47
+mdomsch quaid: count on your feature _not_ getting in, and be pleasantly surprised when it make the Gold discs 11:47
+quaid s/can/do/ ? 11:47
@stickster I think assigning a different date, and slipping a date, are kind of getting mixed up in quaid's summary there. 11:47
+quaid mdomsch: oh, yeah, I can sell that one to ISVs, for sure 11:48
+f13 quaid: erm, I thought that all features are "blockers" once they've been accepted, until such time that they are thrown out and the contengency plan is enacted. 11:48
+mdomsch quaid: welcome to my world :-) 11:48
+quaid stickster: sure, and that's the point; how clear is this to new contributors? 11:48
* mdomsch _is_ really an optimist 11:48
+spoleeba quaid, awesome..so if i convince someone my feature is really really important..they can tap it as a blocker at the beginning of a devel cycle..and i can sit on my hands and make releng push back the release repeatedly to accomidate me 11:48
+quaid spoleeba: opposite 11:48
+f13 so maybe to reword this a bit 11:48
+quaid spoleeba: the spotlight then is on blockers to get done v. making schedules slip 11:49
+f13 we're time based, we plan features based on those times, expect features to hit our schedule dates, but will slip for bugs. 11:49
+quaid spoleeba: then we know where to pour or restrain resources, etc. 11:49
+spoleeba quaid, perhaps its best to leave it squishy...so decisions get put off so the people who are making effort and deserve a little extra time..get it 11:49
+spoleeba quaid, you dotn know at the beginning which feature owners are going to make a best effort 11:49
+notting .... i'm confused. we earlier said that fesco was going to discuss and determine the schedule, and now we're all pontificating on ... what exactly? 11:49
+spoleeba notting, nothing 11:50
+skvidal notting: good question :) 11:50
+mdomsch seinfeld 11:50
+quaid notting: something that matters to the Board 11:50
+quaid new contributors being unable to fathom wtf our schedule is all about 11:50
+quaid let me put it another way: 11:50
+ctyler s/Board/the whole project/ 11:50
+quaid who decides if Fedora is a time-by-passage-of-time, time-by-calendar, feature-driven, or blend? 11:50
+quaid is that FESCo? 11:50
+quaid or the Board? 11:50
+quaid ctyler: yes, but the Board represents who? the entire project 11:51
+f13 quaid: ultimately it's the FPL that decides that 11:51
@stickster The way I look at it is this: 11:51
@stickster The Fedora Project is more than just the distribution we issue. 11:51
@stickster We're not a product, we're a project. 11:51
@stickster If we were product-centric, we would likely institute a lot stronger and definitive timelines for everything 11:52
+mizmo (we have another question in the queue when you're ready ) 11:52
@stickster We are always looking to maximize stickiness for contribution, whencever that arises. 11:52
+mdomsch question: do we have "priorities" assigned to different features? 11:52
@stickster Sometimes to do that we have to look at issues beyond a rigorous calendar date. 11:52
+f13 mdomsch: not enumerated in any way. 11:53
+quaid I maintain that the calendar thing was put on _after_ the six month thing 11:53
@stickster mdomsch: Do you mean like a weighting? I don't think so. 11:53
+quaid and while six months is proven, I'm not yet convinced that the calendar is 11:53
+spoleeba mdomsch, what would that get us? We dont exactly have abstract resources which we can move from one feature to another 11:54
+f13 mdomsch: that somewhat happens naturally based on what the feature is, how many things it touches, and how big of a boulder it is rolling behind you as you try to run out of the ruins. 11:54
+spoleeba mdomsch, features are bottom up.. the feature owners drive them...we cant re-assign resources to high priorities 11:54
+notting i'm not sure what particular features have to do with this 5 vs. 6 month cycle discussion 11:54
+f13 spoleeba: we can however more easily "throw out" some features 11:54
+mdomsch so all features are 'nice 1' priority 11:55
+spoleeba f13, sure...but isnt that a late in the game decision..based on how far that feature has come? 11:55
+f13 spoleeba: while other are quite difficult to throw out without incurring just as much of a delay as we would have in waiting for the bugs to get fixed. 11:55
+mdomsch if they get done, great, otherwise, not 11:55
+quaid notting: it does if features drive slips of that calendar, thereby causing 5 v. 6 discussions 11:55
+ctyler notting: the question is what features you might slip for, and which ones you don't 11:55
+mdomsch ctyler, exactly 11:55
+f13 ctyler: and the answer to that is "it depends" 11:55
+f13 sadly. 11:55
+ctyler right 11:56
+spoleeba f13, whether to through a specific feature out..is an intrisic assessment of that feature's scope and complexity..its not ranked ordered to another feature 11:56
+quaid it just seems odd that we have a big drum to beat, and one little drummer can mess up the whole riddim for YEARS 11:56
+notting i'm not sure we've ever slipped for any particular feature more than 'aaargh, broken' 11:56
+quaid either we need to recognize that each drummer matters (features) or the beat matters (passage of time), and I don't get where adherence to a strict calendar helps either of those. 11:56
+f13 quaid: I think the only features we've ever interrupted the schedule for were big drum features, not little ones 11:56
+quaid f13: ok, fair 11:56
+f13 quaid: and it was cases where throwing the feature out would have incurred a /longer/ delay than waiting for the feature to be fixed. 11:57
+ctyler f13: that's the dividing line right there 11:57
+f13 quaid: often there is a point of no return on features, and we just have to accept that when we've reached that point, we may have to delay 11:57
+quaid f13: maybe that's a basis for identifying higher-value features; discarding them costs more than delaying for them. 11:57
+mdomsch s/discarding/postponing/ 11:57
+quaid s/value/blocker/ might be a better way to say that 11:58
+quaid ok both changes :) 11:58
+f13 is this something we're going to want to incorporate into the F11 feature process? 11:58
+f13 if so, I think poelcat would like to know about it sooner, rather than later. 11:59
+spoleeba f13, go or no go....if that point exists for feature...that should try to be identified so the feature inclusion process that fesco is involved with can sync with that point in the feature development 11:59
@stickster Especially since the feature process has (I believe) already begun for Fedora 11. 11:59
+quaid spoleeba: on your point about assigning resources 12:00
+quaid I'd like to personally be able to know where and when to apply to help to keep a schedule from slipping 12:00
+quaid usually when the ubiquitous we hears about it, it's too late to help. 12:00
* quaid doesn't need to keep beatin' this hoss 12:01
+quaid but I don't think we should fool ourselves 12:01
+quaid in to thinking that there isn't a fundamental "what is Fedora" question in here 12:01
+f13 we've drifted quite a bit, is there a summary of what we've been discussing, or any action items to take away? 12:01
* stickster was looking in buffer asking himself the same. 12:02
+quaid that the Board is not answering by saying, "this one time schedule change thing is FESCos, let's move on." 12:02
+skvidal do we have more questions? 12:03
@stickster Would we like to pick out something we can concentrate on, like how to rate the blocker-ness of features at a particular point in the release cycle? 12:03
@stickster (or a point determined by the feature itself) 12:03
+quaid Action Item: can FESCo consider the value of assigning blocker levels to features to give earlier warning of potentially blocking features where bugs might cause schedule slip? 12:03
+quaid stickster: for your q, I don't think that's really Board stuff. 12:04
@stickster quaid: You just said what I wanted to say, only you said it correctly. 12:04
+quaid Board is, "The schedule keeps slipping, we cannot find a way to help prevent that, what are you (FESCO, Releng) doing to help the rest of the community do our jobs of helping?" 12:04
+spoleeba quaid, let me put it this way... i think its inappropriate to pick winning and losing features at the beginning of the Featuring process. By setting priorities early you are delibrately saying sorry Feature Y owner..it doesnt matter that you've been kicking ass and doing your job to drive your feature forward responsibly for months and now need a little help...we decided that this other feature over here with the deadbeat feature driver is way mo 12:04
+spoleeba re important 12:04
+spoleeba quaid, i think thats fundamentally wrong 12:04
@stickster I didn't mean the Board should be taking the issue on, but that we should ask FESCo to look at that. 12:04
+quaid spoleeba: oit 12:05
+quaid spoleeba: it's not priority 12:05
+quaid it's how far a feature reaches in and can mess up the schedule 12:05
+quaid for example, the Transifex feature did not have l10n dependent on it for that release, so it's arrival or not did not impact the schedule. 12:05
+quaid Plymouth? pretty far reaching, etc. 12:06
+quaid it's not some way for people to slack by proxy. 12:06
* poelcat can't recall an incomplete feature that has "messed up the schedule" 12:06
+ctyler number of tentacles and strength of their grip, not value of the feature 12:06
+spoleeba quaid, so its a matter of milestoning inside the release.... at what point in the feature's development does it become release schedule critical 12:06
+f13 poelcat: networkmanager caused late slips for F9 or F8 did it not? 12:07
+quaid for example ... if there are features where bugs are going to block the release, are we getting enough focus on testing those features above others? 12:07
+spoleeba quaid, that point must be gotten to early ennough...or its grounds for punting on review 12:07
+quaid spoleeba: yeah, something like that; some might get punted earlier, therefore, if continuing with them is going to risk the schedule too much, etc. 12:07
+f13 quaid: I think that's a fair question, and from releng I have an answer to that. Is this something we want to discuss now? 12:07
+poelcat f13: fair enough... i kind of think that is the only one... and it would have blocked the release even if it didn't have a feature page 12:07
@stickster I think we've solidified that there's a question worth asking. 12:07
+quaid also, there *are* features where e.g. RHEL engineering could be hit up for help to get through bugs, if we can identify to tburke that it's needed. 12:08
@stickster quaid: I think further discussion here is something we should do on f-devel-l. 12:08
@stickster Where more actual developers can chime in. 12:08
+quaid ok! 12:08
+spoleeba quaid, most assuredly we can persuade...but we dont manage enough engineering resourced directly..there is a difference 12:08
@stickster Hoss, you are hereby released. 12:08
+notting stickster: i'm not seeing how that's relevant to the initial query about this particular schedule discussion, though 12:09
+quaid spoleeba: yes, but that doesn't absolve us from trying, and we need the ammunition to try. 12:09
@stickster The original question was about consensus, and we've wandered into the fact that our schedule slips. 12:09
@stickster mizmo: Anything left in the queue at this poitn? 12:10
@stickster *point, even 12:10
+mizmo stickster, nope 12:11
+f13 there should be at least one 12:11
+mizmo f13, no that wasn't a real question 12:11
+mizmo and i thought it was 12:11
+f13 ah 12:11
@stickster OK, it seems like there's a lurking question we haven't answered that's too inefficient for IRC, which is, "What is the proper way to acquaint new contributors with how our schedule works?" 12:12
@stickster Maybe we should cobble that out through email 12:12
+spoleeba our schedule works? 12:12
+f13 brb 12:12
@stickster "the Fedora release schedule works" 12:12
+notting stickster: i always thought it was '6 months, adjusted for slips, with an attempt to sync around mayday/halloween) 12:13
@stickster Sorry, I didn't realize there was another schedule we were talking about over the last 30 minutes. 12:13
+quaid notting: in other words ... don't book travel or make plans until the last three weeks? 12:14
@stickster notting: That's how I've thought about it too. If we can't get more specific, we should note why somewhere that people can read it. 12:14
+spoleeba notting, i purposely try to find a way to introduce enough slips in the spring release so it falls on my birthday... 12:15
@stickster OK, if there's nothing further... mizmo? 12:16
+mizmo stickster, we got another one 12:16
+mizmo from joropo, " could a history of past releases schedules be developed? Rather that pontificate upon what *should* happen, can we gat a view of how things unfolded before?" 12:16
@stickster I believe someone's done that on one of the lists... 12:17
+mdomsch poelcat provided some of that already 12:17
@stickster I don't have a URL handy but I think it might have been either John or Bill 12:17
+notting wasn't me 12:17
+mizmo nothing else in the question queue after that 12:18
+poelcat https://fedoraproject.org/wiki/Releases/HistoricalSchedules 12:18
+notting quaid: i think we're fairly clear months in advance (modulo big explosions). might be worth comparing to ubuntu. i don't think 'big' companies (msft, even red hat with RHEL) are valid comparisons, as they're not working on the same cycles 12:18
+poelcat https://fedoraproject.org/wiki/Releases 12:18
+spoleeba poelcat im sure answeed this in the fab thread...in response to me asking about that historical trends 12:18
+quaid notting: that is not the feedback we get most releases from Ambassadors trying to plan release parties, for example 12:18
@stickster Yes, he did -- Nov. 13th 12:18
+notting poelcat: does that describe the schedule moves from the planned dates? 12:19
+poelcat https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00074.html 12:19
+poelcat notting: nope... nobody tracked it before I started 12:19
+poelcat doing it w/ taskjuggler 12:19
+quaid if it mattered, we could figure it out to some level of accuracy 12:20
+notting quaid: yeah, we can probably do wikimining 12:20
@stickster OK, I think in fairness to our moderator we should close up shop here. We can continue talking if anyone would like. 12:21
+quaid if we continue, over on #-public 12:22
@stickster quaid: Right 12:22
@stickster Adjourn? 12:22
+f13 One comment 12:23
+f13 re the history of schedules 12:23
+f13 Every release is unique, and each release faces it's own pressures and difficulties. 12:23
+f13 the result of one release can't necessarily be compared to the result of another, especially when things like the break in happen, or a move to an external build system 12:23
+f13 the constants between releases outside of these events have been somewhat identified, and we've attempted over the releases to introduce new methods of avoiding common scenarios 12:24
+f13 I"d like to think that we improve a little bit each time, uncovering layer upon layer of what causes delays, attaching each layer as we get to it. 12:25
+f13 so while the net result of "we slipped a week" still may happen, it's certainly not for the same reasons. 12:25
+f13 (except for when it is and our experiments failed) 12:25
+f13 that's all I have. 12:25
@stickster OK, so noted f13 :-) 12:27
@stickster And thanks again to John and you for trying to bring clarity to the F11 schedule given our F10 calendar 12:27
* notting has to disappear 12:28
@stickster Thanks guys 12:28
@stickster Anyone wanting to stick around can come to #fedora-board-public 12:28
@stickster </meeting> 12:28

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