From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 2008-12-01
Fedora 11 Schedule
- Draft shedule agreed to by reelease engineering
- sending to FESCo for final approval at next meeting
- https://fedoraproject.org/wiki/Releases/11/Schedule
- desire to be stricter around freezes and tracking feature status
Other Plans for Fedora 11
- build out documentation so we can grow Release Engineering beyond current emembers
- signing server
- more automation around checkins and builds
Fedora 11 Naming
- f13 to check with Josh Boyer (jwb) on running the process
IRC Transcript
f13 | ping: notting jeremy rdieter_away spot lmacken poelcat wwoods warren | 10:00 |
---|---|---|
* notting is here | 10:00 | |
* lmacken | 10:00 | |
* warren here | 10:00 | |
jeremy | hi | 10:00 |
* poelcat here | 10:03 | |
f13 | oh sorry | 10:06 |
f13 | got distracted | 10:06 |
-!- f13 changed the topic of #fedora-meeting to: Fedora releng - F11 Schedule | 10:06 | |
f13 | .rel 843 | 10:06 |
zodbot | f13: #843 (Draft Fedora 11 Schedule) - Fedora Release Engineering - Trac - https://fedorahosted.org/rel-eng/ticket/843 | 10:06 |
* f13 wishes wwoods was here | 10:06 | |
notting | as i said in e-mail to poelcat, the latest proposal (http://poelstra.fedorapeople.org/schedules/f-11/f-11-draft.html) seems reasonable | 10:08 |
poelcat | f13: i'll make other wording changes you suggested in ticket | 10:09 |
f13 | I added a comment in the ticket about the tail end of the schedule | 10:09 |
* poelcat votes for "send it to FESCo!" | 10:09 | |
wwoods | PATCHOW | 10:09 |
f13 | wwoods had been talking about radical changes he'd like to see at the tail end too, but unfortunately he's not here | 10:09 |
* wwoods here now | 10:09 | |
f13 | OR IS HE!?! | 10:09 |
* wwoods appears in a poofy cloud of flour | 10:09 | |
f13 | ‽ | 10:10 |
wwoods | smokebombs smell funny. anyway: scheduling magic | 10:10 |
wwoods | There aren't any radical changes to the schedule per se - at least not against the version I'm looking at | 10:11 |
f13 | wwoods: I thought you were talking about doing away with Preview? | 10:12 |
wwoods | The only real change was to make the final freeze more final (and more frozen) by demanding final builds *before* then | 10:12 |
wwoods | emphasizing that by calling Preview "RC1" | 10:13 |
wwoods | and rejecting any features that wouldn't be fully complete by then | 10:13 |
wwoods | I don't think that's a *radical* change though | 10:14 |
f13 | so I'm with you on making the final freeze more strict | 10:14 |
f13 | and I think one way to do that is part of my suggestion, moving the RC compose date up to the 5th rather than the 12th | 10:15 |
wwoods | I'm undecided on renaming (since I doubt that Preview will actually be a viable RC) | 10:15 |
f13 | I'm not comfortable calling Preview an "RC" though | 10:15 |
wwoods | yeah | 10:15 |
warren | Perhaps we should create a RHEL-like exceptions process, and make Beta the point where we get more strict? | 10:15 |
f13 | unless we actually made it an RC | 10:15 |
f13 | beta is really really early to get like that | 10:15 |
warren | That might beat people to get stuff done long before the hard deadline of RC. | 10:15 |
f13 | and there is no way I'm going to support ack-flags and cvs blockage for Fedora | 10:16 |
wwoods | yeah we're not doing that. | 10:16 |
f13 | warren: currently we state that your features have to be /testable/ by Beta, not perfect | 10:16 |
warren | I wouldn't ever suggest cvs blockage | 10:16 |
f13 | we give you from beta to final freeze to fix your bugs found in testing | 10:16 |
notting | f13: the 5th? that's not in the trac ticket | 10:17 |
f13 | oops | 10:17 |
f13 | sorry, the 12th | 10:17 |
wwoods | we need a spec by Alpha and something that (mostly) meets spec by Beta. If it doesn't fully meet spec at the *freeze* for PR, it gets booted | 10:17 |
f13 | wwoods: I'd rather have the 'boot' date a week prior to final freeze | 10:18 |
wwoods | right - the FESCo meeting before each freeze decides what will actually make it into the release | 10:18 |
f13 | wwoods: that gives us a week to enact the contengency plan without having to do a bunch of tag requests | 10:18 |
wwoods | if something gets booted, it gets booted before we freeze, and then we freeze without it | 10:18 |
f13 | what days are fesco meetings? | 10:18 |
poelcat | f13: wed | 10:19 |
notting | wednesdays, ATM | 10:19 |
wwoods | and since freezes are on tuesdays, that means it's a week | 10:19 |
f13 | ok, so that's one day less than a week, but I can live with that | 10:19 |
wwoods | but yeah, just in case the meetings move or whatever, let's be clear - the fesco meeting the week *before* the freeze is the deadline | 10:20 |
wwoods | anything that's not meeting the requirements at that moment *will* be dropped | 10:21 |
f13 | s/dropped/will have the contengency plan enacted/ | 10:22 |
wwoods | (unless it's definitely 100% sure going to be ready before the freeze) | 10:22 |
f13 | of course this means we need to have valid contengency plans | 10:22 |
wwoods | yes - assume that "dropping" a feature means that we follow the contingency plan | 10:22 |
f13 | other than "wait longer" | 10:22 |
wwoods | sometimes the contingency plan is just "don't tag these packages" or "don't add to comps" or whatever | 10:23 |
warren | or "do nothing, just don't advertise it on the feature list" | 10:23 |
wwoods | right | 10:23 |
wwoods | "dropped" sounds a lot more harsh, I should try to avoid it | 10:23 |
wwoods | "deferred" might be a better choice | 10:24 |
f13 | wwoods: just to recap, there are no date changes you'd recommend for the schedule? | 10:26 |
wwoods | no, I think being stricter about what changes we allow is sufficient | 10:26 |
wwoods | a month in Final Freeze should be plenty, so long as we stick to the Final Freeziness of it | 10:27 |
f13 | sadly it's going to result in another 300+ 0-day update set | 10:28 |
f13 | ok, is there any other input on the schedule? | 10:29 |
wwoods | it would be nice if we had some subset of the distribution - some Core part of Fedora - that was subject to the stricter freeze requirements | 10:29 |
f13 | Proposal: accept poelcat's draft and push to FESCo for approval | 10:29 |
poelcat | +1 | 10:30 |
f13 | wwoods: I've seen that asked before, but where would you draw the line, how would you enforce it, and why couldn't we just do that anyway with what we accept/reject? | 10:30 |
notting | +1 | 10:30 |
spot | +1 | 10:30 |
f13 | (+1 to the proposal btw) | 10:30 |
f13 | warren: wwoods: jeremy: lmacken: rdieter_away: votes? | 10:32 |
lmacken | +1 | 10:32 |
wwoods | +1 | 10:32 |
f13 | well, I think that's enough to pass, so poelcat consider it passed. | 10:34 |
poelcat | f13: i'll forward to bpepple for inclusion on FESCo's agenda this wed | 10:34 |
f13 | ok. | 10:36 |
-!- f13 changed the topic of #fedora-meeting to: Fedora Releng - F11 plans | 10:36 | |
f13 | This should just be a quick braindump of what we'd like to work on for F11. | 10:36 |
f13 | I'd like to see the signing server take shap, mitr is working on that | 10:36 |
f13 | I'd like to start working on a messaging server as a communications medium for the basis of doing reactive QA testing | 10:37 |
f13 | (IE react to a cvs checkin, a package build, an update request, a rawhide push, etc...) | 10:37 |
f13 | I'd like to see an effort to gather up community ran scripts, fix them up as necessary for efficiency, conformity, and put them in the releng git, as well as setup scheduled runs of the scripts in Fedora infrastructure | 10:38 |
notting | scripts for...? | 10:38 |
f13 | I've got some bugs to fix in pungi, as well as helping out with a re-write of the anaconda compose scripts | 10:38 |
f13 | notting: there is broken deps checking, source url checking, conflicts checking, etc... | 10:39 |
f13 | many of these can eventually be turned into reactive tests as mentioned above, but in the meantime I think it would be worth getting these ran in some "official" capacity | 10:39 |
notting | i'd like to see more push-button release making, but i don't think i really have much time to work on it | 10:40 |
f13 | oh yeah | 10:40 |
f13 | documentation | 10:40 |
f13 | I'd like to borrow some docs writers time to help me and others beef up our documentation | 10:41 |
f13 | both from a SOP "how we do things" pov as well as a more maintainer appropriate "this is what we do and why" | 10:41 |
f13 | notting: push-button release making is going to be pretty hard | 10:42 |
f13 | but I can spend some time writing more scripts to do what I've been doing by hand | 10:43 |
f13 | it's just hard to script things across multiple systems | 10:43 |
f13 | ok, nobody else has any goals for F11? | 10:49 |
notting | 'ship it' | 10:49 |
poelcat | f13: was there anything left over from the F10 "things to do" ticket? | 10:50 |
f13 | poelcat: pardon? | 10:50 |
poelcat | didn't we have a ticket of F9 post mortem items for F10? | 10:51 |
f13 | yeah, they were kind of hand-wavy. | 10:52 |
f13 | I'll review the ticket and see if anything is still relevant or possible. | 10:52 |
jeremy | f13: while not an easy goal, it'd be nice to get more "outside" participation in rel-eng | 10:53 |
f13 | jeremy: yeah, I was hoping that our drive to bring in scripts would bring on some of the authors of those scripts to the team | 10:54 |
f13 | the first question to answer though is what would we want these people doing | 10:54 |
lfoppiano | hi | 10:55 |
jeremy | if we got to nirvana? actual building of release trees could move between people for various stages of the release and releases instead of it always being on your plate | 10:55 |
f13 | jeremy: yeah, that would be nice. I'm just worries about the traning and such aspect leading up to that | 10:57 |
f13 | I'd like to get more people looking after overall tree health and fixing things up there | 10:57 |
f13 | as well as script writing and such | 10:58 |
f13 | that could grow into more responsibility, and in many cases can be done without handing over sysadmin-releng rights | 10:58 |
* jeremy is unconvinced that tree health is really the "duty" of rel-eng... it ends up being done by people who happen to be in rel-eng just because we're suckers ;-) | 10:59 | |
f13 | well, sure I'd love to do less work, but then the work just wouldn't get done | 10:59 |
jeremy | but we have this very very large small-numbers (or arguably single) point of failure in terms of getting releases out, updates pushed, etc | 11:00 |
notting | first step is the aforementioned docs | 11:00 |
jeremy | notting: docs help. docs don't motivate people. | 11:01 |
notting | signing server also helps | 11:01 |
f13 | yeah, I'm painfully aware of the single point of failure | 11:01 |
notting | jeremy: it's the first step though. without docs, even motivated people are unable to help in many cases | 11:01 |
f13 | docs + people + trust = salvation | 11:02 |
jeremy | notting: motivated people can and will muddle through without docs. it's maybe not as fast or as efficient, but it's sometimes more fun for the do-er ;-) | 11:03 |
notting | jeremy: muddle through... to push updates? | 11:03 |
notting | (we're drifting off-topic) | 11:04 |
jeremy | notting: even there, yes. it starts with rough email that says this is basically what I do, you can figure it out | 11:04 |
f13 | I think each step is equally difficult | 11:04 |
f13 | starting with finding people who are A) motivated, and B) trustworthy, since right now you'd get keys to the castle | 11:04 |
jeremy | f13: now that there's separate keys per release and updates-testing, the keys to the castle are starting to be segregated | 11:05 |
f13 | to some extent | 11:05 |
notting | jeremy: if those you trust do something silly with the key, it's still a huge PITA | 11:06 |
jeremy | notting: and if those with access to any of the sysadmin groups do something silly with their ssh keys, it's still a huge PITA. | 11:06 |
* nirik would be happy to help push updates, but notes that there is a C) enough time in the day to do all the fun things out there to do. ;) | 11:06 | |
jeremy | we have got to get beyond the "oh dear god, the world could end!!!" mentality or we're always going to push people off and come up with excuses that we can't get more people really involved | 11:08 |
jeremy | anyway, </soapbox-that's-been-bugging-me-a-little-recently-and-needed-to-get-off-my-chest> :-) | 11:08 |
f13 | jeremy: I think it's a valid point, and something we should look at for F11 | 11:09 |
notting | jeremy: exactly, which is why we're pushing people off by ... documenting what we do so people can follow it, getting a signing server ready so we can automate more things/spread signing around, and... huh? | 11:10 |
jeremy | notting: except that we never get the time to actually *do any of those things* because the day to day sucks up all available time | 11:11 |
jeremy | we've been talking about working on the signing server "for the next release" for exactly how many releases now? | 11:11 |
notting | so, you're saying 'why make plans, we'll fail to execute on them?' | 11:12 |
notting | i really don't see what your angle is here | 11:12 |
f13 | jeremy: except this time we outsourced the signing server work to somebody who's explicitly tasked with doing it | 11:12 |
f13 | jeremy: and now we're getting results | 11:12 |
jeremy | notting: I'm saying planning for 28 hour days doesn't do anyone any good. you have to either a) just go ahead and start getting external people involved with the day to day to help make time for the other things, even if it's not the perfect situation or b) outsourcing some of the "new" things is also valid | 11:15 |
poelcat | how about starting with something as simple as tag requests? I see the tickets come in and would love to help from time to time | 11:16 |
poelcat | but there are no docs or simple guidelines on what to do | 11:16 |
jeremy | notting: my angle is that this meeting and this group is the same cabal it's always been. we've seen massive growth around people helping mmcgrath out with sysadmin-y tasks. we badly need to do the same with rel-eng if we're going to scale at all and not just burn all the candles at both ends | 11:17 |
poelcat | granted maybe you'd argue that is why I shouldn't help because what to do should be obvious :) | 11:17 |
jeremy | poelcat: there actually is some documentation of that one :-) | 11:17 |
jeremy | http://fedoraproject.org/wiki/ReleaseEngineering/SOP/BuildRootOverrides | 11:17 |
notting | jeremy: ... and i still state that the first step is *actually documenting what gets done*, because if someone working 28-hour days doesn't have time to do XYZ, they also don't have time to walk someone else through it when they're muddling along | 11:19 |
f13 | that's a lot of why sysadmin grew so much, they had good docs to cover what they did | 11:20 |
jeremy | f13: the docs came as a result of trusting for the best and giving some people some responsibility | 11:20 |
jeremy | because then there was time to write the docs | 11:20 |
f13 | ok, we're obviously going in circles here. We need both, we should shoot for both. | 11:21 |
f13 | jeremy: I'd love it if you would take up the task of trying to recruit more people in | 11:21 |
f13 | but we do have to ahve a better story for what they can do once interested. | 11:21 |
f13 | ... and I think a good target for that would be shepherding scripts into the rel-eng git tree and finding a place in infrastructure to run them. | 11:23 |
f13 | and ticket triage. | 11:23 |
f13 | we're horribly over time though, is there anything else for today's meeting? | 11:24 |
* jeremy has little to no thinking or breathing room for the next week or two. but will try to get something a little more fleshed out once he gets through this current stretch | 11:24 | |
f13 | ok. | 11:25 |
f13 | thanks all! | 11:25 |
* f13 has to jet for a bike ride before the weather sets in | 11:25 | |
notting | oh wait | 11:25 |
f13 | notting: hrm? | 11:25 |
* notting was going to ask about f11 names | 11:25 | |
f13 | oh yeah, forgot about that. | 11:25 |
f13 | that's still jwb's task, even though he's "not in releng" | 11:25 |
f13 | at least, I think he still wanted to run that | 11:26 |
f13 | I'll ping him next time I see him to get that going. | 11:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!