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