From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 04-JUN-07
Spam-o-matic for rawhide
- the tool that generated the broken deps report at the end of the old rawhide emails
- DECISION:
- notting is going to get 'spam-o-matic' working for rawhide reports again
- including a full report of broken deps at the bottom of rawhide report mails like before the merge, and specific individual mails to maintainers with broken deps.
- f13 will let mike schwendnt know that this is coming.
Updates policy
- DECISION:
- rel-eng is proposing to FESCo that Update tool defaults to pushing to updates-testing
- Maintainer has option to "skip testing" and can do so without an "approver" roadblock.
- UPdate gets marked as "hot" somehow visually so that releng / qa can look over before pushing if necessary
Signing unsigned 7 packages
- DECSISON:
- To do some final Fedora 7 tree maintenance, replace unsigned packages with signed versions
- chmod 644 all the files (not dirs).
- Test with cached yum metadata to see what happens, push to mirror master, alert mirrors.
- Leave the i486/586/686/athlon stuff alone, fix those by updates.
Disable tagged builds from srpms in koji
- DECISION:
- Koji's little know ability to accept builds for tags directly from srpms rather than CVS checkouts will be disabled
- This will prevent people from getting builds into collections that aren't managed in CVS.
- This will NOT disrupt admins ability to bootstrap new arches.
Freeze Policy
- DECISION:
- Defer to a subsequent meeting
- Discuss release Freeze Requirments
- determine what they are
- document them
- determine how to best manage them
- get input from QA
- Start discussion on fedora-maintainers-list the write up results into a wiki page
IRC Transcript
 f13 changed the topic of #fedora-meeting to: RELENG-Meeting - Rawhide spam-o-matic - JesseKeating | <a href="#t13:04" class="time">13:04</a> | |
| f13 | Rolecall. poelcat, jwb, jeremy, spot, rdieter, wwoods, warren ping | <a href="#t13:04" class="time">13:04</a> |
|---|---|---|
| rdieter | here | <a href="#t13:05" class="time">13:05</a> |
| jwb | out today. crit sit in real life | <a href="#t13:05" class="time">13:05</a> |
| * spot raises his head and puts his head back down | <a href="#t13:05" class="time">13:05</a> | |
| dgilmore | f13: i'm here for mmcgrath to represent infrastructure | <a href="#t13:06" class="time">13:06</a> |
| f13 | Notting said he was out. | <a href="#t13:07" class="time">13:07</a> |
| rdieter | dgilmore: to represent the peeps from instra-town. word. | <a href="#t13:07" class="time">13:07</a> |
| rdieter | s/instr/infra/ | <a href="#t13:07" class="time">13:07</a> |
| f13 | alright, lets try to blow through this, we've got a lot to cover. | <a href="#t13:08" class="time">13:08</a> |
| warren | f13, who's decision is it if new added packages go directly into updates or updates-testing? | <a href="#t13:08" class="time">13:08</a> |
| warren | (It is either this group, or FESCO...) | <a href="#t13:08" class="time">13:08</a> |
| f13 | warren: that comes up later | <a href="#t13:08" class="time">13:08</a> |
| warren | ok | <a href="#t13:09" class="time">13:09</a> |
| * f13 waits for the wiki to load to link to the agenda | <a href="#t13:09" class="time">13:09</a> | |
| f13 | <a href="http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/Agenda">http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/Agenda</a> | <a href="#t13:09" class="time">13:09</a> |
| f13 | so Bill isn't here but I'm going to ask him to turn on spam-o-matic again for rawhide builds. Core builders are used to this. | <a href="#t13:09" class="time">13:09</a> |
| f13 | it's the tool that generated the broken deps report at the end of the old rawhide emails. | <a href="#t13:10" class="time">13:10</a> |
| f13 | notting: whoh, I thought you were out? | <a href="#t13:10" class="time">13:10</a> |
| notting | f13: greetings from the UNC PT waiting room | <a href="#t13:10" class="time">13:10</a> |
| f13 | heh | <a href="#t13:10" class="time">13:10</a> |
| f13 | notting: so, are there any blockers to turning spam-o-matic back on? | <a href="#t13:11" class="time">13:11</a> |
| f13 | notting: does it need modification to work with koji or is that done already? | <a href="#t13:11" class="time">13:11</a> |
| dgilmore | f13: is it free and open? | <a href="#t13:11" class="time">13:11</a> |
| f13 | dgilmore: it is, not sure if we've checked it into the git repo though | <a href="#t13:11" class="time">13:11</a> |
| notting | f13: 'making it work'. basically, mash would need to dump the deps out,and spam-o-matic would need to parse it, and query koji (using the api) instead of brew-via-command-line for owners | <a href="#t13:11" class="time">13:11</a> |
| f13 | it's basically just a repoclosure with goo in it to query koji to find out who owns the package and email them as well. | <a href="#t13:11" class="time">13:11</a> |
| dgilmore | f13: ok my only concern would be that whatever we use has to be free | <a href="#t13:11" class="time">13:11</a> |
| f13 | dgilmore: absolutely | <a href="#t13:12" class="time">13:12</a> |
| f13 | notting: hrm, didn't spam-o-matic work independantly of the compose tool in the past, or are you just looking to capatilize on the info we already have in the mash? | <a href="#t13:12" class="time">13:12</a> |
| notting | f13: no sense to run the dep check/closure twice if we don't have to | <a href="#t13:12" class="time">13:12</a> |
| f13 | nod | <a href="#t13:12" class="time">13:12</a> |
| notting | also, it was running on its own hacked-up version of repoclosure | <a href="#t13:13" class="time">13:13</a> |
| f13 | oh fun. | <a href="#t13:13" class="time">13:13</a> |
| f13 | notting: so do you want help with getting this going, or will htat just put things in your way? | <a href="#t13:13" class="time">13:13</a> |
| notting | i can look at it | <a href="#t13:13" class="time">13:13</a> |
| f13 | the key here is that the rawhide report will have the list of broken deps, and the individual maintainers will get "spam" in their inbox about it. | <a href="#t13:13" class="time">13:13</a> |
| * poelcat here | <a href="#t13:13" class="time">13:13</a> | |
| f13 | We can then have mschwendent remove rawhide from his reports. | <a href="#t13:14" class="time">13:14</a> |
| warren | notting, physical therapy? | <a href="#t13:14" class="time">13:14</a> |
| f13 | Is there anybody in attendance that thinks we should not go forward with this? | <a href="#t13:14" class="time">13:14</a> |
| jwb | question | <a href="#t13:14" class="time">13:14</a> |
| jwb | oh wait... this is rawhide | <a href="#t13:14" class="time">13:14</a> |
| jwb | nevermind | <a href="#t13:14" class="time">13:14</a> |
| rdieter | spam the broken-dep bastards. | <a href="#t13:14" class="time">13:14</a> |
| mclasen | will the individual spam be filtered ? or does everybody get the full report ? | <a href="#t13:14" class="time">13:14</a> |
| warren | f13, it sends mail to individuals right? | <a href="#t13:14" class="time">13:14</a> |
| notting | mclasen: full report goes in the rawhide report | <a href="#t13:14" class="time">13:14</a> |
| f13 | warren: yes, for their specific package(s) | <a href="#t13:15" class="time">13:15</a> |
| mclasen | notting: yes, I'm asking about the individual spam | <a href="#t13:15" class="time">13:15</a> |
| warren | f13, as long as the individual spam is only packages pertinent to themself | <a href="#t13:15" class="time">13:15</a> |
| f13 | mclasen: filtered IIRC. | <a href="#t13:15" class="time">13:15</a> |
| * bpepple pokes his head into the meeting. | <a href="#t13:15" class="time">13:15</a> | |
| jeremy | hit traffic on the way back from lunch... here now | <a href="#t13:15" class="time">13:15</a> |
| f13 | mclasen: didn't you get some from before the merge? | <a href="#t13:15" class="time">13:15</a> |
| mclasen | f13: you expect me to read all my mail ? | <a href="#t13:16" class="time">13:16</a> |
| notting | mclasen: it's just things that it thinks you're involved with (i.e., your packages, and things with deps on libraries that you maintain) | <a href="#t13:16" class="time">13:16</a> |
| mclasen | sounds great then | <a href="#t13:16" class="time">13:16</a> |
| nirik | Q: is there fc5/fc6 reports? extras push scripts should do that still right? | <a href="#t13:16" class="time">13:16</a> |
| jwb | nirik, those are being done again | <a href="#t13:16" class="time">13:16</a> |
| * jwb notes that he's really not here and a bot is replying for him | <a href="#t13:16" class="time">13:16</a> | |
| nirik | and for f7, bodhi should stop push on broken except for security pushes? | <a href="#t13:17" class="time">13:17</a> |
| * rdieter waves at jwb_bot. | <a href="#t13:17" class="time">13:17</a> | |
| f13 | nirik: that's a different subject. | <a href="#t13:17" class="time">13:17</a> |
| nirik | ok. sorry. ;) | <a href="#t13:17" class="time">13:17</a> |
| f13 | nirik: we're talking about the broken dep report for rawhide. | <a href="#t13:17" class="time">13:17</a> |
| * nirik goes back to lurking. | <a href="#t13:17" class="time">13:17</a> | |
| f13 | ok, I didn't see any objections, notting please 'make it work' at your convenience (: | <a href="#t13:18" class="time">13:18</a> |
| f13 | poelcat: for the record, notting is going to get 'spam-o-matic' working for rawhide reports again. This includes a full report of broken deps at the bottom of rawhide report mails like before the merge, and specific individual mails to maintainers with broken deps. | <a href="#t13:19" class="time">13:19</a> |
| f13 | I'll let mike schwendnt know that this is coming. | <a href="#t13:19" class="time">13:19</a> |
| poelcat | f13: thanks. summaries like that make the minutes easy to prepare :) | <a href="#t13:19" class="time">13:19</a> |
| f13 | poelcat: thought it would (: | <a href="#t13:19" class="time">13:19</a> |
| f13 changed the topic of #fedora-meeting to: RELENG-Meeting - Updates Policy - JesseKeating | <a href="#t13:19" class="time">13:19</a> | |
| f13 | lmacken: are you lurking? | <a href="#t13:19" class="time">13:19</a> |
| lmacken | indeed | <a href="#t13:20" class="time">13:20</a> |
| f13 | I think wwoods is on vacation which makes this topic a bit difficult to discuss. | <a href="#t13:20" class="time">13:20</a> |
| jeremy | yeah, he is on vacation | <a href="#t13:20" class="time">13:20</a> |
| warren | How much authority does wwoods alone have over this? | <a href="#t13:20" class="time">13:20</a> |
| warren | Surely rel-eng group and FESCO have some say. | <a href="#t13:20" class="time">13:20</a> |
| f13 | but the natives would like some policy around what things can be pushed, when they can go directly to updates without passing go, what criteria they should have before leaving -testing, etc... | <a href="#t13:20" class="time">13:20</a> |
| f13 | warren: we have some say sure, but I know that wwoods and his QA team is trying to come up with policy on the same subject, so we should cooporate. | <a href="#t13:21" class="time">13:21</a> |
| notting | use common sense? | <a href="#t13:21" class="time">13:21</a> |
| f13 | notting: if only :/ | <a href="#t13:21" class="time">13:21</a> |
| lmacken | heh, right now bodhi requires common sense. | <a href="#t13:21" class="time">13:21</a> |
| rdieter | notting: heresy! | <a href="#t13:21" class="time">13:21</a> |
| warren | Is it too dangerous to trust package owners to decide if it goes directly into updates or updates-testing? | <a href="#t13:21" class="time">13:21</a> |
| mclasen | notting: thats a scarce resource... | <a href="#t13:21" class="time">13:21</a> |
| warren | In the case of multi-package updates that are interdependent, it can be problematic to push everything at once no? | <a href="#t13:21" class="time">13:21</a> |
| notting | warren: sounds more problematic not to | <a href="#t13:21" class="time">13:21</a> |
| warren | notting, not to what? | <a href="#t13:22" class="time">13:22</a> |
| f13 | warren: I honestly don't think so. Bodhi should definitely default to updates-testing, but there should be an override they can do to get it to go to updates directly | <a href="#t13:22" class="time">13:22</a> |
| warren | f13, I can agree with that. | <a href="#t13:22" class="time">13:22</a> |
| f13 | warren: multi-package interdependant packages should be pushed all at once, regardless of where they go | <a href="#t13:22" class="time">13:22</a> |
| lmacken | f13: so along with a 'Push to Testing', maybe have a 'Skip testing' button, that then requires approval from releng ? | <a href="#t13:22" class="time">13:22</a> |
| warren | f13, lmacken: does bodhi still lack the multi-package update like core updates had | <a href="#t13:22" class="time">13:22</a> |
| warren | ? | <a href="#t13:22" class="time">13:22</a> |
| f13 | lmacken: I don't think we necessarily need to block on approval | <a href="#t13:22" class="time">13:22</a> |
| lmacken | warren: yes.. It is going to require some schema changes that I hope to do tonight | <a href="#t13:23" class="time">13:23</a> |
| warren | lmacken, cool | <a href="#t13:23" class="time">13:23</a> |
| f13 | lmacken: but perhaps flag those as "hot" updates so that when rel-eng goes to do a push they might scruitinize the update closer, we have the ability to 'deny' the update just by unchecking it in the push. | <a href="#t13:23" class="time">13:23</a> |
| * mclasen doesn't see why we have to allow skipping | <a href="#t13:23" class="time">13:23</a> | |
| f13 | mclasen: there are some valid cases where spending time in updates-testing won't really do any good. | <a href="#t13:23" class="time">13:23</a> |
| warren | more than half of packages really don't belong in updates-testing | <a href="#t13:24" class="time">13:24</a> |
| dgilmore | f13: i think only security and new packages go straight in the rest go through testing | <a href="#t13:24" class="time">13:24</a> |
| mclasen | does it justify a complicated policy with exceptions and approval ? | <a href="#t13:24" class="time">13:24</a> |
| warren | The package owner should really DTRT | <a href="#t13:24" class="time">13:24</a> |
| f13 | if a maintainer is abusing the ability to go directly to updates, that's a matter for his sponsor and FESCo to address. | <a href="#t13:24" class="time">13:24</a> |
| f13 | mclasen: nope, which is why I want to make it simple. | <a href="#t13:24" class="time">13:24</a> |
| f13 | mclasen: just offer the ability and call it good. | <a href="#t13:24" class="time">13:24</a> |
| warren | If a maintainer screws up consistently with bad judgment, then $HIGHER_POWER can lart. | <a href="#t13:24" class="time">13:24</a> |
| mclasen | f13: simplest is just to not have that feature... | <a href="#t13:24" class="time">13:24</a> |
| f13 | mclasen: which would mean not allowing it all together. | <a href="#t13:25" class="time">13:25</a> |
| warren | mclasen, you mean everything goes to updates-testing first? | <a href="#t13:25" class="time">13:25</a> |
| mclasen | rather than have a button and say "if you press this, we'll send the sponsors after you" | <a href="#t13:25" class="time">13:25</a> |
| dgilmore | mclasen: sometimes things need to go straight in | <a href="#t13:25" class="time">13:25</a> |
| warren | mclasen, sponsors after you is only if your judgment screws up. | <a href="#t13:25" class="time">13:25</a> |
| * f13 wonders if we're talking past eachother. | <a href="#t13:25" class="time">13:25</a> | |
| mclasen | dgilmore: My first question was for a concrete example of that being necessary | <a href="#t13:25" class="time">13:25</a> |
| dgilmore | mclasen: firefox security bug | <a href="#t13:26" class="time">13:26</a> |
| mclasen | oh, security, sure | <a href="#t13:26" class="time">13:26</a> |
| f13 | broken deps | <a href="#t13:26" class="time">13:26</a> |
| mclasen | 100% agreed on that | <a href="#t13:26" class="time">13:26</a> |
| warren | I believe the releng policy recommendation should be, "Package owner decides if it goes directly into updates or updates-testing. They are expected to use their best judgment about risk, and they are responsible for screwing up." | <a href="#t13:26" class="time">13:26</a> |
| nirik | how about a serious bug that makes something not work right for many users? | <a href="#t13:26" class="time">13:26</a> |
| dgilmore | mclasen: probably any remotely exploitable security bug | <a href="#t13:26" class="time">13:26</a> |
| mclasen | f13: the broken dep should not make it out of updates-testing in the first place... | <a href="#t13:26" class="time">13:26</a> |
| rdieter | dgilmore: security updates already bypass testing, don't they? | <a href="#t13:26" class="time">13:26</a> |
| f13 | mclasen: it may due to security | <a href="#t13:26" class="time">13:26</a> |
| lmacken | rdieter: yes | <a href="#t13:26" class="time">13:26</a> |
| mclasen | I'm just contesting that we need to allow non-security updates directly in | <a href="#t13:26" class="time">13:26</a> |
| f13 | mclasen: there were a number of complains by many people with specific cases, lots of library updates that there aren't really test cases / testers for | <a href="#t13:27" class="time">13:27</a> |
| dgilmore | rdieter: they don't have to right now but security and a new package should be the only exceptions to testing | <a href="#t13:27" class="time">13:27</a> |
| mclasen | anyway, if you need to add that button to make valuable contributors happy, then go ahead | <a href="#t13:27" class="time">13:27</a> |
| lmacken | f13: i do plan on adding support for defining testing instructions, if that makes any difference | <a href="#t13:27" class="time">13:27</a> |
| mclasen | I just won't use it... | <a href="#t13:27" class="time">13:27</a> |
| nirik | yeah, thats the common one: firefox security update. Other updates needed to keep broken deps from happening. They should be allowed right? | <a href="#t13:27" class="time">13:27</a> |
| f13 | mclasen: I appreciate that | <a href="#t13:27" class="time">13:27</a> |
| warren | mclasen, the vast majority of Extras really would not benefit from an enforced testing period, and this adds lots of additional process overhead for those maintainers who maintain dozens of packages. | <a href="#t13:27" class="time">13:27</a> |
| warren | We really must trust the package maintainers more here. | <a href="#t13:28" class="time">13:28</a> |
| f13 | warren: that's a really broad and disparaging comment | <a href="#t13:28" class="time">13:28</a> |
| jeremy | warren: I think there _should_ be value for the packages being in updates-testing | <a href="#t13:28" class="time">13:28</a> |
| warren | f13, it is the reality. | <a href="#t13:28" class="time">13:28</a> |
| mclasen | warren: thats the kind of comment that I feared | <a href="#t13:28" class="time">13:28</a> |
| f13 | warren: reality is what you make of it. | <a href="#t13:28" class="time">13:28</a> |
| nirik | I think the reccomendation is that testing should be used unless the maintainer has a good reason not to. | <a href="#t13:28" class="time">13:28</a> |
| f13 | warren: if you state there is no value, then sure, people believe there is no value and don't even attempt to add value. | <a href="#t13:28" class="time">13:28</a> |
| warren | nirik, +1 | <a href="#t13:28" class="time">13:28</a> |
| jeremy | that said, at the moment, there isn't necessarily a lot of value there. as we build up more testing and QA stuff around updates-testing, hopefully people will see the value even more | <a href="#t13:28" class="time">13:28</a> |
| * rdieter agrees is mclasen, having run my own repo, and having been burnt by skipping testing a few times when it didn't *seem* necessary. | <a href="#t13:28" class="time">13:28</a> | |
| mclasen | warren: if it looks as if former extras will in general just skip testing altogether, then we should not add the button | <a href="#t13:28" class="time">13:28</a> |
| jeremy | nirik: +1 | <a href="#t13:29" class="time">13:29</a> |
| lmacken | if bodhi can automatically submit updates to Stable after $TIMEOUT, then I don't see any issue with throwing updates at it.. | <a href="#t13:29" class="time">13:29</a> |
| lmacken | or $APPROVALs | <a href="#t13:29" class="time">13:29</a> |
| warren | lmacken, that would be good. | <a href="#t13:29" class="time">13:29</a> |
| warren | Is there a required length of time something must sit in updates-testing? | <a href="#t13:29" class="time">13:29</a> |
| lmacken | that's something we need to agree upon | <a href="#t13:29" class="time">13:29</a> |
| f13 | lmacken: I would hope that getting an update to go directly to updates without passing go wouldn't need somebody to "sign off" on it. | <a href="#t13:29" class="time">13:29</a> |
| lmacken | some people said a week.. some say 3 - 4 days :\ | <a href="#t13:29" class="time">13:29</a> |
| nirik | I think letting maintainers should have a bypass, but default should be testing. Otherwise everyone will bypass it and it will be useless. ;( | <a href="#t13:29" class="time">13:29</a> |
| f13 | if we're going to trust the maintainer, lets trust th emaintainer. | <a href="#t13:30" class="time">13:30</a> |
| warren | Say I want a trivial update that is obviously correct to go in, that corrects a typo in a cron script that spams users due to a syntax error. Do I really want that to sit in updates-testing for 7 dys? | <a href="#t13:30" class="time">13:30</a> |
| f13 | nirik: indeed. | <a href="#t13:30" class="time">13:30</a> |
| f13 | warren: you shouldn't have to no | <a href="#t13:30" class="time">13:30</a> |
| f13 | warren: positive feedback should override a default timeout. | <a href="#t13:30" class="time">13:30</a> |
| lmacken | f13: well.. releng / qa should always be able to nudge stuff through | <a href="#t13:30" class="time">13:30</a> |
| warren | We really need to trust the package maintainer to some degree. I would argue that such trivial and obviously correct updates should skip testing. | <a href="#t13:30" class="time">13:30</a> |
| nirik | warren: yeah, thats an exampe of something the maintainer should be allowed to push. Although it should have been caught in testing for the previous release, right? | <a href="#t13:30" class="time">13:30</a> |
| warren | We need to ENCOURAGE use of updates-testing in most cases, but TRUST the maintainer to DTRT. | <a href="#t13:30" class="time">13:30</a> |
| f13 | lmacken: releng always has the ability to "opt out" of pushing an update. However there hsouldn't be a roadblock to the maintainer getting it to the "push" stage of updates. | <a href="#t13:31" class="time">13:31</a> |
| warren | nirik, I screwed that up for spamassassin in RHEL5 somehow. Testing missed it. | <a href="#t13:31" class="time">13:31</a> |
| nirik | really? was that the sa-update thing? That should have been caught by a day in updates-testing I would think... | <a href="#t13:32" class="time">13:32</a> |
| lmacken | f13: so you're saying anyone should be able to submit anything to Stable at any time ? | <a href="#t13:32" class="time">13:32</a> |
| f13 | Proposal: | <a href="#t13:32" class="time">13:32</a> |
| warren | nirik, it happened during FC6test, there was no updates-testing | <a href="#t13:32" class="time">13:32</a> |
| warren | nirik, I accepted a user submitted patch during a rush and got burned. | <a href="#t13:32" class="time">13:32</a> |
| nirik | yeah. ;( Now there is tho... so thats a great case of updates-testing being good. Someone would have notified about it... | <a href="#t13:33" class="time">13:33</a> |
| f13 | Update tool defaults to pushing to updates-testing. Maintainer has option to "skip testing" and can do so without an "approver" roadblock. UPdate gets marked as "hot" somehow visualyl so that releng / qa can look over before pushing if necessary. | <a href="#t13:33" class="time">13:33</a> |
| jwb | f13, +1 | <a href="#t13:33" class="time">13:33</a> |
| jeremy | f13: +1 | <a href="#t13:33" class="time">13:33</a> |
| rdieter | f13: +1 | <a href="#t13:33" class="time">13:33</a> |
| lmacken | f13: sounds good to me | <a href="#t13:33" class="time">13:33</a> |
| lmacken | so a 'Skip testing' checkbox in the new update submission for m? | <a href="#t13:33" class="time">13:33</a> |
| * nirik thinks that sounds great. | <a href="#t13:33" class="time">13:33</a> | |
| warren | f13, "hot" could just mean zero days in updates-testing, and it could be colored such. +1 in principle | <a href="#t13:33" class="time">13:33</a> |
| f13 | lmacken: or how about 'push to updates-testing' followed by 'skip updates-testing' ? | <a href="#t13:34" class="time">13:34</a> |
| lmacken | f13: WFM | <a href="#t13:34" class="time">13:34</a> |
| warren | f13, color code! 0 days red, 1-3 days orange, 4-6 days yellow | <a href="#t13:34" class="time">13:34</a> |
| f13 | warren: but I want my bike shed to be blue! | <a href="#t13:34" class="time">13:34</a> |
| notting | rpm threat level is: red | <a href="#t13:34" class="time">13:34</a> |
| warren | And we adjust the threat level for political reasons as needed. | <a href="#t13:34" class="time">13:34</a> |
| f13 | whaever we do to mark it, please don't break my ability to highlight the list of updates to go out and paste them into a \n seperated list. | <a href="#t13:34" class="time">13:34</a> |
| * spot puts all his liquid and gel packages in a quart ziploc bag | <a href="#t13:35" class="time">13:35</a> | |
| f13 | So it looks like that proposal passed. | <a href="#t13:35" class="time">13:35</a> |
| lmacken | f13: hahah.. damn screen scrapers!! | <a href="#t13:35" class="time">13:35</a> |
| jwb | f13, do we want to run it by FESCo now? | <a href="#t13:35" class="time">13:35</a> |
| f13 | If we notice repeated abuse we can take it up with maintainer+sponsor, potentially even FESCo | <a href="#t13:35" class="time">13:35</a> |
| f13 | jwb: yes, this should be proposed to FESCo | <a href="#t13:35" class="time">13:35</a> |
| warren | This is the official releng recommendation to be ratified by FESCo | <a href="#t13:36" class="time">13:36</a> |
| jwb | should just be a quick review and ack from them | <a href="#t13:36" class="time">13:36</a> |
| lmacken | heh, i was just about to implement it :( | <a href="#t13:36" class="time">13:36</a> |
| jwb | lmacken, go ahead. just don't make it live yet | <a href="#t13:36" class="time">13:36</a> |
| lmacken | k | <a href="#t13:36" class="time">13:36</a> |
| f13 | lmacken: haha, well you can do it on your test platform | <a href="#t13:36" class="time">13:36</a> |
| warren | Do we agree on a 7 day countdown for updates-testing by default? | <a href="#t13:36" class="time">13:36</a> |
| jwb | f13, and we should send that to the list as well | <a href="#t13:36" class="time">13:36</a> |
| f13 | poelcat: For the record, rel-eng is proposing to FESCo that Update tool defaults to pushing to updates-testing. Maintainer has option to "skip testing" and can do so without an "approver" roadblock. UPdate gets marked as "hot" somehow visualyl so that releng / qa can look over before pushing if necessary. | <a href="#t13:36" class="time">13:36</a> |
| f13 | warren: I want to leave that up to QA | <a href="#t13:37" class="time">13:37</a> |
| warren | Idea: 7 day countdown for updates-testing by default. Interface allows an emergency "WAIT!!!" button for people to click if a test update is really fubar. | <a href="#t13:37" class="time">13:37</a> |
| mclasen | I think one proposal on the mailing list made a lot of sense, to write down an update policy independent of any tools that we use | <a href="#t13:37" class="time">13:37</a> |
| mclasen | but that probably has to wait for wwoods return... | <a href="#t13:37" class="time">13:37</a> |
| f13 | mclasen: indeed. Policy should not be goverened by tools, instead tools should be written to apply the policy (: | <a href="#t13:38" class="time">13:38</a> |
| warren | f13, as an implementation detail, the color code of hotness really may help. At a glance you see how long something has been in testing before you push. | <a href="#t13:38" class="time">13:38</a> |
| jwb | work that with lmacken | <a href="#t13:38" class="time">13:38</a> |
| * warren likes "color code of hotness" | <a href="#t13:38" class="time">13:38</a> | |
| f13 | warren: absolutely. That's eye candy | <a href="#t13:38" class="time">13:38</a> |
| lmacken | patches welcome! | <a href="#t13:38" class="time">13:38</a> |
| f13 | heh | <a href="#t13:38" class="time">13:38</a> |
| f13 | as for the rest of updates policy, lets see how far this gets us and discuss more specific things as they fall out of the mailing list and out of QA/FESCo. OK? | <a href="#t13:39" class="time">13:39</a> |
| lmacken | sounds good.. so is the Testing -> Stable move still going to be manual? or should bodhi move them after a timeout ? | <a href="#t13:40" class="time">13:40</a> |
| notting | lmacken: tbd? | <a href="#t13:40" class="time">13:40</a> |
| lmacken | notting: k | <a href="#t13:40" class="time">13:40</a> |
| jwb | yeah, tbd | <a href="#t13:40" class="time">13:40</a> |
| f13 | lmacken: we didn't really talk about that. | <a href="#t13:40" class="time">13:40</a> |
| f13 | tbd. | <a href="#t13:40" class="time">13:40</a> |
| notting | lmacken: actually, coding up the ability to *have* a timeout that moves things could be useful | <a href="#t13:40" class="time">13:40</a> |
| f13 | ok, next topic | <a href="#t13:40" class="time">13:40</a> |
| warren | lmacken, I'll start a theoretical discussion about that on list now | <a href="#t13:41" class="time">13:41</a> |
| f13 changed the topic of #fedora-meeting to: RELENG-Meeting - Signing unsigned 7 packages - JesseKeating | <a href="#t13:41" class="time">13:41</a> | |
| mclasen | lmacken: at the very least, we should have the same spam-after-timeout that the old tool had | <a href="#t13:41" class="time">13:41</a> |
| lmacken | warren: thanks | <a href="#t13:41" class="time">13:41</a> |
| f13 | (inserting topic that wasn't on the wiki) | <a href="#t13:41" class="time">13:41</a> |
| mclasen | lmacken: getting those reminders was very useful to me | <a href="#t13:41" class="time">13:41</a> |
| lmacken | mclasen: yeah, I need to hack up some nagmail for bodhi | <a href="#t13:41" class="time">13:41</a> |
| f13 | mclasen: +1 good idea. | <a href="#t13:41" class="time">13:41</a> |
| f13 | Ok, so we all know that there were a number of unsigned packages that leaked into the Everything trees | <a href="#t13:41" class="time">13:41</a> |
| f13 | My plan to fix this was to make sure they're signed within the koji store and do another mash of the f7-final tag. Then rsync to the tree I have staged to make sure only the expected things changed, push to mirror masters, and alert mirrors that this content change happened. | <a href="#t13:42" class="time">13:42</a> |
| f13 | Any objections to this plan? | <a href="#t13:42" class="time">13:42</a> |
| notting | works for me. sorry about the bug. | <a href="#t13:42" class="time">13:42</a> |
| f13 | (there is more to come, I just want to get this part cleared first) | <a href="#t13:43" class="time">13:43</a> |
| dgilmore | f13: none from me | <a href="#t13:43" class="time">13:43</a> |
| jwb | sounds fine | <a href="#t13:43" class="time">13:43</a> |
| f13 | skvidal thinks we'll be OK with the nvr not changing, but the metdata/checksum changing. | <a href="#t13:43" class="time">13:43</a> |
| jeremy | have we found the bug that caused this to happen in the first place? | <a href="#t13:43" class="time">13:43</a> |
| jeremy | (so that we can avoid it in the future) | <a href="#t13:43" class="time">13:43</a> |
| notting | jeremy: mash assumed that if koji had the signature, it had a signed rpm | <a href="#t13:43" class="time">13:43</a> |
| warren | Only problem with this, is all existing users must wipe their yum caches in order to recover. | <a href="#t13:44" class="time">13:44</a> |
| jeremy | ok, fine by me then | <a href="#t13:44" class="time">13:44</a> |
| rdieter | I assume that assumption was incorrect? | <a href="#t13:44" class="time">13:44</a> |
| notting | rdieter: correct. it has since been fixed | <a href="#t13:44" class="time">13:44</a> |
| warren | If you do it with an Update instead, then yum can recover without a yum cache wipe. | <a href="#t13:44" class="time">13:44</a> |
| f13 | warren: actually I think skvidal and jbowes think that bug in yum is fixed. | <a href="#t13:44" class="time">13:44</a> |
| warren | since when? | <a href="#t13:44" class="time">13:44</a> |
| warren | hm | <a href="#t13:44" class="time">13:44</a> |
| jeremy | that should be easy to verify | <a href="#t13:44" class="time">13:44</a> |
| f13 | I talked to them about it last week when I was formulating this plan, but I havne't tested to verify | <a href="#t13:45" class="time">13:45</a> |
| f13 | We should test before pushing anywhere | <a href="#t13:45" class="time">13:45</a> |
| warren | fortunately the number of affected packages is small | <a href="#t13:45" class="time">13:45</a> |
| f13 | indeed. | <a href="#t13:45" class="time">13:45</a> |
| warren | gallery2 (the majority) will likely have an update naturally anyway | <a href="#t13:46" class="time">13:46</a> |
| f13 | Anyway, so with testing I'll go forward with that plan. | <a href="#t13:46" class="time">13:46</a> |
| f13 | but the second part of this is a bit more controversial. | <a href="#t13:46" class="time">13:46</a> |
| f13 | due to a misthought out patch to koji, there are a number of packages that were built not just for i386, but for i486, i586, i686, athlon. | <a href="#t13:47" class="time">13:47</a> |
| dgilmore | opps | <a href="#t13:47" class="time">13:47</a> |
| f13 | And they're sitting in the Everything tree, and in the pungi spins | <a href="#t13:47" class="time">13:47</a> |
| notting | f13: qt4, pm-utils... what else? | <a href="#t13:47" class="time">13:47</a> |
| f13 | libbeagle | <a href="#t13:47" class="time">13:47</a> |
| f13 | beagle-ui | <a href="#t13:48" class="time">13:48</a> |
| f13 | beagle basically | <a href="#t13:48" class="time">13:48</a> |
| f13 | notting: I don't see qt4 as built like htat | <a href="#t13:48" class="time">13:48</a> |
| notting | f13: that may have been only in rawhide | <a href="#t13:48" class="time">13:48</a> |
| f13 | just pm-utils, beagle. | <a href="#t13:48" class="time">13:48</a> |
| f13 | pm-utils is particularly bad as radeontool inclusion is only on i386, not the other arches | <a href="#t13:49" class="time">13:49</a> |
| f13 | so some people will get pm-utils but not radeon-tool. | <a href="#t13:49" class="time">13:49</a> |
| notting | f13: that you'd want to force upgrades on, so i'd do an update | <a href="#t13:49" class="time">13:49</a> |
| f13 | notting: I wanted to for that yes. | <a href="#t13:49" class="time">13:49</a> |
| f13 | so the question though is do we just leave those in the tree, while we're doing signing maint, or do we scrub them? | <a href="#t13:49" class="time">13:49</a> |
| f13 | both beagle and pm-utils will probably get updates soon anyway (and we'll force the issue with pm-utils) | <a href="#t13:50" class="time">13:50</a> |
| f13 | I'm more in favor of just leaving them and changing as little as possible. | <a href="#t13:50" class="time">13:50</a> |
| * jeremy votes for leave them | <a href="#t13:50" class="time">13:50</a> | |
| rdieter | f13, notting: qt4-4.3.0-1 was that way (used ExclusiveArch: %{ix86}) qt4-4.3.0-2 is better. | <a href="#t13:50" class="time">13:50</a> |
| f13 | (oh and while we're doing tree stuff, chmod 644 *.rpm) | <a href="#t13:50" class="time">13:50</a> |
| f13 | rdieter: that qt didn't land in f7 it appears. | <a href="#t13:50" class="time">13:50</a> |
| notting | rdieter: qt4 with 4 or 5 extra arches takes a loooooong time to push :) | <a href="#t13:51" class="time">13:51</a> |
| rdieter | f13: just rawhide. | <a href="#t13:51" class="time">13:51</a> |
| rdieter | notting: even longer to build. | <a href="#t13:51" class="time">13:51</a> |
| f13 | Proposal: To do some final tree maintenance, replace unsigned packages with signed versions, and chmod 644 all the files (not dirs). Test with cached yum metadata to see what happens, push to mirror master, alert mirrors. Leave the i486/586/686/athlon stuff alone, fix those by updates. | <a href="#t13:52" class="time">13:52</a> |
| rdieter | f13: +1 | <a href="#t13:53" class="time">13:53</a> |
| notting | f13: you may not have to actually chmod | <a href="#t13:53" class="time">13:53</a> |
| notting | f13: i thing sometime between <compose> and <now> chmod was run over the koji dirs | <a href="#t13:53" class="time">13:53</a> |
| f13 | notting: ok, so rsync may pick up those changes when I mash. | <a href="#t13:54" class="time">13:54</a> |
| f13 | since I"m not seeing any - votes, we'll count this as agreed. | <a href="#t13:56" class="time">13:56</a> |
| f13 | poelcat: For the record, To do some final Fedora 7 tree maintenance, replace unsigned packages with signed versions, and chmod 644 all the files (not dirs). Test with cached yum metadata to see what happens, push to mirror master, alert mirrors. Leave the i486/586/686/athlon stuff alone, fix those by updates. | <a href="#t13:56" class="time">13:56</a> |
| f13 | Next topic, another insertion. | <a href="#t13:56" class="time">13:56</a> |
| f13 | mbonnet: you around? | <a href="#t13:56" class="time">13:56</a> |
| warren | f13, existing install images wont have a problem with the install tree changing? | <a href="#t13:57" class="time">13:57</a> |
| mbonnet | f13: yo | <a href="#t13:57" class="time">13:57</a> |
| warren | f13, (boot from boot.iso and do a network install, it wont care that things changed?) | <a href="#t13:57" class="time">13:57</a> |
| f13 changed the topic of #fedora-meeting to: RELENG-Meeting - Disable tagged builds from srpms in koji - MikeBonnet | <a href="#t13:57" class="time">13:57</a> | |
| f13 | warren: Everything trees are not installable for 7 | <a href="#t13:57" class="time">13:57</a> |
| warren | f13, ah. ok. | <a href="#t13:57" class="time">13:57</a> |
| jwb | huh on /topic? | <a href="#t13:58" class="time">13:58</a> |
| f13 | warren: only usable as add-on repos from other install media. Too many moving parts at the deadline to have them tested as installable nad still release for LinuxTag | <a href="#t13:58" class="time">13:58</a> |
| f13 | Right now, koji will allow you to build for a tag directly from an srpm | <a href="#t13:58" class="time">13:58</a> |
| notting | f13: um, if you point boot.iso at it, it does install :) | <a href="#t13:58" class="time">13:58</a> |
| f13 | notting: when did you try that? Maybe it does becuase I copied the Fedora spins' .discinfo file intot he tree | <a href="#t13:58" class="time">13:58</a> |
| f13 | what we'd like to do is turn off Koji's ability to do this, making any build directly from srpm only --scratch builds. | <a href="#t13:59" class="time">13:59</a> |
| f13 | any build that will be tagged and imported will have to have come from a CVS checkout. | <a href="#t13:59" class="time">13:59</a> |
| jwb | f13, ew on that. tag builds should only be built from cvs and srpm should only work for --scratch | <a href="#t13:59" class="time">13:59</a> |
| notting | f13: a while ago | <a href="#t13:59" class="time">13:59</a> |
| dgilmore | f13: we need that | <a href="#t13:59" class="time">13:59</a> |
| f13 | Not many people know that koji can build from srpms in this way for tags, so we want to fix it now before it gets abused. | <a href="#t13:59" class="time">13:59</a> |
| jwb | dgilmore, need it for what? | <a href="#t13:59" class="time">13:59</a> |
| warren | f13, wow. I didn't know we allowed that. Definitely. | <a href="#t14:00" class="time">14:00</a> |
| dgilmore | jwb: we cant allow people to build for releases and not check there build into cvs | <a href="#t14:00" class="time">14:00</a> |
| mbonnet | one proposal was to allow only admins to build from srpm as non--scratch | <a href="#t14:00" class="time">14:00</a> |
| f13 | should be a no brainer, but we wanted to be transparent in making decisions/changes. | <a href="#t14:00" class="time">14:00</a> |
| jwb | dgilmore, oh ok. i misunderstood your "need it" statement. sounds like everyone is agreeing so far | <a href="#t14:00" class="time">14:00</a> |
| f13 | Proposal: Disable Koji's ability to tag/import packages that were built directly from srpm instead of from a CVS checkout. | <a href="#t14:01" class="time">14:01</a> |
| f13 | +1 | <a href="#t14:01" class="time">14:01</a> |
| jwb | +1 | <a href="#t14:01" class="time">14:01</a> |
| warren | +1 | <a href="#t14:01" class="time">14:01</a> |
| jeremy | +1 | <a href="#t14:01" class="time">14:01</a> |
| notting | f13: wait a sec | <a href="#t14:01" class="time">14:01</a> |
| f13 | yes? | <a href="#t14:01" class="time">14:01</a> |
| notting | f13: secondary architecture population | <a href="#t14:02" class="time">14:02</a> |
| jwb | can do imports | <a href="#t14:02" class="time">14:02</a> |
| f13 | notting: Admin override | <a href="#t14:02" class="time">14:02</a> |
| notting | f13: as long as that still works, i'm +1 | <a href="#t14:02" class="time">14:02</a> |
| jwb | yeah | <a href="#t14:02" class="time">14:02</a> |
| mbonnet | notting: arbitrary packages can still be imported by admins | <a href="#t14:02" class="time">14:02</a> |
| f13 | mbonnet: can we still import builds? | <a href="#t14:02" class="time">14:02</a> |
| f13 | ok. | <a href="#t14:02" class="time">14:02</a> |
| jwb | good thinking notting | <a href="#t14:02" class="time">14:02</a> |
| f13 | poelcat: For the record, Koji's little know ability to accept builds for tags directly from srpms rather than CVS checkouts will be disabled. This will prevent people from getting builds into collections that aren't managed in CVS. This will NOT disrupt admins ability to bootstrap new arches. | <a href="#t14:03" class="time">14:03</a> |
| f13 | Next is going to be a /fun/ one. | <a href="#t14:03" class="time">14:03</a> |
| f13 | although we're at an hour already. | <a href="#t14:03" class="time">14:03</a> |
| f13 | Our next topic was to be Freeze Policy, which could be a fairly lengthy topic. | <a href="#t14:04" class="time">14:04</a> |
| f13 | So we cna talk about it now and go over our meeting time, or we can punt for next week with more discussion on list? | <a href="#t14:04" class="time">14:04</a> |
| jwb | i say punt | <a href="#t14:04" class="time">14:04</a> |
| jwb | we have two decisions to push out to the lists from today's meeting | <a href="#t14:05" class="time">14:05</a> |
| jeremy | I think that rather than lengthy discussion, we should a) get requirements written up and then b) get some ideas written up as possible ways to work within the constraints of the requirements | <a href="#t14:05" class="time">14:05</a> |
| f13 | the only topic after that was discussion around creating Standard Operating Proceedures for things that rel-eng does, which should be a no-brainer. | <a href="#t14:05" class="time">14:05</a> |
| f13 | jeremy: I agree, but there needs to be some discussion on what our requirements are (: | <a href="#t14:05" class="time">14:05</a> |
| warren | What rel-eng team tasks are there outside of a freeze? | <a href="#t14:05" class="time">14:05</a> |
| notting | f13: at some point we need to tackle 'making signing sane'. but that's almost infrastructure as much as rel-eng | <a href="#t14:05" class="time">14:05</a> |
| rdieter | punt +1, need to bolt for food soon anyway. | <a href="#t14:05" class="time">14:05</a> |
| f13 | so maybe next meeting and between now and then we'll discuss what our requirements are without any thought as to implementation? | <a href="#t14:05" class="time">14:05</a> |
| jwb | f13, sounds good | <a href="#t14:06" class="time">14:06</a> |
| f13 | warren: updates pushing, buildroot overrides, buildroot unbreaking, tag creations, builds untagging, etc... | <a href="#t14:06" class="time">14:06</a> |
| jeremy | f13: it'll be a far more productive discussion if we're having a discussion _based_ on something. as opposed to just random free-form discussion | <a href="#t14:06" class="time">14:06</a> |
| warren | f13, except only two of you can do updates pushing | <a href="#t14:06" class="time">14:06</a> |
| notting | warren: see my comment about signing :/ | <a href="#t14:07" class="time">14:07</a> |
| f13 | warren: right now. we're planning on changing that. | <a href="#t14:07" class="time">14:07</a> |
| jwb | right | <a href="#t14:07" class="time">14:07</a> |
| warren | notting, make signing sane includes implementing signing server? | <a href="#t14:07" class="time">14:07</a> |
| notting | warren: step 1: get a box | <a href="#t14:07" class="time">14:07</a> |
| f13 | warren: that's potentially one way | <a href="#t14:07" class="time">14:07</a> |
| f13 | mbonnet: btw, "make it so" (the srpm thing) | <a href="#t14:08" class="time">14:08</a> |
| notting | i should write something up | <a href="#t14:08" class="time">14:08</a> |
| warren | We don't need a lot of signers, but a signing server allowing us to proxy and protect the real key would be great. | <a href="#t14:08" class="time">14:08</a> |
| mbonnet | f13: got it, I'll have new packages available today | <a href="#t14:08" class="time">14:08</a> |
| f13 | mbonnet: cool, we'll schedule some downtime. | <a href="#t14:08" class="time">14:08</a> |
| f13 | Ok, I'm going to call the meeting then, and let people go. Thanks everybody! | <a href="#t14:08" class="time">14:08</a> |
| warren | notting, timezone coverage of signing is part of your goal? | <a href="#t14:08" class="time">14:08</a> |
| f13 changed the topic of #fedora-meeting to: <a href="http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel">http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel</a> -- Meetings often get logged -- see schedule in the wiki for next meeting | <a href="#t14:09" class="time">14:09</a> | |
| notting | warren: it's not something i want to prevent. but it's so bad ATM it's not on the radar | <a href="#t14:09" class="time">14:09</a> |
| warren | notting, ok, I just wanted to know your thoughts. | <a href="#t14:09" class="time">14:09</a> |
| f13 | poelcat: for the record: We're going to discuss what our Freeze Requirments are and write those up, to have further discussions about how to manage a freeze around those requirements. Will need QA input on this as well. | <a href="#t14:10" class="time">14:10</a> |
| f13 | the rest of the topics we'll get to next week. | <a href="#t14:11" class="time">14:11</a> |
| poelcat | f13: "discuss(ion)" will happen where? | <a href="#t14:11" class="time">14:11</a> |
| jwb | i suggest -maintainers or -devel list | <a href="#t14:12" class="time">14:12</a> |
| poelcat | IOW is someone writing up wiki page first, then email discussion? | <a href="#t14:12" class="time">14:12</a> |
| f13 | poelcat: I think we should have some discussion on -maintainers first, then write up results into a wiki page | <a href="#t14:15" class="time">14:15</a> |
| poelcat | gotcha | <a href="#t14:16" class="time">14:16</a> |
Generated by irclog2html.py 2.3 by Marius Gedminas - find it at mg.pov.lt!