ReleaseEngineering/Meetings/2007-nov-12

Fedora Release Engineering Meeting :: Monday 2007-11-12

Schedule Review

• http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html
• Make sure no collisions with holidays
• Next proposed FUDCon: January 11-13, 2008, at Red Hat HQ in Raleigh
• http://gregdek.livejournal.com/17724.html
• Need to have other teams review: FESCo, Docs, translation team, QA
• Change Alpha Freeze to Jan. 15, Alpha release Jan. 24

F9 Tasks & Targets

• Fill out Trac tickets for things that need to get done
• https://hosted.fedoraproject.org/projects/rel-eng/
• Python scripts that can take email as input and create Trac tickets from them
• use rel-eng@fedoraproject.org as Trac input.

DECISIONS:

• continue move to Trac for task management
• work toward turning rel-eng@fp.o into a Trac ticket gateway
• create an invite only or otherwise moderated mailing list for rel-eng discussion/voting

Ideas for Goals for F9 Release

• brainstorm before next week's meeting to figure out what we want to do for this release outside the typical make bits show up stuff
• send preferably by Friday so we can digest it over the weekend.
• wwoods: http://fedoraproject.org/wiki/ReleaseEngineering/Overview
• notting
• signing server
• potentially the big multilib change--i need to get some stuff written down for that
• kill the buildroot overrides stuff
• wwoods
• bodhi depchecking!
• PPC as the trailblazer secondary arch
• f13
• signing server
• complete the s/development/rawhide/ changes.
• post-build processing--running rpmlint and other such things.
• jigdo support
• dealing with rawhide late in the cycle so that we have two nightly trees
• composes in Colo for F9
• warren
• delta rpm and presto by default
• jeremy
• less involvement
• need help spinning live images

Fedora CD Releases

• The board has asked that we produce split CD media once again.
• Release Engineering has not fully agreed, though have it would be possible
• really just a matter of time and space, yes?
• warren: can't upgrade with live images.
• would increase number of test targets
• affects on Release Engineering are more of the following:
• compose time
• validation time
• sync time
• disc space used

Meeting Time

• Going forward (starting with next week) we will meet at 1800 UTC (1300 EST)

Fedora 8 Jigdo Data from Fedora Unity

• 600 downloads of the .jigdo file
• 400 downloads of the CD1 template
• thus so 200 or so users did not know where to get started with jigdo or did not start yet.
• thought to be useful to people that cannot do network installs
• if we can look at what packages are on what CD and what CD other than 1 is most popular that might make for some interesting analysis

IRC Transcript

f13	notting: wwoods: warren: jwb: jeremy: spot: rdieter: poelcat: ping	13:03
wwoods	hi!	13:04
notting	it's like i never left!	13:04
* poelcat here		13:04
rdieter	here	13:04
* warren here		13:04
* jeremy is here at least sort of		13:07
f13	ok.	13:08
f13	http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html	13:08
f13	please review, I'd like to give John the thumbs up from our end.	13:08
notting	we're going to have the release scoped in 10 days?	13:08
f13	poelcat: nothing changed since I gave you the thumbs up this weekend right?	13:08
poelcat	f13: correct	13:09
f13	notting: suppose that depends on what "scope" means	13:09
f13	since our feature review is open far longer than the scope period	13:09
poelcat	notting: yeah, that was kind of place holder for "let's do *some* planning " :)	13:09
warren	looks a lot like RHEL	13:09
warren	=)	13:09
poelcat	i know fedora board is talking about overall things they would like to see	13:10
poelcat	so that kind of fits in	13:10
poelcat	warren: nothing like it ;-)	13:10
poelcat	ours is better :)	13:10
notting	if so, the taskjuggler bars should be blue, not red~	13:10
warren	Yeah, RHEL is just a cheap knock-off spin	13:10
f13	ours is achievable.	13:11
notting	can we put RHEL on spins.fp.o?	13:11
f13	LOL	13:11
warren	hah	13:11
poelcat	LOL	13:11
wwoods	their packages are all old and crusty	13:11
wwoods	they barely update them at all	13:11
warren	and no excitement	13:11
wwoods	and ugh, that color scheme	13:11
wwoods	so red!	13:11
wwoods	I mean, at least it's not brown, but still	13:11
warren	There is currently a flamewar going on at <that project> about moving away from brown.	13:12
notting	obviously we should switch to a green theme. it's the in thing!	13:12
wwoods	but their entire identity is tied up in the brownness! there is none more brown!	13:13
f13	poelcat: one thing I didn't look at was the mash up of any holidays	13:13
wwoods	(this idle chitchat is me stalling while I read through the schedule)	13:13
f13	poelcat: I don't /think/ we have any significant dates falling on holidays, did you check that?	13:13
notting	wwoods: they wear brown coats? explains the rabid online fans.	13:13
poelcat	f13: i don't believe there are any... but TJ can schedule around them	13:13
f13	k	13:13
* poelcat will look into it		13:13
warren	notting, is the new multilib plugin going to happen for F9?	13:13
jeremy	alpha freeze is likely to be "interesting" as the first work-week post the holidays	13:13
notting	warren: REPLY HAZY. ASK AGAIN LATER.	13:14
rdieter	multilib plugin?	13:14
wwoods	I'm going to be gone during the first week of April I think	13:14
f13	rdieter: doing away with the idea of pre-defining what is or isn't multilib at compose time, and instead do it at run time, based on local policy, on the client.	13:15
rdieter	wee!	13:15
wwoods	actually 7-12. which coincides with PR1.	13:15
warren	I don't get back until January 8th	13:15
wwoods	oh man, having a "i386 compatibility" checkbox in the installer/yum config would be just awesome	13:16
rdieter	welcome aboard, capt awesome. :)	13:17
warren	good friends with captain obvious	13:17
f13	wwoods: having composes that don't take 14 hours would be awesome too	13:17
wwoods	all aboard the H.M.S. whupass! SET SAIL FOR RADNESS!!	13:17
wwoods	f13: roger that	13:17
rdieter	*cough* 14 hours! ouchie.	13:17
wwoods	so yeah, I'll have to get someone to fill in as QA Lead for PR1	13:18
poelcat	wwoods:  and a free bottle of awesome sauce?	13:18
wwoods	but given 5 months to do so, I think that'll be OK	13:18
warren	Could we possibly push back Alpha freeze by a week?	13:18
wwoods	well, it's a non-blocking ("honor system") freeze	13:19
f13	warren: which direction is "back", and why?	13:19
wwoods	so the first week could just be a polite request to skip non-essential builds	13:19
warren	"Please don't cause new breakage."	13:20
wwoods	and subsequent weeks the request becomes less polite?	13:20
warren	f13, 1/8 seems to be too early, especially with many people returning from holidays	13:20
f13	if you mean make it a week later, ditto the release of Alpha1, I'm OK with that, without adjusting other schedules.	13:20
warren	yes, htat	13:21
f13	note that during the holidays is when a lot of our maintainers actually have /time/ to do Fedora stuff	13:21
f13	it's just the paid shills that stop work	13:21
warren	I did lots of work during last holidays	13:21
wwoods	does it make sense to move the release a week later and leave the freeze where it is?	13:22
f13	I would be board out of my mind if I didn't do work.	13:22
f13	wwoods: no, because then we wouldn't get all those fun builds which would actually be worth testing.	13:22
warren	wwoods, if honor system freeze, i guess so.	13:22
warren	f13, oh	13:22
f13	wwoods: if we're worried about new stuff landing due to holiday hackfests, we should include that in the Alpha	13:23
wwoods	true	13:23
wwoods	and the alpha is already 3 weeks longer than the beta	13:23
warren	push back freeze and release by a week	13:23
warren	+1	13:23
wwoods	our test releases become a burden after ~4wks	13:24
wwoods	err, start becoming a burden	13:24
warren	Perhaps an important priority for November/December is to make composes faster	13:25
warren	Wont really have time to work on that next year with F9 fires	13:25
jeremy	also, what's up with fudcon and how does the schedule mesh (or not) with that	13:26
warren	jeremy, URL?	13:26
jeremy	warren: don't have one -- just greg's blog post from a few weeks ago	13:26
warren	vaporconference	13:27
wwoods	"Next proposed FUDCon: January 11-13, 2008, at Red Hat HQ in Raleigh."	13:27
wwoods	(that was oct. 17)	13:27
wwoods	http://gregdek.livejournal.com/17724.html	13:27
f13	that would put fudcon the weekend before the Alpha freeze	13:27
warren	pushing back the Alpha freeze to be after FUDcon would be good, suck in possible hackfest results	13:27
f13	not a bad time for it.	13:27
wwoods	yeah, alpha freeze should definitely be post-fudcon-hackfest	13:28
f13	which it would be, if we all agree to kick it out a week due to vacation spew	13:29
warren	spew	13:30
wwoods	do we need to do a proposal/vote or can we just go with implied consent?	13:30
f13	anybody opposed to pushing alpha freeze/release out a week later?	13:31
warren	15th/	13:31
warren	15th?	13:31
poelcat	is fudcon for sure? greg's blog says "proposed"	13:32
wwoods	not for sure. still in discussions etc.	13:32
wwoods	ask greg for details.	13:33
warren	Then let's push it back a week for now, and see how FUDCon crystalizes.	13:33
warren	or congeals	13:33
f13	but we can't wait for vapourconference.	13:33
* warren likes congeal		13:33
f13	and there are other reasons to adjust	13:33
warren	Let's do it	13:33
EvilBob	NOTE: the last word I got from Greg about FUDcon was "Working on it" so I am not sure that date is solid	13:33
gregdek	WORKING TO FINISH PLANS FOR FUDCON.	13:33
rdieter	do it +1, can revisit later when/if new information comes	13:33
gregdek	The date is solid.  The location, though, is up in the air.	13:33
gregdek	More info as I have it.	13:34
EvilBob	gregdek: K	13:34
f13	ok.	13:34
rdieter	mmmm. solid.	13:34
* EvilBob goes to post his other reservations as "for sale"		13:34
rdieter	my back yard is free, it's pretty big. :)	13:34
warren	poelcat, I assume you've already looked at how the proposed F9 schedule may affect <awful red colored commercial spin> schedule?	13:34
wwoods	I think that's due to be discussed later this week	13:35
poelcat	warren: having weekly meeting with them	13:35
warren	k	13:35
wwoods	having rel-eng approval will give this schedule more weight, prolly	13:35
f13	yes	13:36
f13	other people still need to weigh in	13:36
f13	FESCo, Docs, translation team, QA	13:36
f13	(although QA is kind of doing that now)	13:36
wwoods	Yeah, thus far I'm happy with it but I'll ping testers and such	13:36
wwoods	I'm not sure if the denizens of -test-list are fully aware of the changes being proposed	13:37
wwoods	but I can't see there being major opposition	13:37
wwoods	mostly we're codifying existing procedure and streamlining the early half of the process	13:38
wwoods	it's a solid plan and I like it a lot.	13:38
warren	Do it	13:38
warren	let's move on	13:38
f13	ok, moving on.	13:38
* poelcat hears action as move Alpha to 15th... hold to other dates		13:39
f13	As some of you noticed due to email, we now have a Trac instance at hosted.fp.o	13:39
warren	poelcat, and the release one week as well.	13:39
f13	I've created milestones for Alpha/Beta/Final Freeze/Release s	13:39
f13	warren: what?	13:39
warren	f13, wasn't that the plan?	13:39
wwoods	Alpha Freeze Jan. 15, Alpha release Jan. 24	13:39
f13	warren: we're not moving the final release, just the Alpha freeze/release set.	13:39
warren	ok yes.	13:40
poelcat	f13: carry on :)	13:40
warren	f13, does this mean freeze requests go into trac instead of flooded lit?	13:40
warren	list?	13:40
f13	warren: getting to that.	13:40
f13	So far I've filed some pretty important things we need to do for each of those things	13:41
f13	and I'd like to encourage all of you to add tickets as you think of things that need to be done.	13:41
f13	or propose milestones for things.	13:41
f13	This is really our first stab at writing up each part.	13:41
f13	And since we /have/ Trac, we can start looking at using it for processing tag requests	13:42
f13	however, I don't want to force people to click through web forms, I"d like to allow them to just email an address and have it go into a ticket	13:42
wwoods	that would be good, because it sucks when we worry about dropping rel-eng requests on the floor	13:42
notting	where is the frontpage for this?	13:42
f13	THere are python scripts that can take email as input and create Trac tickets from them, and I would like to make use of that to turn 'rel-eng@fedoraproject.org' into a Trac input.	13:42
warren	notting, https://hosted.fedoraproject.org/projects/rel-eng/	13:42
f13	notting: https://hosted.fedoraproject.org/projects/rel-eng/	13:43
f13	Right now all tickets are assigned to rel-eng@ alias, which wouldn't work so hot if we turned that into a Trac input	13:44
f13	so we'll either need a new alias or something else to assign tickets to	13:44
f13	I wouldn't mind creating a full email-list for release engineering, and making that list the default assignee of tickets.	13:45
warren	assign to nobody@	13:45
f13	rel-eng@ could be the trac input still.	13:45
f13	warren: nobody@ sucks for getting notified of new tickets filed.	13:45
f13	Any thoughts about this?	13:47
wwoods	would the releng list be invite-only or what?	13:47
warren	archives not open to public?	13:47
* poelcat posts refreshed schedule... still researching holidays		13:47
wwoods	it makes sense to me, anyway. would be nice to have public archives etc	13:47
f13	public archives yes.	13:48
warren	so this replaces rel-eng@ ?	13:48
f13	invite only, I'm not sure.  If we're doing voting on that list then yeah, I'd like to keep it that way to avoid confusing noise from non-voters.	13:48
wwoods	well, maybe moderated such that only voting members can post freely. I don't care if people want to join and follow the list	13:49
f13	warren: yes, rel-eng@ would cease to be a wide alias for us, and would be come an email gateway to our trac.  We'd gain a new mailing list for us, and that would be come the default owner of tickets.  If you're going to work on a ticket, you can reassign to yourself.  (not mandatory)	13:49
f13	wwoods: perhaps	13:49
wwoods	so how would people create tickets? mail to rel-eng@fp.o, which goes to trac, which sends mail to fedora-rel-eng@r.c	13:49
warren	So people should no longer send mail to rel-eng@	13:50
f13	wwoods: that's the easiest way yes.	13:50
wwoods	no, I think the mail alias would stay the same	13:50
f13	wwoods: alternatively they could file directly in Trac	13:50
wwoods	but this new list would take the *role* of rel-eng@fp.o	13:50
wwoods	build requests still go to the same place, and they still get to all of us	13:51
wwoods	but they go through trac->mailman first	13:51
wwoods	so we get public archives and ticketing	13:51
wwoods	accountability, transparency, all that good stuff	13:51
wwoods	I guess you can tell that I support this idea.	13:52
f13	heh	13:52
wwoods	so, yeah. let's make a decision and move on?	13:55
f13	anybody against moving in this direction?	13:56
jeremy	nope	13:56
f13	It may take a while to hook up the email gateway, rel-eng@fp.o won't go away as our communication method until that happens I think.	13:56
warren	wwoods, wait	13:57
warren	wwoods, if people can still post to rel-eng@	13:57
warren	how does that make it invite-only?	13:57
f13	...	13:57
f13	warren: /two/ addresses.	13:57
warren	oh	13:58
f13	warren: rel-eng@  -> trac.  feodra-release-engineering@redhat.com -> moderated mailing list.	13:58
warren	trac can create tickets from an e-mail?	13:58
f13	warren: that's what I said above.  There is a python tool to do this, we just have to hook it up somewhere in Fedora infrastructure.	13:58
warren	ok cool	13:58
f13	alright, nobody said no.	13:59
f13	poelcat: decision: continue move to Trac for task management.  Work toward turning rel-eng@fp.o into a Trac ticket gateway, and creating an invite only or otherwise moderated mailing list for rel-eng discussion/voting.	14:00
f13	This is just a quick blurb, that since FESCo approved the proposal, I made some big updates to the Overview page to reflect this.	14:00
f13	If i've missed anything, please let me know.	14:00
wwoods	f13: for reference, URL for the Overview page?	14:01
f13	This I"d like ya'll to brainstorm a bit befor enext week's meeting, to figure out what we want to do for this release, outside the typical make bits shwo up stuff.	14:01
f13	wwoods: http://fedoraproject.org/wiki/ReleaseEngineering/Overview	14:01
notting	signing server!	14:01
f13	Personally, I'd really like to get the signing server in place	14:02
wwoods	bodhi depchecking!	14:02
f13	and complete the s/development/rawhide/ changes.	14:02
notting	potentially the big multilib change. i need to get some stuff written down for that	14:02
f13	wwoods: that would be nice in some form.	14:02
f13	notting: please for the love of god (:	14:02
wwoods	at least in an informative manner: "pushing this update will break deps on the following live packages"	14:03
notting	also, i'd like to kill the buildroot overrides stuff	14:03
wwoods	and holy merciful crap yeah, everyone is dying for multilib reworking. but that's a much more invasive thing than the signing server	14:03
f13	notting: can you explain that more?	14:03
wwoods	and I think bodhi depchecking is going to be a lot more complex than the signing server	14:04
notting	f13: push updates-candidate into the buildroot automatically	14:04
f13	notting: that gives me a bit of the hives.	14:04
f13	notting: but I await your proposal (:	14:05
warren	notting, what do we do instead of buildroot override?	14:05
f13	I'd also like to see something done with ppc	14:05
warren	oops	14:05
notting	f13: bodhi was going to grow a flag if an update was built against unreleased packages . this is all old stuff that just hasn't happened yet.	14:05
f13	notting: sure, it's also making things pretty complicated for somebody trying to push an update, or figure out why an update hasn't been pushed.	14:06
f13	lets see, what else woudl I not be upset if it magically happened.	14:06
notting	free beer everywhere.	14:06
f13	oh!  post-build processing, say running rpmlint and other such things.	14:06
warren	delta rpm and presto by default?	14:07
f13	that could happen.	14:07
f13	jigdo support	14:07
warren	And I really don't buy that we need delta rpm to be generated by koji/bodhi.  Why can't it be an async process?	14:07
f13	dealing with rawhide late in the cycle so that we have two nightly trees	14:07
wwoods	oh yeah, PPC as the trailblazer secondary arch	14:08
f13	warren: for much of the same reason why pcakage signing shouldn't necessarily be async.	14:08
warren	delta rpm generation would have to happen after packaging signing	14:08
wwoods	if the compose process is already too slow, adding more steps seems like a loss	14:08
warren	wwoods, +1	14:08
warren	f13, delta rpm missing or existing doesn't break existing users	14:08
f13	warren: but if package signing is automated...	14:08
warren	f13, no reason to slow down the composing process for deltas	14:09
f13	warren: if you don't create them during the compose process, how else do they show up?	14:09
warren	f13, perhaps we should talk about this in detail later, I think there is an understanding disconnect about how it could work.	14:09
warren	a bit off-topic for here	14:09
f13	sure, somebody needs to own the feature and run with it.	14:10
f13	anywho, I'd love to hear some thoughts and proposals on what to do for F9 by next week's meeting.	14:10
warren	ok	14:10
f13	preferrably by Friday so we can digest it over the weekend.	14:10
wwoods	things proposed thus far: signing server, bodhi depchecking, multilib rework, deltarpm (presto) support, buildroot overrides(?)	14:11
f13	poelcat: decision: prepare and present Fedora 9 rel-eng goals by next week's meeting.	14:11
f13	wwoods: and jigdo	14:11
f13	oh geez, I forgot something.	14:11
f13	The board has asked that we produce split CD media once again.	14:12
f13	I haven't fully agreed, I just indicated that it would be possible.	14:12
notting	it's really just a matter of time and space, yes?	14:12
warren	installing from live is insufficient?	14:12
notting	there shouldn't be any *technical* concerns?	14:12
notting	(i don't care one way or another, just clarifying)	14:12
f13	notting: just crufty code.	14:13
f13	warren: can't upgrade with live images.	14:13
warren	f13, good point	14:13
warren	f13, although we need that crufty code to work for RHEL6	14:13
f13	yes	14:14
f13	but they have their own crufty code.	14:14
f13	not necessarily the same as ours.	14:14
f13	(lets not go there here)	14:14
wwoods	I sure do love having more test targets	14:14
f13	From our side of things, its not that big of a deal.  more compose time, more validation time, more sync time, larger space used.	14:15
warren	f13, eh?  isn't RHEL6 split-CD upgrade going to be based on Fedora <some number>	14:15
f13	warren: RHEL's tool has their own copy of splittree.py and potentially more things.	14:15
warren	oh	14:15
f13	but not a discussion for here.	14:15
jeremy	another important thing to note -- my availability for rel-eng types of tasks is going to be a lot lower for f9.  I'm hoping to find some one else to volunteer to run with building live images too	14:15
f13	If nobody else volunteers, I'll be taking that task on	14:16
warren	jeremy, just show me how, I'd love to.	14:16
* poelcat might be interested too		14:16
warren	jeremy, would I need a ppc box to do it?	14:16
f13	wwoods: I think QA gets to make their own stink regarding split media showing up again.	14:16
f13	warren: if we still make ppc live images yes, or you can use mine like Jeremy has been doing.	14:16
jeremy	warren: I just used the ppc that f13 uses for the regular composes.  but hopefully we'll be doing composes in the colo for f9	14:17
f13	jeremy: ooh good point.	14:17
f13	Composes in Colo for F9	14:17
f13	which ties into 'reverse the netapp stream'	14:17
notting	and syncs from colo	14:17
f13	it'll be good to have all these in Trac for well, tracking (:	14:17
jeremy	(in an ideal world, we could then have an "external" person do the live composes.  which would be nice.   if nothing else, I'd like to let the kde sig take ownership of their own destiny, and the same with other spins)	14:17
f13	Last item.	14:18
f13	any objections to moving the meeting time one hour later to match up with DST?	14:18
f13	(we did it today based on vote of those that showed up at the regular time)	14:19
notting	no objections from me	14:19
warren	do it	14:20
* wwoods +1		14:20
f13	poelcat: decision: Meeting time now one hour later (1800 UTC) to stay in sync with American DST	14:20
jeremy	do it!	14:21
f13	ok, unless there is anything else, we should call it.	14:21
wwoods	I think we're good	14:22
wwoods	Woo	14:22
wwoods	goooo rel-eng!	14:23
f13	Thanks all!	14:23
poelcat	wwoods: figured it was an important conversation to have a record of	14:25
wwoods	agreed. I had a log of it and was trying to find the irc2html stuff when I noticed you'd already done it	14:25
EvilBob	Just a note on jogdo and the Split CD media, looking at the F8 CD logs Fedora Unity has had just over 600 downloads of the .jigdo file, about 400 downloads of the CD1 template, so 200 or so users did not know where to get started with jigdo or did not start yet.	14:33
poelcat	EvilBob: why is F8 CD1 so popular when you can download F8 rescue.iso just as easily?	14:37
f13	EvilBob: jigdo is a bit more interesting now that we populate rawhide with signed packages.	14:37
EvilBob	poelcat: for people that do not have the connectivity to do a network install is my best guess	14:39
poelcat	ahh	14:39
EvilBob	poelcat: we don't know all the reasons why people have asked for us to release these but that was one arguement	14:40
EvilBob	poelcat: a lot of users are getting the .jigdo and the CD1 template, checking to see what other media they need and are only building those images	14:41
EvilBob	Hopefully this week we will get it so the logs are merged between all the round robin servers we are using so we can start looking at where users are coming from	14:43
poelcat	that's pretty interesting	14:44
EvilBob	if we can look at what packages are on what CD and what CD other than 1 is most popular that might make for some interesting analysis	14:46

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