From Fedora Project Wiki

< ReleaseEngineering‎ | Meetings

Revision as of 18:39, 17 February 2014 by Holmja (talk | contribs) (→‎IRC Transcript: Removed some HTML markup.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Fedora Release Engineering Meeting :: Thursday 19-APR-07

F7 Test 4

1. In need of a good release note related to the hda-->sda change. People upgrading from a previous version could experience problems depending on how the partitions are labeled. No one officially took this task. 1. wwoods mentioned some problems he's seeing

  • mkinitrd weirdness lingering
  • a lot of sata/pata weirdness still being tracked down
  • wwoods hoping to go through the buglists and sort stuff out but so far there's no clear patterns

1. notting reports that the comps stuff was approved. He will complete and send mail to rel-eng@fp.o 1. f13 reports seeing lots of "fun" with the extras multilib stuff. 1. jeremy reports that overall it's probably worth doing another tree in the near-ish future, but we're definitely not "there"

Coordination of sub-groups

1. jeremy is going to get a weekly rawhide live image up later today or tomorrow am and that should hopefully get us some more testing 1. f13--rel-eng is the group that drives this meeting and these topics, but we'll want some known points of people to go to for various things.

  • wwoods-QA
  • jeremy-installer and such
  • davej-kernel
  • if you'd like to represent some group for Release Engineering type discussions, feel free to add yourself to the wiki
  • need a "Representatives" section in the ReleaseEngineering page to distinguish between representatives and folks actually in releng

1. jeremy determined that anaconda does not need upd-instroot changes; it looks like it might work and switch back without anything needing doing 1. Discussion about changing default icons

  • notting-are there political concerns with changing icons?
  • wwoods-Is it considered important to have an all-new look for F7?
  • mclasen-when we did switch to echo early in the cycle, we always said that we'd reevaluate late in the cycle
  • don't have a recommendation right now
  • need to consult with some people first; sent question to art list and try to give recommendation by tomorrow.

When should we branch CVS for F7?

1. Several suggestions were made:

  • Merge anyway even if we don't have the hardware--deal with some pain
  • The Day After Tomorrow?
  • At test4 release
  • At the final freeze?

1. No definitive decision was made though folks seemed to think near final freeze was best.

Regular meeting schedule

Decisions made were: 1. Every Monday 1. Extra meetings tossed in when releases are happening for more the state of the tree type things. 1. f13 will mark it in the wiki that Mondays are our regular meeting slot 1. Regular meeting time was not specified

Mailing list for rel-eng?

Decisions made were: 1. Continue to use the rel-eng@ alias for requesting tags and "please do something for me" not necessarily a "lets discuss this topic" or "here is the state of hte tree." Revisit usage after F7 1. Send tree status to fedora-devel

Where to send meeting notes to?

1. Meeting notes will be sent to fedora-devel only to avoid cross-posting mess

What do we report to FESCO?

1. no strong consensus 1. ideas and comments

  • jwb-this is a pointless question
  • wwoods-what sort of decisions does FESCO need special notification of?
  • f13-RTFM? (Read the Fine Minutes)
  • wwoods-maybe decisions to slip schedules, change how freezes are done, etc..?
  • jwb-how we decide to handle freezes, slips, etc

Open Floor

1. wwoods

  • I'm going to try (fingers crossed) to get RHEL QE involved with testing F7--which *might* result in a bunch of folks who are not intimately familiar with Fedora.. customs and traditions; reporting bugs and such
  • if I hear back about the st firmware before test4, I'll bring it up again. otherwise.. F8

1. poelcat

  • I updated the feature listing... there was some discussion on how in/out certain features were
  • have we ever considered the possibility of an audio meeting, e.g. SIP call? It might provide for a faster meeting

1. f13

  • I _really_ want to spin a golden tree at some point tomorrow (2007-04-19) instead of on Monday

IRC Transcript

Idea.png warren changed the topic of #fedora-meeting to: Fedora Release Meeting<a href="#t14:04" class="time">14:04</a>
jeremywwoods: ping<a href="#t14:05" class="time">14:05</a>
warrenWhat was that about the last kernel being busted?<a href="#t14:06" class="time">14:06</a>
jeremyit was busted.  badly<a href="#t14:06" class="time">14:06</a>
jeremynew kernel is building that is fixedificated<a href="#t14:06" class="time">14:06</a>
jeremyand should be done any minute now<a href="#t14:06" class="time">14:06</a>
f13we reverted, and jeremy pushed a new rawhide<a href="#t14:06" class="time">14:06</a>
f13ah cool<a href="#t14:06" class="time">14:06</a>
f13so, lets try to drag wwoods in here.<a href="#t14:06" class="time">14:06</a>
f13wwoods: ping?<a href="#t14:06" class="time">14:06</a>
nottingbusted is .309...?<a href="#t14:06" class="time">14:06</a>
jeremy1<a href="#t14:06" class="time">14:06</a>
wwoodswhat's up? oh excellent<a href="#t14:06" class="time">14:06</a>
jeremy3094 is the good one<a href="#t14:06" class="time">14:06</a>
wwoodsyeah, I hear .3091 was busted but I haven't touched it - .3088 is in rawhide today<a href="#t14:07" class="time">14:07</a>
jeremywwoods: rawhide the second at least<a href="#t14:07" class="time">14:07</a>
wwoodsrawhide 2: the fixening<a href="#t14:07" class="time">14:07</a>
f13heh<a href="#t14:08" class="time">14:08</a>
f13ok..<a href="#t14:08" class="time">14:08</a>
wwoodsdwalsh says the fixfiles/restorecon segfault is fixed in -8, but -7 is what I currently see in rawhide<a href="#t14:08" class="time">14:08</a>
Idea.png f13 changed the topic of #fedora-meeting to: Fedora Release Meeting -- Test 4 status<a href="#t14:08" class="time">14:08</a>
f13so, I haven't caught up on mail, where are we at?<a href="#t14:09" class="time">14:09</a>
wwoodsOTOH the bug seems fixed in -7, so I don't know whether to request inclusion of -8 or just let it go<a href="#t14:09" class="time">14:09</a>
jeremyf13: we're finding bugs, we're fixing bugs, we're rinsing and repeating<a href="#t14:09" class="time">14:09</a>
wwoodsjeremy: you have any insight there?<a href="#t14:09" class="time">14:09</a>
jeremywwoods: looking<a href="#t14:09" class="time">14:09</a>
warrenI'm satisfied with the SCIM debacle for now.  I'm working with tagoh to fix it in an ideal way after Test4.<a href="#t14:09" class="time">14:09</a>
jeremywwoods: -7 should be good enough<a href="#t14:09" class="time">14:09</a>
wwoodsokay, I'll mark that bug CLOSED RAWHIDE<a href="#t14:09" class="time">14:09</a>
* f13 looks at the blocker tree<a href="#t14:09" class="time">14:09</a>
jeremywarren: cool<a href="#t14:10" class="time">14:10</a>
wwoodsI put the kdm/ConsoleKit bug on the blocker list - rdieter wants it for test4, it's already got a patch..<a href="#t14:10" class="time">14:10</a>
wwoodsOTOH - rebuilding chunks of KDE, and untested patches = scary<a href="#t14:10" class="time">14:10</a>
wwoodsopinions?<a href="#t14:10" class="time">14:10</a>
nottingtest it? :)<a href="#t14:10" class="time">14:10</a>
wwoodsright, but we need a test package built first, and AFAIK we don't have that yet<a href="#t14:11" class="time">14:11</a>
f13bah, it's KDE, can't be any more broken... (:<a href="#t14:11" class="time">14:11</a>
nottingbuild it, toss it on people, have people test<a href="#t14:11" class="time">14:11</a>
LetoToquick test 4 question: people are aware that for some machines fc6 -> fc7 will cause a change from hda to sda?<a href="#t14:12" class="time">14:12</a>
LetoTodoes fstab get updated in the upgrade?<a href="#t14:12" class="time">14:12</a>
jeremyLetoTo: fstabs are setup with labels by default<a href="#t14:13" class="time">14:13</a>
jeremywe should be giving better guidance in the case of not now<a href="#t14:13" class="time">14:13</a>
wwoodsf13, notting: so, we should try to get it in for t4?<a href="#t14:13" class="time">14:13</a>
jeremy(still need to write the part for the release notes)<a href="#t14:13" class="time">14:13</a>
LetoTojeremy: yes by default :P<a href="#t14:13" class="time">14:13</a>
jimaLetoTo: non-default = "good luck!"<a href="#t14:13" class="time">14:13</a>
nottingwwoods: get a test build asap, go from there<a href="#t14:13" class="time">14:13</a>
jeremyLetoTo: there is no way to just figure it out and do a migration.  this is part of why we switched to labels long ago<a href="#t14:13" class="time">14:13</a>
LetoTojima: thats fedora policy? :P<a href="#t14:14" class="time">14:14</a>
jimaLetoTo: automated migration could break badly in mixed ide/sata or ide/scsi environments.<a href="#t14:14" class="time">14:14</a>
wwoodsIt is fedora policy. There's a million different ways you can screw up your system, and we can't be expected to compensate for all of them<a href="#t14:14" class="time">14:14</a>
LetoTolabels work less ideal when you install fc6 and fc7 on the same box in different partitions with root=LABEL=/<a href="#t14:14" class="time">14:14</a>
jeremyLetoTo: like I said, we should be detecting it now (I'm going to be testing in a little bit) and saying "please put the labels back"<a href="#t14:14" class="time">14:14</a>
wwoodsor rather - it should be<a href="#t14:14" class="time">14:14</a>
f13LetoTo: the installer detects that and doesn't create duplicate label names.<a href="#t14:15" class="time">14:15</a>
f13(usually)<a href="#t14:15" class="time">14:15</a>
jeremyLetoTo: anaconda won't set up two partitions on the same box with different labels...<a href="#t14:15" class="time">14:15</a>
jimacorrect, the second one is usually LABEL=/1 iirc<a href="#t14:15" class="time">14:15</a>
LetoTook, then no worries then.<a href="#t14:15" class="time">14:15</a>
jimaand /boot1<a href="#t14:15" class="time">14:15</a>
warrenjeremy, how does it handle RAID-1?<a href="#t14:15" class="time">14:15</a>
LetoToI just personally always change it, because it gave me more problems then it solved in the past. time to upgrade my tricks :)<a href="#t14:16" class="time">14:16</a>
warrenlabels in two partitions that are identical...<a href="#t14:16" class="time">14:16</a>
wwoodsIt'd be nice if we were using slightly more descriptive labels, like "f7_root"<a href="#t14:16" class="time">14:16</a>
nottingyou could just label it with the uuid<a href="#t14:16" class="time">14:16</a>
jeremywarren: raid superblocks give a unique identifier, so we used to mount them by that.  but then we fixed mount to dtrt with raid and label them now<a href="#t14:17" class="time">14:17</a>
jeremynotting: that's probably what we're going to end up doing for f8 :/<a href="#t14:17" class="time">14:17</a>
wwoodsheh yuck<a href="#t14:17" class="time">14:17</a>
nottingjeremy: or sha1 the fs superblock, or...<a href="#t14:17" class="time">14:17</a>
f13ah fun.<a href="#t14:17" class="time">14:17</a>
f13ok, any more Test4 status discussion?<a href="#t14:18" class="time">14:18</a>
wwoodsthere's a lot of mkinitrd weirdness lingering<a href="#t14:18" class="time">14:18</a>
wwoodsand a lot of sata/pata weirdness that I haven't gotten nailed down<a href="#t14:18" class="time">14:18</a>
wwoodsI'm hoping to go through the buglists and sort stuff out but so far there's no clear patterns<a href="#t14:18" class="time">14:18</a>
nottingf13: the comps stuff was approved. i'll get that done and send mail to rel-eng@fp.o<a href="#t14:18" class="time">14:18</a>
wwoodsjeremy: is the sata_sil fix you mentioned going to be in .309x (where x > 1 and not broken)<a href="#t14:19" class="time">14:19</a>
jeremywwoods: it's in 3094 I believe<a href="#t14:19" class="time">14:19</a>
wwoodscool<a href="#t14:19" class="time">14:19</a>
* notting wonders how he always has hardware whose storage drivers does not break<a href="#t14:19" class="time">14:19</a>
wwoodswe don't buy weirdo no-name laptops or build our own computers<a href="#t14:19" class="time">14:19</a>
jeremywwoods: probably<a href="#t14:20" class="time">14:20</a>
wwoodsI'd love it if we had free budget so when there's some hardware that some poor soul cannot get working<a href="#t14:20" class="time">14:20</a>
wwoodswe just buy one of the damn things<a href="#t14:20" class="time">14:20</a>
f13notting: I have hardware that breaks (:<a href="#t14:20" class="time">14:20</a>
wwoodsmake it work<a href="#t14:20" class="time">14:20</a>
f13I bought a Pogo box...<a href="#t14:20" class="time">14:20</a>
wwoodsand sell it on ebay when we're done<a href="#t14:20" class="time">14:20</a>
davejwwoods: and buy it again when we regress in an update? :)<a href="#t14:20" class="time">14:20</a>
wwoodsdavej: well, yes<a href="#t14:20" class="time">14:20</a>
wwoodsthere's that.<a href="#t14:20" class="time">14:20</a>
wwoodsheh<a href="#t14:20" class="time">14:20</a>
f13hrm.<a href="#t14:21" class="time">14:21</a>
davejwe'll never have complete coverage, but I agree we should at least try and get some of the more common-case hardware.<a href="#t14:21" class="time">14:21</a>
f13I'm seeing lots of "fun" with the extras multilib stuff.<a href="#t14:21" class="time">14:21</a>
jeremyf13: so the basic summary is that it's probably worth doing another tree in the near-ish future, but we're definitely not "there"<a href="#t14:21" class="time">14:21</a>
wwoodsyeah, I don't have any machines with ATI video, nor sata_nv, nor pata_amd, nor sata_sil<a href="#t14:21" class="time">14:21</a>
f13jeremy: ok.<a href="#t14:21" class="time">14:21</a>
wwoodsand I have no idea what other drivers may be flaky<a href="#t14:21" class="time">14:21</a>
jimawwoods: well, i'm not sure it's specific to those controllers.<a href="#t14:22" class="time">14:22</a>
LetoToi guess the mkinitrd on xenblk inclusion on dom0 died out on the list<a href="#t14:22" class="time">14:22</a>
Idea.png f13 changed the topic of #fedora-meeting to: Fedora Release Meeting -- Coordination of sub-groups<a href="#t14:22" class="time">14:22</a>
jimawwoods: err, sorry, wrong thread ;)<a href="#t14:22" class="time">14:22</a>
wwoodsjima: if it turns out there's a common cause for it all, I will be very very happy<a href="#t14:22" class="time">14:22</a>
jeremyI'm going to get a weekly rawhide live image up later today or tomorrow am and that should hopefully get us some more testing<a href="#t14:22" class="time">14:22</a>
wwoodsI completely love it when one fix closes 97 vaguely-related bugs<a href="#t14:22" class="time">14:22</a>
f13So rel-eng is the group that drives this meeting and these topics, but we'll want some known points of people to go to for various things.<a href="#t14:22" class="time">14:22</a>
nottingwwoods: my boxes are all ata_piix or pata/sata_via<a href="#t14:22" class="time">14:22</a>
f13wwoods for QA obviously, jeremy for installer and such, davej for kernel...<a href="#t14:23" class="time">14:23</a>
wwoodsnotting: same.. except for the ide_pmac (ha ha ha SPLODE)<a href="#t14:23" class="time">14:23</a>
davejnotting: ditto, though I got a bunch of jmicron controllers sent to me this week.<a href="#t14:23" class="time">14:23</a>
f13Should we start listing these on the ReleaseEngineering page?<a href="#t14:23" class="time">14:23</a>
jeremyf13: sure!<a href="#t14:24" class="time">14:24</a>
wwoodssounds like a good idea<a href="#t14:24" class="time">14:24</a>
davejpeople writing stuff about me on the internets? damn those guys..  meh, what's one more page. +1<a href="#t14:25" class="time">14:25</a>
f13how's this, if you'd like to represent some group for releng type discussions, feel free to add yourself to the wiki<a href="#t14:25" class="time">14:25</a>
f13hrm, no polecat<a href="#t14:25" class="time">14:25</a>
poelcati'm here :)<a href="#t14:25" class="time">14:25</a>
nottingf13: probably need to direct that to all said groups, some of which maynot be here right now<a href="#t14:25" class="time">14:25</a>
f13oh, I can't type right.<a href="#t14:25" class="time">14:25</a>
f13notting: yeah, broadcast announcement<a href="#t14:26" class="time">14:26</a>
mclasensorry for being late<a href="#t14:26" class="time">14:26</a>
f13probably need a "Representatives" section in the ReleaseEngineering page to distinguish between representatives and folks actually in releng<a href="#t14:26" class="time">14:26</a>
mclasenI hear that I missed the test4 status part of the meeting, can I still bring up one thing related to it ?<a href="#t14:26" class="time">14:26</a>
nottingsure<a href="#t14:27" class="time">14:27</a>
mclasendefault icon theme<a href="#t14:27" class="time">14:27</a>
nottingit's not echo?<a href="#t14:27" class="time">14:27</a>
mclasenI tried to improve the echo coverage by including svgs, but that turns out to be problematic<a href="#t14:27" class="time">14:27</a>
mclasenso I will have to take the svgs out again<a href="#t14:27" class="time">14:27</a>
mclasenand we did say at some point that we need to decide on going with echo or not around the last test release<a href="#t14:27" class="time">14:27</a>
wwoodsthe lightbulb does look a bit weird<a href="#t14:28" class="time">14:28</a>
davejmclasen: can you un-dent the trashcan icon whilst you're at it ? :)<a href="#t14:28" class="time">14:28</a>
mclasendavej: thats one of the svg issues<a href="#t14:28" class="time">14:28</a>
* lmacken strolls in from class<a href="#t14:28" class="time">14:28</a>
wwoodsand the trashcan still turns into the old bluecurve one when you drag a file over it<a href="#t14:28" class="time">14:28</a>
warrenEcho looks a lot like Tango...<a href="#t14:28" class="time">14:28</a>
wwoodsother than that, though, I'm pretty happy with Echo..<a href="#t14:28" class="time">14:28</a>
mclasenwwoods: thats a coverage issue; echo is missing that icon<a href="#t14:28" class="time">14:28</a>
lmackenwhen all else fails... go with the upstream (default gnome icons (tango based))<a href="#t14:29" class="time">14:29</a>
mclasentango is not the default gnome icon theme<a href="#t14:29" class="time">14:29</a>
lmackeni know, but the new gnome icons are tango-ish<a href="#t14:29" class="time">14:29</a>
mclasenbut the gnome-icon-theme got more and more tangoified over the last cycle<a href="#t14:29" class="time">14:29</a>
mclasenfor better or worse<a href="#t14:29" class="time">14:29</a>
nottingso, our choices are: 1) echo - new, lacking in coverage 2) bluecurve - works, but boring 3) upstream - not tested in fedora?<a href="#t14:30" class="time">14:30</a>
* f13 leans toward 2<a href="#t14:31" class="time">14:31</a>
nottingmclasen: how many packages need to change to change the default?<a href="#t14:31" class="time">14:31</a>
mclasenthe way I see it, we either declare echo good enough, or switch back to bluecurve<a href="#t14:31" class="time">14:31</a>
mclasen1 package<a href="#t14:31" class="time">14:31</a>
nottingjeremy: does anaconda need upd-instroot changes?<a href="#t14:31" class="time">14:31</a>
jeremypotentially<a href="#t14:31" class="time">14:31</a>
* jeremy goes to look<a href="#t14:32" class="time">14:32</a>
* lmacken would like to see us use gnome's default icons.. but i guess we already "bought in" to bluecurve and echo a while ago<a href="#t14:32" class="time">14:32</a>
jeremyit looks like it might work and switch back without anything needing doing<a href="#t14:32" class="time">14:32</a>
nottingare there political concerns with changing icons?<a href="#t14:32" class="time">14:32</a>
warrennotting, how so?<a href="#t14:32" class="time">14:32</a>
nottingi dunno. annoying the echo team, or something<a href="#t14:33" class="time">14:33</a>
wwoodsIs it considered important to have an all-new look for F7?<a href="#t14:33" class="time">14:33</a>
warrennotting, we can't possibly annoy the echo team more.<a href="#t14:33" class="time">14:33</a>
wwoodsI really like Echo thus far, personally, even though I expected not to<a href="#t14:33" class="time">14:33</a>
nottingwwoods: we have balloons!<a href="#t14:33" class="time">14:33</a>
mclasennotting: when we did switch to echo early in the cycle, we always said that we'd reevaluate late in the cycle<a href="#t14:34" class="time">14:34</a>
mclasenso I don't think people will be upset<a href="#t14:34" class="time">14:34</a>
wwoodsWe'll still be *including* it, right?<a href="#t14:34" class="time">14:34</a>
warrenWell, they will be, but they already are.<a href="#t14:34" class="time">14:34</a>
f13it's not our fault it isn't done yet<a href="#t14:34" class="time">14:34</a>
mclasenin fact, some people were offended by us "pushing" echo before it was ready<a href="#t14:34" class="time">14:34</a>
jeremymclasen: people will _always_ be upset :-)<a href="#t14:34" class="time">14:34</a>
mclasenright<a href="#t14:34" class="time">14:34</a>
mclasenthough art-list has become silent lately<a href="#t14:35" class="time">14:35</a>
jeremyI don't have a strong opinion in any direction<a href="#t14:35" class="time">14:35</a>
warrenmclasen, nobody is accountable to it<a href="#t14:35" class="time">14:35</a>
* jeremy is willing to support whatever mclasen thinks we should do <a href="#t14:35" class="time">14:35</a>
warrenmclasen, I wouldn't call a dozen mail/day silent<a href="#t14:35" class="time">14:35</a>
mclasenwwoods: sure, the discussion is only about default, not about inclusion<a href="#t14:35" class="time">14:35</a>
mclasenwarren: I meant that there is no constant flamewar anymore<a href="#t14:36" class="time">14:36</a>
jwb_gonewe're having a release team meeting?<a href="#t14:36" class="time">14:36</a>
wwoodsHow far away from "ready" is it?<a href="#t14:36" class="time">14:36</a>
f13jwb_gone: yes<a href="#t14:37" class="time">14:37</a>
jwb_gonef13, i thought they were on mondays?<a href="#t14:37" class="time">14:37</a>
jeremyjwb_gone: generally, yes.  on monday we said we wanted to just see where we were again on thursday<a href="#t14:37" class="time">14:37</a>
mclasenwwoods: there is a lot of work left to do<a href="#t14:37" class="time">14:37</a>
jwb_gonejeremy, f13: ok sorry<a href="#t14:37" class="time">14:37</a>
mclasenjeremy: I don't have a recommendation right now; need to consult with some people first; do you want to make this change for test4 ?<a href="#t14:38" class="time">14:38</a>
f13mclasen: if you can get an answer by tomorrow, sure, if not, no.<a href="#t14:39" class="time">14:39</a>
wwoodsmclasen: we've got less than a month until the release, so.. if you're fairly confident it could be ready by then, I'd be inclined to keep it<a href="#t14:39" class="time">14:39</a>
jeremymclasen: I think we need to have test4 match what we're doing for the final release<a href="#t14:39" class="time">14:39</a>
* jwb_gone agrees<a href="#t14:39" class="time">14:39</a>
f13sure, I'm persueded<a href="#t14:39" class="time">14:39</a>
wwoodsjeremy: +1<a href="#t14:39" class="time">14:39</a>
mclasenok, I put the question out on the art list, so I'll wait for some responses from the echo people<a href="#t14:39" class="time">14:39</a>
jeremytest4 needs to be _a lot_ more solid than the past few test releases<a href="#t14:40" class="time">14:40</a>
mclasenand try to give a recommendation by tomorrow<a href="#t14:40" class="time">14:40</a>
wwoodsif you're not sure it can be done for the release, let's turn it off now so that test4 matches final<a href="#t14:40" class="time">14:40</a>
jeremywe've gotten a fair bit of negative feedback with the previous test releases, and it'd be good to be able to follow up with a rocking test4<a href="#t14:40" class="time">14:40</a>
Idea.png f13 changed the topic of #fedora-meeting to: Release Engineering Meeting -- When should we branch CVS for F7?<a href="#t14:40" class="time">14:40</a>
nottingafter we merge<a href="#t14:40" class="time">14:40</a>
jwb_gonenotting, +1<a href="#t14:40" class="time">14:40</a>
f13notting: and if we don't get hardware in place in the next month?<a href="#t14:41" class="time">14:41</a>
jwb_gonei saw we merge anyway and deal with some pain<a href="#t14:41" class="time">14:41</a>
nottingf13: merge anyway<a href="#t14:41" class="time">14:41</a>
wwoodsThe People's Glorious Merging must be driven ever forward!<a href="#t14:42" class="time">14:42</a>
f13so then do we want to stake a date for merging with or without hardware?<a href="#t14:42" class="time">14:42</a>
f13and this is a more general question to.  At what point after the final test release do we want to branch CVS<a href="#t14:42" class="time">14:42</a>
* nirik thinks sooner is better than later... if only to blast extras with a thick layer of icy freeze. ;) <a href="#t14:43" class="time">14:43</a>
f13because there is going to be a lull where we don't want to introduce new things to CVS, but we're only taking specific bug fixes...<a href="#t14:43" class="time">14:43</a>
nottingnirik: extras: The Day After Tomorrow?<a href="#t14:43" class="time">14:43</a>
warrenWe need better automated enforcement so folks don't allow devel to fall behind FC-7<a href="#t14:43" class="time">14:43</a>
nottingf13: at test4 release seems practical to me<a href="#t14:44" class="time">14:44</a>
nottingin the general case<a href="#t14:44" class="time">14:44</a>
warrenhmm... rawhide pulls from FC-7...<a href="#t14:44" class="time">14:44</a>
warrenso there is no published tree of devel<a href="#t14:44" class="time">14:44</a>
warren?<a href="#t14:44" class="time">14:44</a>
f13yeah, devel builds wouldn't be published in a tree, but available through koji's web interface<a href="#t14:45" class="time">14:45</a>
f13notting: I could agree with that.  A brief period where some bugs are fixed on multiple branches, but allows for future development too<a href="#t14:45" class="time">14:45</a>
jeremyexcept that we want devel/ to have the F-7 stuff in teh general case<a href="#t14:46" class="time">14:46</a>
jeremyand forcing double builds after test4 seems like it's going to go poorly<a href="#t14:46" class="time">14:46</a>
warrenouch<a href="#t14:46" class="time">14:46</a>
f13how about at the final freeze?<a href="#t14:46" class="time">14:46</a>
f13either we lock CVS and developers take a vacation, or we have to do some fixes in two trees for a period of time.  Just want to find the right balance<a href="#t14:47" class="time">14:47</a>
LetoTothis process of devel becoming fc+1 is not always ideal. i guess it boils down to having unstable,stable,testing<a href="#t14:47" class="time">14:47</a>
jwb_gonef13, i say vacation<a href="#t14:47" class="time">14:47</a>
jeremyf13: yes, there is some period where it's the case.  but minimizing the amount of time is pretty important I think<a href="#t14:48" class="time">14:48</a>
jeremyLetoTo: that just means you always have to deal with three branches.  which isn't necessarily better<a href="#t14:48" class="time">14:48</a>
f13I'm also worried about lots of time where builds in devel/ aren't actually going anywhere and the content of devel/ being _wrong_ when we branch for F-7/<a href="#t14:49" class="time">14:49</a>
f13since from now until the end we're only taking packages by request.<a href="#t14:49" class="time">14:49</a>
LetoTojeremy: but it insures my development bleeding edge isnt suddenly declared the next release freeze<a href="#t14:49" class="time">14:49</a>
f13unless we want to change how the final test -> final release continuous freeze works<a href="#t14:49" class="time">14:49</a>
LetoTojeremy in my case. i have nsd-2.* in FC[456] <a href="#t14:49" class="time">14:49</a>
jeremyf13: yeah, not sure how to really resolve the differences :/<a href="#t14:49" class="time">14:49</a>
LetoToand nsd-3 in devel<a href="#t14:49" class="time">14:49</a>
LetoTonow suddenly, other people decided to make nsd-3 the new version by calling devel fc7<a href="#t14:50" class="time">14:50</a>
LetoToi understand it is less work then having all maintainers create their stuff in a new tree<a href="#t14:51" class="time">14:51</a>
f13LetoTo: maybe you weren't following the feature freeze and such dates.<a href="#t14:51" class="time">14:51</a>
LetoTof13: say i was, and i found nsd-3 was not ready?<a href="#t14:51" class="time">14:51</a>
LetoTowould i have to revoke stuff from devel?<a href="#t14:51" class="time">14:51</a>
f13probably.<a href="#t14:51" class="time">14:51</a>
f13epoch and revert<a href="#t14:51" class="time">14:51</a>
jeremyLetoTo: or get an early F-7 branch has been done in the past<a href="#t14:52" class="time">14:52</a>
LetoTojeremy: is that process documented on the wiki? It does sound like the better solution<a href="#t14:52" class="time">14:52</a>
f13so, opinions on branching at the final freeze date?<a href="#t14:52" class="time">14:52</a>
jeremyf13: that's probably the best compromise time<a href="#t14:52" class="time">14:52</a>
jeremyf13: and we should include thinking about this as we get back to some of the new scm thinking<a href="#t14:53" class="time">14:53</a>
f13nod<a href="#t14:53" class="time">14:53</a>
jeremyLetoTo: probably not...  but a branch request in bugzilla like you'd do for any other release should work<a href="#t14:53" class="time">14:53</a>
f13bein gable to have both F7 and devel at the same time, but in sync if there is no changes would be nice.<a href="#t14:53" class="time">14:53</a>
LetoTof13: yes, that would be best<a href="#t14:53" class="time">14:53</a>
f13so if you haven't actually changed devel, things you do in F-7 automatically echo to devel/<a href="#t14:54" class="time">14:54</a>
f13but thats hand waivy future land<a href="#t14:54" class="time">14:54</a>
jeremyanother concrete thing<a href="#t14:54" class="time">14:54</a>
jeremymikmod<a href="#t14:54" class="time">14:54</a>
jeremyit got bumped to a beta version with a new soname right before the freeze<a href="#t14:54" class="time">14:54</a>
jeremyvotes on reverting back to the older version?<a href="#t14:54" class="time">14:54</a>
notting+revert<a href="#t14:54" class="time">14:54</a>
jwb_gonerevert<a href="#t14:54" class="time">14:54</a>
f13+1 to revert.  Probably epoch+revert for upgrade path :/<a href="#t14:54" class="time">14:54</a>
f13(as much as that still bothers me)<a href="#t14:55" class="time">14:55</a>
* nirik notes that a few people already rebuilt against it, so we need to rebuild those again, or dump the updates there too. <a href="#t14:55" class="time">14:55</a>
f13icky tata<a href="#t14:55" class="time">14:55</a>
wwoodsthis is one of those things that would be OK if we were doing a mass-rebuild?<a href="#t14:55" class="time">14:55</a>
wwoodsor, at least, we wouldn't have noticed after the rebuild<a href="#t14:55" class="time">14:55</a>
f13wwoods: would have been ok before the feature freeze<a href="#t14:55" class="time">14:55</a>
warrenmikmod is core?<a href="#t14:56" class="time">14:56</a>
f13but soname bumping sounds like featury<a href="#t14:56" class="time">14:56</a>
wwoodsI.. hm<a href="#t14:56" class="time">14:56</a>
nirikwarren: yes, jnovy is the last one in the changelog<a href="#t14:56" class="time">14:56</a>
wwoodsbut it was pre-freeze?<a href="#t14:56" class="time">14:56</a>
warrenwwoods, test3 was feature freeze<a href="#t14:56" class="time">14:56</a>
jeremywwoods: it was before we locked down things.  but post feature freeze<a href="#t14:56" class="time">14:56</a>
wwoodsoh, pre test4 freeze<a href="#t14:56" class="time">14:56</a>
wwoodsboo<a href="#t14:56" class="time">14:56</a>
* wwoods votes revert<a href="#t14:57" class="time">14:57</a>
warrenhow many things need reverting?<a href="#t14:57" class="time">14:57</a>
wwoodsunless there's a really good reason<a href="#t14:57" class="time">14:57</a>
warrenmikmod isn't that widespread<a href="#t14:57" class="time">14:57</a>
wwoods(which was never presented to us)<a href="#t14:57" class="time">14:57</a>
jeremywarren: the version that's in rawhide right now is a beta<a href="#t14:57" class="time">14:57</a>
nirik<a href="http://www.redhat.com/archives/fedora-devel-list/2007-April/msg01047.html">http://www.redhat.com/archives/fedora-devel-list/2007-April/msg01047.html</a><a href="#t14:57" class="time">14:57</a>
warrenreverting might be ugly due to epoch.  mikmod really isn't dangerous.  Does the new version work?<a href="#t14:57" class="time">14:57</a>
wwoodsso they crammed in a beta with a new soname, post-feature freeze? uuuugly<a href="#t14:58" class="time">14:58</a>
jeremywwoods: yes<a href="#t14:58" class="time">14:58</a>
wwoodssounds like a LARTable (DART?) offense<a href="#t14:58" class="time">14:58</a>
jwb_goneepoch is just a damn number<a href="#t14:59" class="time">14:59</a>
f13warren: as much as I hate epochs, I hate having to rebuild a bunch of stuff after a freeze for a soname bump much more<a href="#t14:59" class="time">14:59</a>
wwoodsheh! we basically only use 'epoch' to fix stuff like this<a href="#t14:59" class="time">14:59</a>
f13for a beta<a href="#t14:59" class="time">14:59</a>
jwb_gonef13, +!<a href="#t14:59" class="time">14:59</a>
jwb_goneer, 1<a href="#t14:59" class="time">14:59</a>
wwoodsso maybe we need to keep track of 'total Epoch increase by developer'<a href="#t14:59" class="time">14:59</a>
warrenwwoods, public shaming scoreboard?<a href="#t14:59" class="time">14:59</a>
wwoodsindeed<a href="#t15:00" class="time">15:00</a>
* wwoods mostly kidding<a href="#t15:00" class="time">15:00</a>
f13every epoch gets you -1 points in karma<a href="#t15:00" class="time">15:00</a>
f13ok, anything else before we move on to regular meeting times?<a href="#t15:00" class="time">15:00</a>
Idea.png f13 changed the topic of #fedora-meeting to: Regular meeting schedule<a href="#t15:00" class="time">15:00</a>
wwoodsanyway yes, +1 for revert + epoch bump<a href="#t15:00" class="time">15:00</a>
f13I think most were OK with this time slot, on Mondays<a href="#t15:01" class="time">15:01</a>
jwb_gonemonday works best for me<a href="#t15:01" class="time">15:01</a>
f13extra meetings tossed in when releases are happening for more the state of the tree type things.<a href="#t15:01" class="time">15:01</a>
jeremyalthough it is a 3 year old beta<a href="#t15:01" class="time">15:01</a>
jeremy(sorry, network dropped)<a href="#t15:01" class="time">15:01</a>
nottingheh<a href="#t15:01" class="time">15:01</a>
f13jeremy: a 3 year old beta, and we're just getting it now?<a href="#t15:01" class="time">15:01</a>
nottingactive upstream project,there<a href="#t15:01" class="time">15:01</a>
jeremyyep!<a href="#t15:01" class="time">15:01</a>
* f13 sigs<a href="#t15:01" class="time">15:01</a>
f13er sighs<a href="#t15:01" class="time">15:01</a>
wwoodsMonday's good for me, and yes, I'm glad we had this meeting - twice weekly during RC-building phase is a good idea<a href="#t15:01" class="time">15:01</a>
f13ok, worksforme.  I'll mark it in the wiki that Mondays are our regular meeting slot<a href="#t15:02" class="time">15:02</a>
Idea.png f13 changed the topic of #fedora-meeting to: Mailing list for rel-eng?<a href="#t15:02" class="time">15:02</a>
f13I'm on the fence about this one.<a href="#t15:02" class="time">15:02</a>
warrenWhy not?<a href="#t15:02" class="time">15:02</a>
f13we have the rel-eng@ alias for requesting tags and such<a href="#t15:02" class="time">15:02</a>
f13we coul dmake it a list, but that's more a "please do something for me" not necessarily a "lets discuss this topic" or "here is the state of hte tree"<a href="#t15:03" class="time">15:03</a>
warrenIs there any reason to keep rel-eng private?<a href="#t15:03" class="time">15:03</a>
f13however using devel or maintainers might be too "noisy" to do tree state discussions, but then again... blah<a href="#t15:03" class="time">15:03</a>
f13warren: I don't think so<a href="#t15:03" class="time">15:03</a>
f13warren: only when we're discussion whether or not to add a new person,and private mail could be used for that<a href="#t15:03" class="time">15:03</a>
jeremystate of the tree being discussed on devel-list isn't a bad thing at all<a href="#t15:04" class="time">15:04</a>
* nirik thinks devel would be fine. <a href="#t15:04" class="time">15:04</a>
jeremyit would help if more people were aware :)<a href="#t15:04" class="time">15:04</a>
f13jeremy: sure, but would that cut out making our maintainers aware who avoid -devel due to the noise?<a href="#t15:04" class="time">15:04</a>
* poelcat says keep using devel and only create addition list if it really becomes a problem<a href="#t15:04" class="time">15:04</a>
f13or is that firmly in the "NotCare" area?<a href="#t15:04" class="time">15:04</a>
poelcatwe have a zillion mailing lists<a href="#t15:04" class="time">15:04</a>
jeremymore mailing lists just means more cross-posting of crap<a href="#t15:05" class="time">15:05</a>
f13poelcat: I know, I hate that, but then again I get all the mail anyway, i don't necessarily care where it comes from<a href="#t15:05" class="time">15:05</a>
jeremyand do we really need that? :)<a href="#t15:05" class="time">15:05</a>
f13no.<a href="#t15:05" class="time">15:05</a>
f13do we need to continue using rel-eng@ for anything?  Culd those requests go to devel?  Hard to tell if as a requestor you get enough +1s from the right people...<a href="#t15:05" class="time">15:05</a>
warrendevel is pretty noisy<a href="#t15:06" class="time">15:06</a>
f13which sort of falls into good ways of ack/nack ing requests<a href="#t15:06" class="time">15:06</a>
f13right now it's fuzzy<a href="#t15:06" class="time">15:06</a>
LetoTowith extras gone, dont you have a free slot? :)<a href="#t15:06" class="time">15:06</a>
jeremyeventually, we need to do something better than mail to an alias.  -devel isn't it.  but I don't want to try to figure that out today :)<a href="#t15:06" class="time">15:06</a>
f13if we make rel-eng into an open list, who's to say your +1 came from a rel-eng person and not random joe?<a href="#t15:06" class="time">15:06</a>
jwb_gonewe need some way to flag rel-eng questions<a href="#t15:06" class="time">15:06</a>
jwb_goneand responses<a href="#t15:06" class="time">15:06</a>
f13*cough* a wiki page?<a href="#t15:07" class="time">15:07</a>
nirikwiki page?<a href="#t15:07" class="time">15:07</a>
* f13 tries real hard to not suggest RT or ORTS<a href="#t15:07" class="time">15:07</a>
f13or flags<a href="#t15:07" class="time">15:07</a>
wwoodschannels on the mailing list?<a href="#t15:07" class="time">15:07</a>
jwb_gonewiki, rt, orts suck for discussion<a href="#t15:07" class="time">15:07</a>
wwoodsadd some code to koji to track tag requests?<a href="#t15:07" class="time">15:07</a>
f13oh yes, we totally need flags in koji<a href="#t15:07" class="time">15:07</a>
jeremywwoods: the buildsystem eventually does sound like a good place for it<a href="#t15:07" class="time">15:07</a>
* notting is fine w/requests to rel-eng@, tree status to -devel<a href="#t15:07" class="time">15:07</a>
f13k<a href="#t15:08" class="time">15:08</a>
jeremynotting: +1<a href="#t15:08" class="time">15:08</a>
wwoods+1<a href="#t15:08" class="time">15:08</a>
jwb_gone+1<a href="#t15:08" class="time">15:08</a>
f13should rel-eng become a semi-moderated mailing list that's easier to track/get archives from?<a href="#t15:08" class="time">15:08</a>
f13or continue with it being an alias for now?<a href="#t15:08" class="time">15:08</a>
jwb_gonealias until after f7<a href="#t15:09" class="time">15:09</a>
jwb_gonerevisit then<a href="#t15:09" class="time">15:09</a>
wwoodswhat happens when the accusations of us being an unfair shadowy cabal of blah blah blah in violation of german law start flying?<a href="#t15:09" class="time">15:09</a>
jwb_gonewwoods, spam them with the oh so many emails we have<a href="#t15:09" class="time">15:09</a>
f13warren: we ignore ralf?<a href="#t15:09" class="time">15:09</a>
f13er wwoods<a href="#t15:09" class="time">15:09</a>
Idea.png f13 changed the topic of #fedora-meeting to: Where to send meeting notes to?<a href="#t15:09" class="time">15:09</a>
f13-devel ?<a href="#t15:10" class="time">15:10</a>
f13I don't want to see cross posts of doom again.<a href="#t15:10" class="time">15:10</a>
jwb_gone-devel<a href="#t15:10" class="time">15:10</a>
warrenInternally, we found that posting meeting minutes to lists is a great way to have them ignored.<a href="#t15:10" class="time">15:10</a>
jwb_gonewarren, it's the only way the community gets to see them<a href="#t15:10" class="time">15:10</a>
jwb_gonethey need posting<a href="#t15:10" class="time">15:10</a>
wwoodsI'm fine with -devel, although I"d like it if there was a reliable way to find them.. common subject or something<a href="#t15:10" class="time">15:10</a>
warrensly said it is more effective to put minutes on a central webpage, and post notices that new minutes were posted.<a href="#t15:10" class="time">15:10</a>
f13warren: i don't care if they're ignored.  I care that we made an effort, posting to a list and in the wiki.<a href="#t15:11" class="time">15:11</a>
warrenThat avoids cross-posting of large amounts of text.<a href="#t15:11" class="time">15:11</a>
wwoodsisn't there some way of doing magical marking and subfiltering on mailman lists?<a href="#t15:11" class="time">15:11</a>
warrenwwoods, only child lists, I don't think we're using that.<a href="#t15:11" class="time">15:11</a>
f13wwoods: there is, but it isn't well used.<a href="#t15:11" class="time">15:11</a>
nirikthere is "topics"... but they don't help with archives, etc.<a href="#t15:11" class="time">15:11</a>
* notting thinks posted to the mailing list is fine as long as the minutes are reasonably concise<a href="#t15:11" class="time">15:11</a>
wwoodsah topics, that's it<a href="#t15:11" class="time">15:11</a>
notting10K of bug lists... not so much<a href="#t15:11" class="time">15:11</a>
f13heh<a href="#t15:12" class="time">15:12</a>
Idea.png f13 changed the topic of #fedora-meeting to: What do we report to FESCO?<a href="#t15:12" class="time">15:12</a>
wwoodswho would ever do something so insane?<a href="#t15:12" class="time">15:12</a>
f13this is a fun question.<a href="#t15:12" class="time">15:12</a>
jwb_gonef13, this is a pointless question<a href="#t15:12" class="time">15:12</a>
f13general decisions?<a href="#t15:12" class="time">15:12</a>
jwb_goneyes<a href="#t15:12" class="time">15:12</a>
f13jwb_gone: if only...<a href="#t15:12" class="time">15:12</a>
wwoodswhat sort of decisions does FESCO need special notification of?<a href="#t15:13" class="time">15:13</a>
f13RTFM?  (Read the Fine Minutes)<a href="#t15:13" class="time">15:13</a>
wwoodswhat kinds of things would be too important to just hope they read in the logs?<a href="#t15:13" class="time">15:13</a>
f13wwoods: maybe decisions to slip schedules, change how freezes are done, etc..?<a href="#t15:13" class="time">15:13</a>
jwb_gonewwoods, how we decide to handle freezes, slips, etc<a href="#t15:13" class="time">15:13</a>
jwb_goneoh, jinx f13<a href="#t15:13" class="time">15:13</a>
f13oh snap<a href="#t15:13" class="time">15:13</a>
jwb_gone:)<a href="#t15:14" class="time">15:14</a>
f13Ok, that's allthe topics I have for this meeting.<a href="#t15:14" class="time">15:14</a>
Idea.png f13 changed the topic of #fedora-meeting to: Open Floor<a href="#t15:14" class="time">15:14</a>
wwoodsI'm going to try (fingers crossed) to get RHEL QE involved with testing F7<a href="#t15:15" class="time">15:15</a>
wwoodswhich *might* result in a bunch of folks who are not intimately familiar with Fedora.. customs and traditions<a href="#t15:16" class="time">15:16</a>
wwoodsreporting bugs and such<a href="#t15:16" class="time">15:16</a>
wwoodsso, y'know, fair warning.<a href="#t15:16" class="time">15:16</a>
poelcati updated the feature listing... there was some discussion on how in/out certain features were<a href="#t15:16" class="time">15:16</a>
poelcati did the best I could given the info I had<a href="#t15:17" class="time">15:17</a>
f13wwoods: hrm, how upset are tey going to be that we aren't taking their trivial bugs in for F7 due to being in freeze?<a href="#t15:17" class="time">15:17</a>
wwoodsf13: ideally they won't care<a href="#t15:17" class="time">15:17</a>
jwb_gonepoelcat, thanks for that<a href="#t15:17" class="time">15:17</a>
f13poelcat: thank you for that.  I haven't looked over it myself due to traveling and such, but thanks!<a href="#t15:17" class="time">15:17</a>
wwoodsthey're not really emotionally involved since there's no horrific errata storm or anything<a href="#t15:17" class="time">15:17</a>
f13heh<a href="#t15:18" class="time">15:18</a>
wwoodsdo we consider firmware a 'feature'?<a href="#t15:18" class="time">15:18</a>
wwoodsor rathher - if we can get legal permission for extra firmware, can we include it or is that too distruptive?<a href="#t15:18" class="time">15:18</a>
jeremywwoods: I think if we can get it into test4, then we're good.  otherwise, it's going to be a lot harder<a href="#t15:20" class="time">15:20</a>
f13what jeremy said<a href="#t15:20" class="time">15:20</a>
jeremy(since by shipping firmware, we'll be making drivers "do something" on a lot more hardware... and if it just causes an oops, that's bad)<a href="#t15:20" class="time">15:20</a>
f13although your time to get it into test4 is very very short.<a href="#t15:20" class="time">15:20</a>
f13I _really_ want to spin a golden tree at some point tomorrow instead of on Monday<a href="#t15:20" class="time">15:20</a>
wwoodsyeah, if I hear back about the st firmware before test4, I'll bring it up again. otherwise.. F8<a href="#t15:20" class="time">15:20</a>
wwoodsso, s/test4/tomorrow/<a href="#t15:21" class="time">15:21</a>
f13is there anything else?<a href="#t15:22" class="time">15:22</a>
poelcatoff topic, but related... have we ever considered the possibility of an audio meeting, e.g. SIP call?<a href="#t15:23" class="time">15:23</a>
poelcati think it might provide for a faster meeting<a href="#t15:24" class="time">15:24</a>
f13Theoretically I could set up a bridge within RH concall system, but harder to share those minutes/logs<a href="#t15:25" class="time">15:25</a>
f13ok, meeting over.<a href="#t15:26" class="time">15:26</a>

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