From Fedora Project Wiki
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!