From Fedora Project Wiki
Fedora Release Engineering Meeting :: Monday 2008-06-09
Misc Open Topics from F13
- edited up sign_unsigned and managed to get a lot of speed increase out of it
- F10 schedule looks okay
- spam filter plugin going into Fedora hopefully today so that we can try to reduce the spam in our project space even more
Source Control Management (SCM)
- Solely a requirements gathering phase--no specific SCM will be identified
- ideas so far of things that would be good to have:
- script triggers pre/post commit actions
- able to reliably disseminate commits as they happen to a selected group of people (per package & branch)
- having acls/multiple owners for things is implied, but might need to be explicit
- better integration with our environment in general, pkgdb, bodhi, bugzilla, etc..
- able to clone for disconnected development
- able to create new branches cheaply
- exploded source trees and quilt like patch management vs just simple patch files--ideally our new system would allow for both, depending on how the owner of the module decides to do it
- easy between-branch merging for those who like to ship the same source rpm everywhere
- not rely on magic 'branch' files for the build & tag-fu to work
Fedora ia64
- ia64 is almost ready to do an F9 release
- they need an updated fedora-release package that has their GPG key in it
- Seth is working on a yum change that will allow a single RPM gpg file hold multiple keys, so that we can just append the ia64 key to the current file.
- also talking with the yum guys about a possible change to how yum handles gpg files
- more discussion needed
Hardware Update
- blade center was installed by mmcgrath last week, and we'll soon have a bunch more builders in koji
IRC Transcript
| f13 | ping: notting jeremy jwb spot lmacken rdieter wwoods poelcat warren | |
| spot | i'm here for about 20 minutes or so | |
| f13 | spot is going to be in a meeting, jwb is moving, warren is on paid time off I do believe. | |
| * poelcat here... logging + 0.5 day PTO | ||
| warren | I'm here | |
| f13 | well, I don't really have much to talk about. | |
| f13 | other than a topic which we could chat for a very long time about, so I'm going to open up the floor for anybody else first. | |
| -!- f13 changed the topic of #fedora-meeting to: Fedora releng - Open Floor | ||
| f13 | heh, chatty crowd. | |
| f13 | Well, couple things from me: | |
| poelcat | is the schedule cool? | |
| f13 | 1) I edited up sign_unsigned and managed to get a /lot/ of speed increase out of it. | |
| * wwoods here. mostly. | ||
| f13 | poelcat: sadly, I couldn't get anybody to do an indepth matchup of dates and events and/or holidays. There was some concern over a holiday, memorial day or labor day, I can't remember which one | |
| poelcat | i believe it was labor day around first part of setp | |
| poelcat | sept | |
| f13 | right | |
| f13 | but I think we're OK with it as it is. | |
| poelcat | okay | |
| f13 | moving on, 2) I've got a spam filter plugin going into Fedora hopefully today so that we can try to reduce the spam in our project space even more | |
| f13 | 3) the big one. I'm composing a mail right now, subject: Requirements gathering for new package source control | |
| -!- f13 changed the topic of #fedora-meeting to: Fedora releng - Requirements gathering for new package source control | ||
| f13 | This is the talk I'm giving at FUDCon, and I throught it would be prudent to give those not at FUDCon a chance to speak about this. | |
| f13 | purely requirements gathering, any "git does foo" or "svn does bar" or "cvs sucks" type comments will flat out be ignored. | |
| f13 | http://fpaste.org/paste/2712 that's what I have so far | |
| notting | - be able to be queried and pulled from anonymously (by the buildsystem, by the web, etc.) might be a given, but.... | |
| wwoods | I think script triggers are another requirement, albeit an easy one | |
| f13 | wwoods: pre/post commit stuff? | |
| wwoods | yeah | |
| warren | blocking script? | |
| notting | - be able to reliably disseminate commits as they happen to a selected group of people (per package & branch) | |
| wwoods | having acls/multiple owners for things is implied, but might need to be explicit | |
| f13 | wwoods: I thought that woudl be in the 'fine grained access control' | |
| f13 | warren: define 'blocking script' | |
| notting | - (nice to have) be able to integrate with the packagedb better than what we have now | |
| f13 | notting: yeah, that's an underlying theme | |
| f13 | better integration with our environment in general, pkgdb, bodhi, bugzilla, etc.. | |
| notting | f13: "no flag-based pre-commit checks". ahem. | |
| f13 | good god no | |
| f13 | for as long as I'm at the helm that will never happen. | |
| notting | ideally: 1) able to clone for disconnected development 2) able to create new branches cheaply | |
| f13 | 2 may be more about change our workflow than change our SCM | |
| notting | are we looking for one-size-fits-all, or package-specific workflows? | |
| f13 | ideally I'd like both (: | |
| f13 | we had talked before about exploded source trees and quilt like patch management vs just simple patch files | |
| f13 | ideally our new system would allow for both, depending on how the owner of the module decides to do it | |
| f13 | although that may prove to be too complicated for scripted actions | |
| f13 | ooh, that's another to add. | |
| warren | are these going onto a wiki page? | |
| f13 | warren: right now they're going into an email I'm about to send to fedora-devel-list. And yes, I'll be gathering responses and tossing them into a wiki page | |
| warren | ok | |
| notting | - easy between-branch merging for those who like to ship the same source rpm everywhere | |
| wwoods | oh that would be lovely. | |
| notting | - ideally, not rely on magic 'branch' files for the build & tag-fu to work | |
| f13 | so this should be a pretty "fantastic" email thread. I can't wait to get it started. | |
| warren | the thread can't possibly devolve. | |
| f13 | oh I know what else I wanted to bring up. | |
| f13 | 4) Fedora ia64. | |
| f13 | ia64 is ready to do an F9 release, well almost. They need us to issue an updated fedora-release package that has their GPG key in it. Seth is working on a yum change that will allow a single RPM gpg file hold multiple keys, so that we can just append the ia64 key to the current file. | |
| f13 | and 5) our bladecenter was installed by mmcgrath last week, and we'll soon have a bunch more builders in koji. | |
| warren | is appending the GPG Key really a good idea | |
| warren | I mean, do we trust every arbitrary secondary arch to keep their key secure? | |
| f13 | we're not appending every arbitrary secondary arch. Right now, we're appending ia64, whom we have some level of trust with. | |
| warren | ok... | |
| notting | hm. i suppose we've sort of painted ourselves into a corner with the 'must use fedora packages' thing | |
| f13 | yep | |
| notting | actually | |
| notting | do the non-mirrorlist baseurls work with secondary arches anyway? | |
| warren | If primary arch users trust the secondary arch key... | |
| warren | uh.. | |
| notting | if the baseurls don't, they may need a different fedora-release anyway. at which point they can add their own key | |
| warren | I would really feel more comfortable that way anyhow. | |
| warren | Do secondary arch URL's reuse noarch's from primary or rebuild those too? | |
| f13 | I do believe they rebuild. | |
| f13 | notting: They can be made to work. | |
| f13 | notting: it's just a url rewrite. | |
| notting | f13: which implies they don't now ;) | |
| warren | f13: that makes it a bit inconsistent with using baseurl for any other mirror which wont have the rewrite | |
| f13 | notting: I haven't tried, they may. | |
| f13 | warren: all those baseurls go to at least round robin DNS | |
| f13 | warren: they aren't hardwired urls. | |
| warren | f13: no | |
| warren | f13: #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/development/$basearch/os/ | |
| warren | f13: this one goes straight to fedora's own | |
| f13 | warren: no mirror is required to carry every primary arch, debuginfo, etc... so it's just as tenious to point directly at a mirror without verfying first. | |
| f13 | warren: havey ou done a dns lookup on that host lately? | |
| f13 | $ host download.fedora.redhat.com | |
| f13 | download.fedora.redhat.com has address 66.187.224.20 | |
| f13 | download.fedora.redhat.com has address 209.132.176.20 | |
| f13 | download.fedora.redhat.com has address 209.132.176.220 | |
| warren | oh, I thought you meant the actual redirect | |
| warren | download.fedoraproject.org | |
| f13 | no, it's just a smaller set of hosts, which can and often are still inconsistant. | |
| f13 | warren: if you have concerns over the key usage, it would help a lot if you put in some time to draft up guidelines on handling the key, since we have none now. | |
| warren | It seems like an awful solution to expose all users to what is effectively a 3rd party key by default. | |
| f13 | warren: the other options involved making fedora-release full of arch specific gunk | |
| warren | and saying "just this one time" opens a can of worms | |
| f13 | and either build time magic, or making the package arch specific in whole. | |
| f13 | warren: I'm not saying that. | |
| warren | so we treat other future secondary archs differently? | |
| f13 | warren: absolutely not, I don't see how you're possibly getting that from me. | |
| warren | <f13> we're not appending every arbitrary secondary arch. Right now, we're appending ia64, whom we have some level of trust with. | |
| f13 | I'm saying we have ia64 /right now/ ready to go, and I'm reasonable confortable with their process and people to grant them being "official" by taking in their key. | |
| notting | or, we grant an exception that secondary arches can use a different package :/ | |
| notting | (for fedora-release only) | |
| warren | that sounds like "just this one" which seems like we're ignoring other cases | |
| f13 | no other secondary arch is ready, so there are no other 'arbitrary' secondary arches to talk about. | |
| f13 | however, if sparc came up tomorrow and said they were ready, and we were reasonable comfortable with their setup, I would ask to add them to our package as well. | |
| warren | It seems absolutely awful to have all users trust a 3rd party key by default for no good reason. | |
| warren | Every 3rd party controlled key you add to the default trust set makes the exposure that much bigger. | |
| f13 | warren: it seems absolutely awful to not be a part of the secondary arch process at all until now and then stonewall. | |
| warren | Each signing server needs to be independently secured | |
| warren | This is a BAD IDEA | |
| warren | f13: I haven't heard any bad ideas until now. | |
| f13 | if we don't trust them, we shouldn't trust them for /any/ use of the Fedora term. | |
| warren | Do we have a revocation ability if one of their keys gets stolen one day? | |
| f13 | do we have that for our key? | |
| warren | It seems perfectly reasonable to have arch-specific fedora-release. | |
| warren | That is far less of a risk than exposing this to all users. | |
| f13 | no, that's saying "we may not trust these guys, but eh, it'll only screw a few of you, so whatever." | |
| warren | "a few of you"? | |
| warren | Isn't adding their 3rd party key to the central fedora-release going to expose all Fedora users to packages signed by their key. | |
| warren | You're being self-contradictory here. | |
| f13 | warren: if you don't trust the secondary arch team, and don't ship the key as that reason, you're basically saying "I don't care about the secondary arch uses, they can get screwed for all I care" | |
| warren | You say it isn't "arbitrary" | |
| warren | yet you mention sparc adding next if they say they are ready | |
| warren | how many 3rd party keys do we expose to all of our users? | |
| warren | where do we draw the line? | |
| warren | We need a better solution than this. | |
| warren | f13: couldn't we do something like this instead: | |
| notting | put it this way - even if RHX verifies the key usages of all their partners, does it make sense to add them to the base repo? no. | |
| warren | f13: secondary arch team signs their packages, our signing server checks that sig and resigns using the offical key, since both are distributed on the official mirror. | |
| warren | (this is possibly a bad idea, but not as bad as what you are suggesting) | |
| notting | warren: updates. PAAAAIN. | |
| f13 | updates hell, any release PAAAAAIN | |
| f13 | warren: perhaps you don't understand the meaning of the term 'arbitrary'. | |
| notting | but, as i understand, secondary arch updates are pushed asynchronously from 'regular' updates | |
| warren | perhaps that was a poor word choice | |
| f13 | warren: we /know/ ahead of time what arches are working on being secondary. It's not many. The only two that are remotely close to doing a release are ia64 and sparc | |
| notting | f13: so, the key here is 'must be built from fedora bits', and that was/is a board-level mandate. i suppose i can bring this up tomorrow at the board with 'this is causing a minor headache'. dunno if anything will come of it | |
| warren | What happens when alpha appears, controlled by a group in Poland that we don't know very well. Just trust their key for all users? | |
| warren | This makes NO SENSE | |
| f13 | warren: If we don't trust them to be Fedora, we don't trust them. | |
| f13 | warren: if we don't trust that they can manage a key, we shouldn't trust them with the Fedora brand, and they wouldn't be an official secondary arch. | |
| warren | and are you just ignoring the possibility that trusting more keys controlled by different people makes everyone less safe? | |
| f13 | warren: we ignore all kinds of 'extra risk' things every day warren. | |
| warren | their signing happens on a different box than primary archs? | |
| warren | This is a can of worms that will be difficult to undo. | |
| f13 | warren: signing, building, composing, everything happens on different machines. | |
| warren | OK, it seems we have very different opinions on this. | |
| warren | I think this is a horrible idea. | |
| notting | sorry, i have to go catch a different meeting | |
| warren | I don't appreciate being called "stonewalling" | |
| warren | There is a clear way they can do it without this bad idea. | |
| f13 | no, there is just a way for you to feel better about 'minimizing' the risk, by only exposing the other arch users to the key. | |
| f13 | effectively telling them that you just don't care about them. | |
| warren | perhaps we need a better way to handle this? | |
| warren | the signing server could route all signing on the same trusted host | |
| warren | "just don't care about them" is highly subjective | |
| f13 | that would cause significant bandwith costs | |
| warren | Are you just going to steamroll this through? | |
| warren | I don't understand why you don't see the problem in this. | |
| warren | Your solution is a much greater problem than the problem it aims to solve. | |
| f13 | given that there are only 1.5 people talking about this in here, I'm not going to "steamroll" anything through. I'll kick it to the board, but it sounds like bill will already. | |
| warren | And I don't suppose my opinion matters since I haven't been involved in secondary archs before. | |
| f13 | no, your opinion matters. | |
| warren | Sorry, this tone was too personal. I only disagree with the idea itself. | |
| warren | Let's see what the board says. | |
| f13 | yep. | |
| f13 | warren: fwiw I'm also talking with the yum guys about a possible change to how yum handles gpg files | |
| f13 | warren: in that if yum sees a package signed with <keyid>, it'll look in the listed file and only import the <keyid> key. | |
| warren | this isn't exactly a fix | |
| f13 | warren: so as a primary arch user, you'd never be exposed to packages signed with the secondary arch key, therefor they would never import it. | |
| warren | No. | |
| warren | The risk I'm talking about wouldn't be fixed by that. | |
| f13 | unless they did something by hand to import everything from the file. | |
| warren | If the secondary arch key were to be stolen, then a package could be signed with it and the user would be exposed. | |
| f13 | the key would be shipped in the fedora-release source package no matter what, unless we break our rule about all packages coming from the same source | |
| f13 | (and changing that rule may break some software we've written for secondary arch builds) | |
| warren | fedora-release source package I'm not against | |
| f13 | sure, if it were stolen. | |
| warren | The risk I was talking about was entirely in the secondary arch key being stolen | |
| warren | this new thing you mention only trusts that users know when to not click "yes" on a rarely seen dialog | |
| warren | I have to go | |
| warren | (gotta see if my car is intact) | |
| f13 | yeah, we're over time, ending meeting. | |
Generated by irclog2html.py 2.6 by Marius Gedminas - find it at mg.pov.lt!