ReleaseEngineering/Meetings/2007-nov-12

From FedoraProject

Jump to: navigation, search

Contents

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

Schedule Review

F9 Tasks & Targets

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

f13notting: wwoods: warren: jwb: jeremy: spot: rdieter: poelcat: ping<a href="#t13:03" class="time">13:03</a>
wwoodshi!<a href="#t13:04" class="time">13:04</a>
nottingit's like i never left!<a href="#t13:04" class="time">13:04</a>
* poelcat here<a href="#t13:04" class="time">13:04</a>
rdieterhere<a href="#t13:04" class="time">13:04</a>
* warren here<a href="#t13:04" class="time">13:04</a>
* jeremy is here at least sort of<a href="#t13:07" class="time">13:07</a>
f13ok.<a href="#t13:08" class="time">13:08</a>
f13<a href="http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html">http://poelstra.fedorapeople.org/schedules/f9/f9-tasks-overview.html</a><a href="#t13:08" class="time">13:08</a>
f13please review, I'd like to give John the thumbs up from our end.<a href="#t13:08" class="time">13:08</a>
nottingwe're going to have the release scoped in 10 days?<a href="#t13:08" class="time">13:08</a>
f13poelcat: nothing changed since I gave you the thumbs up this weekend right?<a href="#t13:08" class="time">13:08</a>
poelcatf13: correct<a href="#t13:09" class="time">13:09</a>
f13notting: suppose that depends on what "scope" means<a href="#t13:09" class="time">13:09</a>
f13since our feature review is open far longer than the scope period<a href="#t13:09" class="time">13:09</a>
poelcatnotting: yeah, that was kind of place holder for "let's do *some* planning " :)<a href="#t13:09" class="time">13:09</a>
warrenlooks a lot like RHEL<a href="#t13:09" class="time">13:09</a>
warren=)<a href="#t13:09" class="time">13:09</a>
poelcati know fedora board is talking about overall things they would like to see<a href="#t13:10" class="time">13:10</a>
poelcatso that kind of fits in<a href="#t13:10" class="time">13:10</a>
poelcatwarren: nothing like it ;-)<a href="#t13:10" class="time">13:10</a>
poelcatours is better :)<a href="#t13:10" class="time">13:10</a>
nottingif so, the taskjuggler bars should be blue, not red~<a href="#t13:10" class="time">13:10</a>
warrenYeah, RHEL is just a cheap knock-off spin<a href="#t13:10" class="time">13:10</a>
f13ours is achievable.<a href="#t13:11" class="time">13:11</a>
nottingcan we put RHEL on spins.fp.o?<a href="#t13:11" class="time">13:11</a>
f13LOL<a href="#t13:11" class="time">13:11</a>
warrenhah<a href="#t13:11" class="time">13:11</a>
poelcatLOL<a href="#t13:11" class="time">13:11</a>
wwoodstheir packages are all old and crusty<a href="#t13:11" class="time">13:11</a>
wwoodsthey barely update them at all<a href="#t13:11" class="time">13:11</a>
warrenand no excitement<a href="#t13:11" class="time">13:11</a>
wwoodsand ugh, that color scheme<a href="#t13:11" class="time">13:11</a>
wwoodsso red!<a href="#t13:11" class="time">13:11</a>
wwoodsI mean, at least it's not brown, but still<a href="#t13:11" class="time">13:11</a>
warrenThere is currently a flamewar going on at <that project> about moving away from brown.<a href="#t13:12" class="time">13:12</a>
nottingobviously we should switch to a green theme. it's the in thing!<a href="#t13:12" class="time">13:12</a>
wwoodsbut their entire identity is tied up in the brownness! there is none more brown!<a href="#t13:13" class="time">13:13</a>
f13poelcat: one thing I didn't look at was the mash up of any holidays<a href="#t13:13" class="time">13:13</a>
wwoods(this idle chitchat is me stalling while I read through the schedule)<a href="#t13:13" class="time">13:13</a>
f13poelcat: I don't /think/ we have any significant dates falling on holidays, did you check that?<a href="#t13:13" class="time">13:13</a>
nottingwwoods: they wear brown coats? explains the rabid online fans.<a href="#t13:13" class="time">13:13</a>
poelcatf13: i don't believe there are any... but TJ can schedule around them<a href="#t13:13" class="time">13:13</a>
f13k<a href="#t13:13" class="time">13:13</a>
* poelcat will look into it<a href="#t13:13" class="time">13:13</a>
warrennotting, is the new multilib plugin going to happen for F9?<a href="#t13:13" class="time">13:13</a>
jeremyalpha freeze is likely to be "interesting" as the first work-week post the holidays<a href="#t13:13" class="time">13:13</a>
nottingwarren: REPLY HAZY. ASK AGAIN LATER.<a href="#t13:14" class="time">13:14</a>
rdietermultilib plugin?<a href="#t13:14" class="time">13:14</a>
wwoodsI'm going to be gone during the first week of April I think<a href="#t13:14" class="time">13:14</a>
f13rdieter: 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.<a href="#t13:15" class="time">13:15</a>
rdieterwee!<a href="#t13:15" class="time">13:15</a>
wwoodsactually 7-12. which coincides with PR1.<a href="#t13:15" class="time">13:15</a>
warrenI don't get back until January 8th<a href="#t13:15" class="time">13:15</a>
wwoodsoh man, having a "i386 compatibility" checkbox in the installer/yum config would be just awesome<a href="#t13:16" class="time">13:16</a>
rdieterwelcome aboard, capt awesome. :)<a href="#t13:17" class="time">13:17</a>
warrengood friends with captain obvious<a href="#t13:17" class="time">13:17</a>
f13wwoods: having composes that don't take 14 hours would be awesome too<a href="#t13:17" class="time">13:17</a>
wwoodsall aboard the H.M.S. whupass! SET SAIL FOR RADNESS!!<a href="#t13:17" class="time">13:17</a>
wwoodsf13: roger that<a href="#t13:17" class="time">13:17</a>
rdieter*cough* 14 hours! ouchie.<a href="#t13:17" class="time">13:17</a>
wwoodsso yeah, I'll have to get someone to fill in as QA Lead for PR1<a href="#t13:18" class="time">13:18</a>
poelcatwwoods:  and a free bottle of awesome sauce?<a href="#t13:18" class="time">13:18</a>
wwoodsbut given 5 months to do so, I think that'll be OK<a href="#t13:18" class="time">13:18</a>
warrenCould we possibly push back Alpha freeze by a week?<a href="#t13:18" class="time">13:18</a>
wwoodswell, it's a non-blocking ("honor system") freeze<a href="#t13:19" class="time">13:19</a>
f13warren: which direction is "back", and why?<a href="#t13:19" class="time">13:19</a>
wwoodsso the first week could just be a polite request to skip non-essential builds<a href="#t13:19" class="time">13:19</a>
warren"Please don't cause new breakage."<a href="#t13:20" class="time">13:20</a>
wwoodsand subsequent weeks the request becomes less polite?<a href="#t13:20" class="time">13:20</a>
warrenf13, 1/8 seems to be too early, especially with many people returning from holidays<a href="#t13:20" class="time">13:20</a>
f13if you mean make it a week later, ditto the release of Alpha1, I'm OK with that, without adjusting other schedules.<a href="#t13:20" class="time">13:20</a>
warrenyes, htat<a href="#t13:21" class="time">13:21</a>
f13note that during the holidays is when a lot of our maintainers actually have /time/ to do Fedora stuff<a href="#t13:21" class="time">13:21</a>
f13it's just the paid shills that stop work<a href="#t13:21" class="time">13:21</a>
warrenI did lots of work during last holidays<a href="#t13:21" class="time">13:21</a>
wwoodsdoes it make sense to move the release a week later and leave the freeze where it is?<a href="#t13:22" class="time">13:22</a>
f13I would be board out of my mind if I didn't do work.<a href="#t13:22" class="time">13:22</a>
f13wwoods: no, because then we wouldn't get all those fun builds which would actually be worth testing.<a href="#t13:22" class="time">13:22</a>
warrenwwoods, if honor system freeze, i guess so.<a href="#t13:22" class="time">13:22</a>
warrenf13, oh<a href="#t13:22" class="time">13:22</a>
f13wwoods: if we're worried about new stuff landing due to holiday hackfests, we should include that in the Alpha<a href="#t13:23" class="time">13:23</a>
wwoodstrue<a href="#t13:23" class="time">13:23</a>
wwoodsand the alpha is already 3 weeks longer than the beta<a href="#t13:23" class="time">13:23</a>
warrenpush back freeze and release by a week<a href="#t13:23" class="time">13:23</a>
warren+1<a href="#t13:23" class="time">13:23</a>
wwoodsour test releases become a burden after ~4wks<a href="#t13:24" class="time">13:24</a>
wwoodserr, start becoming a burden<a href="#t13:24" class="time">13:24</a>
warrenPerhaps an important priority for November/December is to make composes faster<a href="#t13:25" class="time">13:25</a>
warrenWont really have time to work on that next year with F9 fires<a href="#t13:25" class="time">13:25</a>
jeremyalso, what's up with fudcon and how does the schedule mesh (or not) with that<a href="#t13:26" class="time">13:26</a>
warrenjeremy, URL?<a href="#t13:26" class="time">13:26</a>
jeremywarren: don't have one -- just greg's blog post from a few weeks ago<a href="#t13:26" class="time">13:26</a>
warrenvaporconference<a href="#t13:27" class="time">13:27</a>
wwoods"Next proposed FUDCon: January 11-13, 2008, at Red Hat HQ in Raleigh."<a href="#t13:27" class="time">13:27</a>
wwoods(that was oct. 17)<a href="#t13:27" class="time">13:27</a>
wwoods<a href="http://gregdek.livejournal.com/17724.html">http://gregdek.livejournal.com/17724.html</a><a href="#t13:27" class="time">13:27</a>
f13that would put fudcon the weekend before the Alpha freeze<a href="#t13:27" class="time">13:27</a>
warrenpushing back the Alpha freeze to be after FUDcon would be good, suck in possible hackfest results<a href="#t13:27" class="time">13:27</a>
f13not a bad time for it.<a href="#t13:27" class="time">13:27</a>
wwoodsyeah, alpha freeze should definitely be post-fudcon-hackfest<a href="#t13:28" class="time">13:28</a>
f13which it would be, if we all agree to kick it out a week due to vacation spew<a href="#t13:29" class="time">13:29</a>
warrenspew<a href="#t13:30" class="time">13:30</a>
wwoodsdo we need to do a proposal/vote or can we just go with implied consent?<a href="#t13:30" class="time">13:30</a>
f13anybody opposed to pushing alpha freeze/release out a week later?<a href="#t13:31" class="time">13:31</a>
warren15th/<a href="#t13:31" class="time">13:31</a>
warren15th?<a href="#t13:31" class="time">13:31</a>
poelcatis fudcon for sure? greg's blog says "proposed"<a href="#t13:32" class="time">13:32</a>
wwoodsnot for sure. still in discussions etc.<a href="#t13:32" class="time">13:32</a>
wwoodsask greg for details.<a href="#t13:33" class="time">13:33</a>
warrenThen let's push it back a week for now, and see how FUDCon crystalizes.<a href="#t13:33" class="time">13:33</a>
warrenor congeals<a href="#t13:33" class="time">13:33</a>
f13but we can't wait for vapourconference.<a href="#t13:33" class="time">13:33</a>
* warren likes congeal<a href="#t13:33" class="time">13:33</a>
f13and there are other reasons to adjust<a href="#t13:33" class="time">13:33</a>
warrenLet's do it<a href="#t13:33" class="time">13:33</a>
EvilBobNOTE: the last word I got from Greg about FUDcon was "Working on it" so I am not sure that date is solid<a href="#t13:33" class="time">13:33</a>
gregdekWORKING TO FINISH PLANS FOR FUDCON.<a href="#t13:33" class="time">13:33</a>
rdieterdo it +1, can revisit later when/if new information comes<a href="#t13:33" class="time">13:33</a>
gregdekThe date is solid.  The location, though, is up in the air.<a href="#t13:33" class="time">13:33</a>
gregdekMore info as I have it.<a href="#t13:34" class="time">13:34</a>
EvilBobgregdek: K<a href="#t13:34" class="time">13:34</a>
f13ok.<a href="#t13:34" class="time">13:34</a>
rdietermmmm. solid.<a href="#t13:34" class="time">13:34</a>
* EvilBob goes to post his other reservations as "for sale"<a href="#t13:34" class="time">13:34</a>
rdietermy back yard is free, it's pretty big. :)<a href="#t13:34" class="time">13:34</a>
warrenpoelcat, I assume you've already looked at how the proposed F9 schedule may affect <awful red colored commercial spin> schedule?<a href="#t13:34" class="time">13:34</a>
wwoodsI think that's due to be discussed later this week<a href="#t13:35" class="time">13:35</a>
poelcatwarren: having weekly meeting with them<a href="#t13:35" class="time">13:35</a>
warrenk<a href="#t13:35" class="time">13:35</a>
wwoodshaving rel-eng approval will give this schedule more weight, prolly<a href="#t13:35" class="time">13:35</a>
f13yes<a href="#t13:36" class="time">13:36</a>
f13other people still need to weigh in<a href="#t13:36" class="time">13:36</a>
f13FESCo, Docs, translation team, QA<a href="#t13:36" class="time">13:36</a>
f13(although QA is kind of doing that now)<a href="#t13:36" class="time">13:36</a>
wwoodsYeah, thus far I'm happy with it but I'll ping testers and such<a href="#t13:36" class="time">13:36</a>
wwoodsI'm not sure if the denizens of -test-list are fully aware of the changes being proposed<a href="#t13:37" class="time">13:37</a>
wwoodsbut I can't see there being major opposition<a href="#t13:37" class="time">13:37</a>
wwoodsmostly we're codifying existing procedure and streamlining the early half of the process<a href="#t13:38" class="time">13:38</a>
wwoodsit's a solid plan and I like it a lot.<a href="#t13:38" class="time">13:38</a>
warrenDo it<a href="#t13:38" class="time">13:38</a>
warrenlet's move on<a href="#t13:38" class="time">13:38</a>
f13ok, moving on.<a href="#t13:38" class="time">13:38</a>
* poelcat hears action as move Alpha to 15th... hold to other dates<a href="#t13:39" class="time">13:39</a>
f13As some of you noticed due to email, we now have a Trac instance at hosted.fp.o<a href="#t13:39" class="time">13:39</a>
warrenpoelcat, and the release one week as well.<a href="#t13:39" class="time">13:39</a>
f13I've created milestones for Alpha/Beta/Final Freeze/Release s<a href="#t13:39" class="time">13:39</a>
f13warren: what?<a href="#t13:39" class="time">13:39</a>
warrenf13, wasn't that the plan?<a href="#t13:39" class="time">13:39</a>
wwoodsAlpha Freeze Jan. 15, Alpha release Jan. 24<a href="#t13:39" class="time">13:39</a>
f13warren: we're not moving the final release, just the Alpha freeze/release set.<a href="#t13:39" class="time">13:39</a>
warrenok yes.<a href="#t13:40" class="time">13:40</a>
poelcatf13: carry on :)<a href="#t13:40" class="time">13:40</a>
warrenf13, does this mean freeze requests go into trac instead of flooded lit?<a href="#t13:40" class="time">13:40</a>
warrenlist?<a href="#t13:40" class="time">13:40</a>
f13warren: getting to that.<a href="#t13:40" class="time">13:40</a>
f13So far I've filed some pretty important things we need to do for each of those things<a href="#t13:41" class="time">13:41</a>
f13and I'd like to encourage all of you to add tickets as you think of things that need to be done.<a href="#t13:41" class="time">13:41</a>
f13or propose milestones for things.<a href="#t13:41" class="time">13:41</a>
f13This is really our first stab at writing up each part.<a href="#t13:41" class="time">13:41</a>
f13And since we /have/ Trac, we can start looking at using it for processing tag requests<a href="#t13:42" class="time">13:42</a>
f13however, 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<a href="#t13:42" class="time">13:42</a>
wwoodsthat would be good, because it sucks when we worry about dropping rel-eng requests on the floor<a href="#t13:42" class="time">13:42</a>
nottingwhere is the frontpage for this?<a href="#t13:42" class="time">13:42</a>
f13THere 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.<a href="#t13:42" class="time">13:42</a>
warrennotting, <a href="https://hosted.fedoraproject.org/projects/rel-eng/">https://hosted.fedoraproject.org/projects/rel-eng/</a><a href="#t13:42" class="time">13:42</a>
f13notting: <a href="https://hosted.fedoraproject.org/projects/rel-eng/">https://hosted.fedoraproject.org/projects/rel-eng/</a><a href="#t13:43" class="time">13:43</a>
f13Right now all tickets are assigned to rel-eng@ alias, which wouldn't work so hot if we turned that into a Trac input<a href="#t13:44" class="time">13:44</a>
f13so we'll either need a new alias or something else to assign tickets to<a href="#t13:44" class="time">13:44</a>
f13I wouldn't mind creating a full email-list for release engineering, and making that list the default assignee of tickets.<a href="#t13:45" class="time">13:45</a>
warrenassign to nobody@<a href="#t13:45" class="time">13:45</a>
f13rel-eng@ could be the trac input still.<a href="#t13:45" class="time">13:45</a>
f13warren: nobody@ sucks for getting notified of new tickets filed.<a href="#t13:45" class="time">13:45</a>
f13Any thoughts about this?<a href="#t13:47" class="time">13:47</a>
wwoodswould the releng list be invite-only or what?<a href="#t13:47" class="time">13:47</a>
warrenarchives not open to public?<a href="#t13:47" class="time">13:47</a>
* poelcat posts refreshed schedule... still researching holidays<a href="#t13:47" class="time">13:47</a>
wwoodsit makes sense to me, anyway. would be nice to have public archives etc<a href="#t13:47" class="time">13:47</a>
f13public archives yes.<a href="#t13:48" class="time">13:48</a>
warrenso this replaces rel-eng@ ?<a href="#t13:48" class="time">13:48</a>
f13invite 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.<a href="#t13:48" class="time">13:48</a>
wwoodswell, maybe moderated such that only voting members can post freely. I don't care if people want to join and follow the list<a href="#t13:49" class="time">13:49</a>
f13warren: 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)<a href="#t13:49" class="time">13:49</a>
f13wwoods: perhaps<a href="#t13:49" class="time">13:49</a>
wwoodsso how would people create tickets? mail to rel-eng@fp.o, which goes to trac, which sends mail to fedora-rel-eng@r.c<a href="#t13:49" class="time">13:49</a>
warrenSo people should no longer send mail to rel-eng@<a href="#t13:50" class="time">13:50</a>
f13wwoods: that's the easiest way yes.<a href="#t13:50" class="time">13:50</a>
wwoodsno, I think the mail alias would stay the same<a href="#t13:50" class="time">13:50</a>
f13wwoods: alternatively they could file directly in Trac<a href="#t13:50" class="time">13:50</a>
wwoodsbut this new list would take the *role* of rel-eng@fp.o<a href="#t13:50" class="time">13:50</a>
wwoodsbuild requests still go to the same place, and they still get to all of us<a href="#t13:51" class="time">13:51</a>
wwoodsbut they go through trac->mailman first<a href="#t13:51" class="time">13:51</a>
wwoodsso we get public archives and ticketing<a href="#t13:51" class="time">13:51</a>
wwoodsaccountability, transparency, all that good stuff<a href="#t13:51" class="time">13:51</a>
wwoodsI guess you can tell that I support this idea.<a href="#t13:52" class="time">13:52</a>
f13heh<a href="#t13:52" class="time">13:52</a>
wwoodsso, yeah. let's make a decision and move on?<a href="#t13:55" class="time">13:55</a>
f13anybody against moving in this direction?<a href="#t13:56" class="time">13:56</a>
jeremynope<a href="#t13:56" class="time">13:56</a>
f13It 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.<a href="#t13:56" class="time">13:56</a>
warrenwwoods, wait<a href="#t13:57" class="time">13:57</a>
warrenwwoods, if people can still post to rel-eng@<a href="#t13:57" class="time">13:57</a>
warrenhow does that make it invite-only?<a href="#t13:57" class="time">13:57</a>
f13...<a href="#t13:57" class="time">13:57</a>
f13warren: /two/ addresses.<a href="#t13:57" class="time">13:57</a>
warrenoh<a href="#t13:58" class="time">13:58</a>
f13warren: rel-eng@  -> trac.  feodra-release-engineering@redhat.com -> moderated mailing list.<a href="#t13:58" class="time">13:58</a>
warrentrac can create tickets from an e-mail?<a href="#t13:58" class="time">13:58</a>
f13warren: 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.<a href="#t13:58" class="time">13:58</a>
warrenok cool<a href="#t13:58" class="time">13:58</a>
f13alright, nobody said no.<a href="#t13:59" class="time">13:59</a>
f13poelcat: 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.<a href="#t14:00" class="time">14:00</a>
f13This is just a quick blurb, that since FESCo approved the proposal, I made some big updates to the Overview page to reflect this.<a href="#t14:00" class="time">14:00</a>
f13If i've missed anything, please let me know.<a href="#t14:00" class="time">14:00</a>
wwoodsf13: for reference, URL for the Overview page?<a href="#t14:01" class="time">14:01</a>
f13This 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.<a href="#t14:01" class="time">14:01</a>
f13wwoods: <a href="http://fedoraproject.org/wiki/ReleaseEngineering/Overview">http://fedoraproject.org/wiki/ReleaseEngineering/Overview</a><a href="#t14:01" class="time">14:01</a>
nottingsigning server!<a href="#t14:01" class="time">14:01</a>
f13Personally, I'd really like to get the signing server in place<a href="#t14:02" class="time">14:02</a>
wwoodsbodhi depchecking!<a href="#t14:02" class="time">14:02</a>
f13and complete the s/development/rawhide/ changes.<a href="#t14:02" class="time">14:02</a>
nottingpotentially the big multilib change. i need to get some stuff written down for that<a href="#t14:02" class="time">14:02</a>
f13wwoods: that would be nice in some form.<a href="#t14:02" class="time">14:02</a>
f13notting: please for the love of god (:<a href="#t14:02" class="time">14:02</a>
wwoodsat least in an informative manner: "pushing this update will break deps on the following live packages"<a href="#t14:03" class="time">14:03</a>
nottingalso, i'd like to kill the buildroot overrides stuff<a href="#t14:03" class="time">14:03</a>
wwoodsand holy merciful crap yeah, everyone is dying for multilib reworking. but that's a much more invasive thing than the signing server<a href="#t14:03" class="time">14:03</a>
f13notting: can you explain that more?<a href="#t14:03" class="time">14:03</a>
wwoodsand I think bodhi depchecking is going to be a lot more complex than the signing server<a href="#t14:04" class="time">14:04</a>
nottingf13: push updates-candidate into the buildroot automatically<a href="#t14:04" class="time">14:04</a>
f13notting: that gives me a bit of the hives.<a href="#t14:04" class="time">14:04</a>
f13notting: but I await your proposal (:<a href="#t14:05" class="time">14:05</a>
warrennotting, what do we do instead of buildroot override?<a href="#t14:05" class="time">14:05</a>
f13I'd also like to see something done with ppc<a href="#t14:05" class="time">14:05</a>
warrenoops<a href="#t14:05" class="time">14:05</a>
nottingf13: 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.<a href="#t14:05" class="time">14:05</a>
f13notting: 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.<a href="#t14:06" class="time">14:06</a>
f13lets see, what else woudl I not be upset if it magically happened.<a href="#t14:06" class="time">14:06</a>
nottingfree beer everywhere.<a href="#t14:06" class="time">14:06</a>
f13oh!  post-build processing, say running rpmlint and other such things.<a href="#t14:06" class="time">14:06</a>
warrendelta rpm and presto by default?<a href="#t14:07" class="time">14:07</a>
f13that could happen.<a href="#t14:07" class="time">14:07</a>
f13jigdo support<a href="#t14:07" class="time">14:07</a>
warrenAnd I really don't buy that we need delta rpm to be generated by koji/bodhi.  Why can't it be an async process?<a href="#t14:07" class="time">14:07</a>
f13dealing with rawhide late in the cycle so that we have two nightly trees<a href="#t14:07" class="time">14:07</a>
wwoodsoh yeah, PPC as the trailblazer secondary arch<a href="#t14:08" class="time">14:08</a>
f13warren: for much of the same reason why pcakage signing shouldn't necessarily be async.<a href="#t14:08" class="time">14:08</a>
warrendelta rpm generation would have to happen after packaging signing<a href="#t14:08" class="time">14:08</a>
wwoodsif the compose process is already too slow, adding more steps seems like a loss<a href="#t14:08" class="time">14:08</a>
warrenwwoods, +1<a href="#t14:08" class="time">14:08</a>
warrenf13, delta rpm missing or existing doesn't break existing users<a href="#t14:08" class="time">14:08</a>
f13warren: but if package signing is automated...<a href="#t14:08" class="time">14:08</a>
warrenf13, no reason to slow down the composing process for deltas<a href="#t14:09" class="time">14:09</a>
f13warren: if you don't create them during the compose process, how else do they show up?<a href="#t14:09" class="time">14:09</a>
warrenf13, perhaps we should talk about this in detail later, I think there is an understanding disconnect about how it could work.<a href="#t14:09" class="time">14:09</a>
warrena bit off-topic for here<a href="#t14:09" class="time">14:09</a>
f13sure, somebody needs to own the feature and run with it.<a href="#t14:10" class="time">14:10</a>
f13anywho, I'd love to hear some thoughts and proposals on what to do for F9 by next week's meeting.<a href="#t14:10" class="time">14:10</a>
warrenok<a href="#t14:10" class="time">14:10</a>
f13preferrably by Friday so we can digest it over the weekend.<a href="#t14:10" class="time">14:10</a>
wwoodsthings proposed thus far: signing server, bodhi depchecking, multilib rework, deltarpm (presto) support, buildroot overrides(?)<a href="#t14:11" class="time">14:11</a>
f13poelcat: decision: prepare and present Fedora 9 rel-eng goals by next week's meeting.<a href="#t14:11" class="time">14:11</a>
f13wwoods: and jigdo<a href="#t14:11" class="time">14:11</a>
f13oh geez, I forgot something.<a href="#t14:11" class="time">14:11</a>
f13The board has asked that we produce split CD media once again.<a href="#t14:12" class="time">14:12</a>
f13I haven't fully agreed, I just indicated that it would be possible.<a href="#t14:12" class="time">14:12</a>
nottingit's really just a matter of time and space, yes?<a href="#t14:12" class="time">14:12</a>
warreninstalling from live is insufficient?<a href="#t14:12" class="time">14:12</a>
nottingthere shouldn't be any *technical* concerns?<a href="#t14:12" class="time">14:12</a>
notting(i don't care one way or another, just clarifying)<a href="#t14:12" class="time">14:12</a>
f13notting: just crufty code.<a href="#t14:13" class="time">14:13</a>
f13warren: can't upgrade with live images.<a href="#t14:13" class="time">14:13</a>
warrenf13, good point<a href="#t14:13" class="time">14:13</a>
warrenf13, although we need that crufty code to work for RHEL6<a href="#t14:13" class="time">14:13</a>
f13yes<a href="#t14:14" class="time">14:14</a>
f13but they have their own crufty code.<a href="#t14:14" class="time">14:14</a>
f13not necessarily the same as ours.<a href="#t14:14" class="time">14:14</a>
f13(lets not go there here)<a href="#t14:14" class="time">14:14</a>
wwoodsI sure do love having more test targets<a href="#t14:14" class="time">14:14</a>
f13From our side of things, its not that big of a deal.  more compose time, more validation time, more sync time, larger space used.<a href="#t14:15" class="time">14:15</a>
warrenf13, eh?  isn't RHEL6 split-CD upgrade going to be based on Fedora <some number><a href="#t14:15" class="time">14:15</a>
f13warren: RHEL's tool has their own copy of splittree.py and potentially more things.<a href="#t14:15" class="time">14:15</a>
warrenoh<a href="#t14:15" class="time">14:15</a>
f13but not a discussion for here.<a href="#t14:15" class="time">14:15</a>
jeremyanother 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<a href="#t14:15" class="time">14:15</a>
f13If nobody else volunteers, I'll be taking that task on<a href="#t14:16" class="time">14:16</a>
warrenjeremy, just show me how, I'd love to.<a href="#t14:16" class="time">14:16</a>
* poelcat might be interested too<a href="#t14:16" class="time">14:16</a>
warrenjeremy, would I need a ppc box to do it?<a href="#t14:16" class="time">14:16</a>
f13wwoods: I think QA gets to make their own stink regarding split media showing up again.<a href="#t14:16" class="time">14:16</a>
f13warren: if we still make ppc live images yes, or you can use mine like Jeremy has been doing.<a href="#t14:16" class="time">14:16</a>
jeremywarren: I just used the ppc that f13 uses for the regular composes.  but hopefully we'll be doing composes in the colo for f9<a href="#t14:17" class="time">14:17</a>
f13jeremy: ooh good point.<a href="#t14:17" class="time">14:17</a>
f13Composes in Colo for F9<a href="#t14:17" class="time">14:17</a>
f13which ties into 'reverse the netapp stream'<a href="#t14:17" class="time">14:17</a>
nottingand syncs from colo<a href="#t14:17" class="time">14:17</a>
f13it'll be good to have all these in Trac for well, tracking (:<a href="#t14:17" class="time">14:17</a>
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)<a href="#t14:17" class="time">14:17</a>
f13Last item.<a href="#t14:18" class="time">14:18</a>
f13any objections to moving the meeting time one hour later to match up with DST?<a href="#t14:18" class="time">14:18</a>
f13(we did it today based on vote of those that showed up at the regular time)<a href="#t14:19" class="time">14:19</a>
nottingno objections from me<a href="#t14:19" class="time">14:19</a>
warrendo it<a href="#t14:20" class="time">14:20</a>
* wwoods +1<a href="#t14:20" class="time">14:20</a>
f13poelcat: decision: Meeting time now one hour later (1800 UTC) to stay in sync with American DST<a href="#t14:20" class="time">14:20</a>
jeremydo it!<a href="#t14:21" class="time">14:21</a>
f13ok, unless there is anything else, we should call it.<a href="#t14:21" class="time">14:21</a>
wwoodsI think we're good<a href="#t14:22" class="time">14:22</a>
wwoodsWoo<a href="#t14:22" class="time">14:22</a>
wwoodsgoooo rel-eng!<a href="#t14:23" class="time">14:23</a>
f13Thanks all!<a href="#t14:23" class="time">14:23</a>
poelcatwwoods: figured it was an important conversation to have a record of<a href="#t14:25" class="time">14:25</a>
wwoodsagreed. I had a log of it and was trying to find the irc2html stuff when I noticed you'd already done it<a href="#t14:25" class="time">14:25</a>
EvilBobJust 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.<a href="#t14:33" class="time">14:33</a>
poelcatEvilBob: why is F8 CD1 so popular when you can download F8 rescue.iso just as easily?<a href="#t14:37" class="time">14:37</a>
f13EvilBob: jigdo is a bit more interesting now that we populate rawhide with signed packages.<a href="#t14:37" class="time">14:37</a>
EvilBobpoelcat: for people that do not have the connectivity to do a network install is my best guess<a href="#t14:39" class="time">14:39</a>
poelcatahh<a href="#t14:39" class="time">14:39</a>
EvilBobpoelcat: we don't know all the reasons why people have asked for us to release these but that was one arguement<a href="#t14:40" class="time">14:40</a>
EvilBobpoelcat: 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<a href="#t14:41" class="time">14:41</a>
EvilBobHopefully 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<a href="#t14:43" class="time">14:43</a>
poelcatthat's pretty interesting<a href="#t14:44" class="time">14:44</a>
EvilBobif 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<a href="#t14:46" class="time">14:46</a>

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