ReleaseEngineering/Meetings/2008-jun-09

From FedoraProject

Jump to: navigation, search

Contents

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!