[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Release Engineering meeting
From:       Chris Gianelloni <wolf31o2 () gentoo ! org>
Date:       2004-12-30 20:40:52
Message-ID: 1104439253.20806.213.camel () cgianelloni ! nuvox ! net
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


Here is the log from our meeting today.

--=20
Chris Gianelloni
Release Engineering - Operational/QA Manager
Games - Developer
Gentoo Linux

["releng-meeting.log" (releng-meeting.log)]

<wolf31o2-work> Houston, we are a go
<zhen> ok
--> plasmaroo (~plasmaroo@plasmaroo.developer.gentoo) has joined #releng-meeting
<zhen> first item
<zhen> 2.6 migration
--- gustavoz gives channel operator status to plasmaroo
<zhen> which I assume means dropping 2.4 from the stages entirely
--> Luke-Jr (~luke-jr@207.192.219.246) has joined #releng-meeting
<zhen> linux26-headers, udev, etc, right?
<wolf31o2-work> not exactly
<wolf31o2-work> the 2.6 stuff is being merged with the 2.4 stuff by the kernel team
<zhen> 2.6 stuff meaning what exactly?
<wolf31o2-work> so the 2005.0 profile will install 2.6 by default, as will all other \
profiles... there is going to be a 2.4 sub-profile for keeping 2.4 and not upgrading \
to 2.6 <gustavoz> on a side note, sparc isn't 2.6 ready yet
<zhen> this is probably a good topic for a -dev discussion
<pvdabeel> ppc is already 2.6 so that shouldn't be a problem
<wolf31o2-work> honestly... we're not discussing this... what we really need to \
discuss is if we want to provide 2.4-based stages <beejay> I see a lot of problems \
with migrating to 2.6 <beejay> especially from hardened-team (method etc.)
<pvdabeel> are we talking about headers or sources ?
<wolf31o2-work> both
<zhen> the stages would only be affected by the headers though, corret?
<zhen> s/corret/correct
<pvdabeel> yes
<wolf31o2-work> ok... everybody stop
<wolf31o2-work> here's what will happen
<wolf31o2-work> linux26-headers is going away
<wolf31o2-work> all the 2.6 ebuilds are being moved into their respective 2.4 package \
counterparts <wolf31o2-work> so linux26-headers -> linux-headers
<wolf31o2-work> gentoo-dev-sources -> gentoo-sources
<zhen> what is their eta for the move?
<wolf31o2-work> before 2005.0... I don't really know
<roger55> vanilla is going to be 2.6 as well?
<gustavoz> some archs have already moved
<gustavoz> hppa did for the kernels already
<pvdabeel> we too (only sources)
<zhen> so this concern really only applies to x86 then, right?
<gustavoz> pvdabeel: yep, wouldn't be good the other way around :)
<zhen> (and hardened x86)
<zhen> if this is a x86 concern, then let's take it to -dev and ask there
<wolf31o2-work> I don't know who all it affects
<wolf31o2-work> ok... you're not following me
<wolf31o2-work> what would we ask -dev?
<wolf31o2-work> if we should provide 2.4-based stages?
<zhen> yes
<wolf31o2-work> this is our decision
<pvdabeel> meaning each profile has a 2.4 and a 2.6 subdir, right?
<wolf31o2-work> pvdabeel: nope... each profile has a 2.4 subdirectory
<wolf31o2-work> 2.6 is default
<pvdabeel> k
<zhen> wolf31o2-work: but we should field input - unilateral decisions on our part \
                are not always the best way to do things
--> Weeve (weeve@Weeve.developer.gentoo) has joined #releng-meeting
<wolf31o2-work> with the "default" yu can use either 2.4 or 2.6, but 2.6 will be \
"highest" <gustavoz> wolf31o2-work: ok, but sparc should have it the other way around
<wolf31o2-work> with a 2.4 profile, 2.6 will be profile masked
--- gustavoz gives channel operator status to Weeve
<zhen> hiya weeve
<Weeve> hiya zhen 
<wolf31o2-work> this is getting a little out of hand...
<roger55> wolf31o2-work: does that mean that with a 2.4 profile one can only use 2.4 \
sources as well or is that only for headers? <wolf31o2-work> sparc needs nothing, \
actually... because on sparc, linux-headers > 2.5 would be masked, since they don't \
work <wolf31o2-work> roger55: a 2.4 profile is 2.4-only
<gustavoz> wolf31o2-work: sure, i'm talking about defaults here, frankly \
linux26-headers was unnecessary imho with proper versioning/locking <wolf31o2-work> \
sparc is the one place where there's no changes <wolf31o2-work> gustavoz: agredd, but \
again... this is not the point and not for us to discuss <Weeve> are we only talking \
wrt officially supported arches at the moment? <wolf31o2-work> I *really* don't want \
to waste a ton of time discussing this <wolf31o2-work> Weeve: all arches, actually
* zhen agrees
<zhen> i believe that what Chris is asking is simply to make 2.4 and 2.6 profiles for \
all arches *that need them* <zhen> outside of that, it is the arch's decision
<gustavoz> as long as the "reversed profile default" is there for sparc i'm done with \
it <wolf31o2-work> well... sparc's profile would be simple in the packages file, \
there would be <linux-sources-2.5 <wolf31o2-work> err
<wolf31o2-work> linux-headers-2.5
<gustavoz> 2.5? :)
<wolf31o2-work> so it would always install the 2.4 headers
<Weeve> wolf31o2-work: i'd double check with mips and alpha folks if they aren't \
around as well since I'd gander we're not the only ones with issues with 2.6 headers \
(and mips always sounds like a lotta fun when it comes to that jazz) <gustavoz> \
linux-headers-2.4* :) <wolf31o2-work> Weeve: I'm not checking anything... that's all \
the kernel team's shizzy <wolf31o2-work> which is why I keep saying we're not going \
to discuss it here <zhen> ok, so that we can move on:
<wolf31o2-work> they've been doing their coordination on it and know more about it \
than us <pvdabeel> If I'm not mistaken there is a portage bug that causes 2.4 headers \
to unpack after 2.6 headers have been unpacked, 2.6 overwriting 2.4 <kloeri> I don't \
know if there's issues with 2.6 headers on alpha yet but I don't believe so <-- \
                plasmaroo has quit (Read error: 54 (Connection reset by peer))
--> plasmaroo (~plasmaroo@plasmaroo.developer.gentoo) has joined #releng-meeting
<wolf31o2-work> so... do we build 2.4 stages for x86 (and any others that will be \
switching)? <zhen> wolf31o2-work: if there is a need, yes
<wolf31o2-work> or do we just build the 2.6 stuff and document how to get a 2.4 \
system? <zhen> which is something that we should query on -dev
<beejay> for x86 (non-hardened) I'd say No
<gustavoz> downgrading headers is basically reemerging glibc, not much more
<kloeri> I'm fine just documenting the downgrade
<wolf31o2-work> right
<gustavoz> though i'd say no, since some stuff like hal uses the added functionality
<gustavoz> so you'd have to do kind of a separate set of GRPs for that
<zhen> wolf31o2-work: write something up to dev explaining our motives and asking \
whether or not 2.4 stages would be necessary for any arches that currently are making \
the move to 2.6 for 2005.0 <zhen> i think that we will be able to make our decision \
based on that correspondence <zhen> and the details can be worked out by the arch \
leads with the kernel team <zhen> will that work?
<wolf31o2-work> one moment
<wolf31o2-work> phone
<zhen> ok
--- wolf31o2-work gives channel operator status to plasmaroo
<plasmaroo> Folks, if 2.6 headers don't work, BUG it and assign it to me please. \
Thanks. <gustavoz> plasmaroo: in the sparc situation first we need a good 2.6 kernel \
to make 2.6 headers useful :) <plasmaroo> gustavoz: Yup ;-]
<gustavoz> plasmaroo: eradicator is working on that, but i don't see us being ready \
                for 2005.0 at least
* plasmaroo nods.
<zhen> while we are waiting for Chris, let's discuss snapshots
<zhen> (and defer the dates discussion for when Chris gets off the phone)
* gustavoz suggests a shared snapshot if possible
<beejay> I make it dependant on "slow" arches
<zhen> i like how snapshots were done for .3, but I don't believe that the central \
snapshot should be on the amd64 for security reasons <beejay> gustavoz: yep
<gustavoz> placed on toucan or such to tweak for the release engineers
<beejay> pvdabeel: how long would you need to build?
<zhen> gustavoz: that would work
<zhen> infra could probably set us up with that
<gustavoz> kinda like /space with propers perms for us
<zhen> yups
<beejay> two weeks before the release for the final snapshot
<beejay> would that be ok?
<gustavoz> yep
<zhen> fine with me
<pvdabeel> 10 days or two weeks would be fine
* zhen mails jforman regarding the snapshot on toucan
<beejay> who should maintain the snapshot?
<gustavoz> jforman is AFK
<gustavoz> on vacation more like it
<zhen> he will be back soon though, right?
<beejay> cruising around in the gulf
<zhen> or is he on extended leave
<kloeri> I'm fine with >=10 days as well
<gustavoz> whoever feels like packing it, but the top relengs for each should be able \
to tweak it <zhen> beejay: probably either Chris or I
<gustavoz> *for each arch
<zhen> gustavoz: it might be better to have everything go through 1 or 2 people to \
avoid confusion <wolf31o2-work> ok... back
<zhen> the more changes to the tree, the more potential problems we may have
<wolf31o2-work> one second while I catch up
<gustavoz> zhen: i agree as long as those 1 or 2 are generally available so as not to \
be showstoppers <zhen> gustavoz: works for me
--> GMsoft (~gmsoft@gmsoft.developer.gentoo) has joined #releng-meeting
--- gustavoz gives channel operator status to GMsoft
<wolf31o2-work> ok... here's the problem... it did *not* work well last time... the \
only reason why it worked at all was becaus eI spent literally 80 hours a week on \
Gentoo <wolf31o2-work> I do not have that luxury this release
<pvdabeel> me neither
<zhen> same here
<gustavoz> for .3 the snapshot wasn't publicly available or touchable
<wolf31o2-work> which is why I suggested the amd64... we cannot wait on -infra to \
setup this for us on toucan... we honestly don't have that long <wolf31o2-work> \
correct <wolf31o2-work> 2004.3 was on my laptop
<zhen> amd64 is not good for security
<wolf31o2-work> explain
<gustavoz> i can set up a box here with shell if that's any good
<zhen> there are 20+ users with sudo access
<zhen> and it is not closely monitored for security breaches
<zhen> it is not even hardened
<wolf31o2-work> umm....
<wolf31o2-work> yeah... allow me to ask...
<wolf31o2-work> so?
<zhen> because we cannot run the risk of a compomised tree.
<zhen> if someone gets into it they could trojan the entire release
<wolf31o2-work> and the amd64 box would be more of a risk than individual developer \
boxes, or my doing it on my laptop? <zhen> and then we are fucked.
<zhen> yes
<zhen> because it is publically accessible
<gustavoz> sudo access on that box would be bad
<zhen> and there is little or no control over it
<zhen> i would like to have the release tree on a box where access is controlled, \
like toucan <zhen> or one of the releng team member's boxen
<zhen> so let's look at toucan to start with and go from there
<wolf31o2-work> I don't want to have to wait on -infra
<zhen> when is .0, Feb?
<wolf31o2-work> so my vote is for a dev's box
<beejay> well
<wolf31o2-work> that's something to discuss
<gustavoz> i think we can agree to give infra say a week to set it up or we'll part
<zhen> ok, let's discuss dates then
<wolf31o2-work> I'm thinking the *release date* would be Feb 7th
<zhen> LWE?
<wolf31o2-work> so we are not talking much time
<wolf31o2-work> week before LWE
<beejay> can't we have them create a group "releng", add all relevant users to it and \
create a dir that's only accessible by these users? <zhen> beejay: yeah, we will take \
that up with infra <wolf31o2-work> beejay: yes, we can
<zhen> I am fine for the 7th
<beejay> make it the 8th
<wolf31o2-work> ok... here were my date proposals:
<beejay> it's my birthday :)
<wolf31o2-work> Snapshot -> Jan 21st
<beejay> ok
<wolf31o2-work> Upload -> Jan 31st
<wolf31o2-work> Release -> Feb 7th
<plasmaroo> Not sure if we have enough room for testing.
<beejay> 10 days for building
<wolf31o2-work> yeah
<wolf31o2-work> plasmaroo: testing should be done before snapshot, as always
<plasmaroo> wolf31o2-work: Oki.
<gustavoz> and there's no biggie (gnome, kde, whatnot) coming either, we should be ok
<zhen> 20 days for testing seems slim
<zhen> but I guess that it depends on what we are releasing
<wolf31o2-work> honestly, 2005.0 is really more like an incremental release from \
2004.3 <wolf31o2-work> there's very little changed
<zhen> what about X CDs?
<plasmaroo> They're experimental.
<zhen> ok
<plasmaroo> At least for x86.
<zhen> yah
<gustavoz> or they could be released on a separate schedule from regular livecds
<wolf31o2-work> in most cases, it'll be a: sed -i 's/20041022/20050121/' *.spec and \
rebuild <zhen> yeah
<zhen> those dates look good Chris
<wolf31o2-work> ok
* plasmaroo nods.
<zhen> post them on the web :)
<gustavoz> i'd like to think X CDs are better suited to release when new desktop \
stuff is out :) <zhen> new desktop stuff?
<gustavoz> gnome, kde, whatnot again
<zhen> ah
<zhen> speaking of dates, we need to talk release schedules
<wolf31o2-work> zhen: I'd rather not... I prefer not making them public, so we can \
slip them in an emergency <zhen> wolf31o2-work: ok, that works
<wolf31o2-work> I thought we just were
<wolf31o2-work> :P
<zhen> wolf31o2-work: :) I mean biannual livecd releases, etc
<roger55> wolf31o2-work: one rather important thing this time is documentation \
coordination. <zhen> quarterly stages/ GRP and biannual LiveCDs?
<wolf31o2-work> ahh... ok... well... given first week of February, that would mean \
something like first week of August <pvdabeel> rb
<pvdabeel> brb
<wolf31o2-work> I'd rather not have two release cycles
<zhen> why?
<wolf31o2-work> GRP is the most intensive thing we do... it is the primary reason for \
dumping the quarterly release cycle <wolf31o2-work> at least as I see it
<zhen> so what do you propose?
<wolf31o2-work> bi-annual releases... period
<wolf31o2-work> but that goes into my idea for GRP's future
<zhen> hm
<zhen> what about out of date media?
<zhen> or does that work into your plan as well? ;)
<gustavoz> guess we can always do a livecd revbump in case of trouble
<zhen> yup
<gustavoz> or for some new funky hardware support
<wolf31o2-work> 6 months isn't too far out of date, honestly... it works for RH and \
others... I don't see why it wouldn't work for us... <wolf31o2-work> that... and I \
want to see GRP go away (kinda) <wolf31o2-work> allow me to explain
<wolf31o2-work> with the new x-based LiveCD, we have complete builds of \
Gnome/KDE/XFCE4/others already on the CD, right? so why build it twice just to have \
GRP packages? <wolf31o2-work> there's no need... so instead, the "GRP" *is* the \
LiveCD... the packages are built on-the-fly by the installer using quickpkg \
<gustavoz> it's reasonable, GRPs are to taste/test gentoo <gustavoz> an X cd fits the \
bill mostly <zhen> with proper scripting, that idea is a nice alternative to grp
<roger55> wolf31o2-work: does all that fit on a cd?
<wolf31o2-work> roger55: so far, it looks to
<zhen> even with 3+ wms?
<wolf31o2-work> right now I have tried *every package* provided by GRP, and I managed \
ot get it onto 700MB <wolf31o2-work> zhen: yes
<gustavoz> well, you kinda have those in the GRPs too, and they fit in one CD :)
<zhen> wolf31o2-work: with X booting and everything?
<gustavoz> would be GRP cd + stage3 + kernel
<wolf31o2-work> zhen: look at the packageCD for x86... then remove 45MB for the \
second X.org instance (we'll have only one for 2005.0 thanks to ATI) then add 50MB \
for the minimal LiveCD <gustavoz> as long as you use some proper compression for that \
cd of course <zhen> wolf31o2-work: hot.
<wolf31o2-work> gustavoz: actually, stage3 would be pulled live, too
<gustavoz> wolf31o2-work: yep, i'm talking rough numbers
<wolf31o2-work> right... ok
<zhen> wolf31o2-work: I like the idea :) run it by dev and see how they think.
<gustavoz> sizeof(stage3+GRPs+kernel) :)
<wolf31o2-work> zhen: alright... that was the idea for (probably) 2006.0 or \
something... to have it all working <zhen> why not 2005.2 if we move to biannual?
<gustavoz> that would be 2005.1 then ;-)
<zhen> er, yeah
<wolf31o2-work> so 2005.0 is first x-livecd/installer... by 2005.1 we expect it to be \
beta quality functionality <wolf31o2-work> installer guys don't expect to be "there" \
yet by then <gustavoz> basically it can be done on a per-arch basis
<zhen> yes
<wolf31o2-work> so it'll remain in /experimental most likely for all of 2005
<wolf31o2-work> correct
<gustavoz> say, if you have a beta ready 2005.0 nice, but mandatory when 2006.0 is \
out or whatever we decide <zhen> sure
<pvdabeel> k
<zhen> pvdabeel: do you like that idea?
<roger55> but stages will stay?
<zhen> roger55: yes
<pvdabeel> sure
<gustavoz> roger55: yep, stages are on the universal cd :)
<wolf31o2-work> roger55: for now, yes
<zhen> pvdabeel: i believe that you recommended this a year a go or so ;)
<pvdabeel> yeah
<wolf31o2-work> yeah... it's an old idea
<wolf31o2-work> but eventually we would have very little to release
<wolf31o2-work> 1. minimal CD
<gustavoz> we could eventualy think of installing that cd to disk for a quick install \
or so <wolf31o2-work> 2. stage1 (not friggin castrated anymore)
<wolf31o2-work> 3. X-based LiveCD
<wolf31o2-work> gustavoz: that'll be available for 2005.0, according to the \
-installer guys <pvdabeel> I have such livecds in my development machines, the cd \
performs a basic install on reboot, completely non-interactive. It's just \
partitioning that needs some work <wolf31o2-work> we'll be "cloing" the CD to disk
<zhen> wolf31o2-work: we should still make stage2 and stage3 available
<gustavoz> wolf31o2-work: yep, but we'll probably have to tweak some baselayout \
'lovin to get it right <wolf31o2-work> zhen: we can still do that
<zhen> wolf31o2-work: cool
<zhen> so 2005.0 will be our last "traditional" release, right?
<wolf31o2-work> the point being is that "universal + packagecd" get replaced by \
"x-based" <zhen> we will release the normal stuff, as well as an experimental \
X-installerCD <zhen> then switch to biannual releases and go all out for .1
<wolf31o2-work> I figure both 2005.0 and 2005.1 will be traditional, unless \
development on the installer side picks way up <wolf31o2-work> which it might after \
2005.0 comes out <zhen> do we technically need the installer to release a x \
installcd? <gustavoz> not really imho
<wolf31o2-work> no... we don't...
<zhen> i don't see the need
<gustavoz> would be an added feature for the future
<zhen> yes
<wolf31o2-work> but we need the installer to do the on-the-fly building of stages/grp
<wolf31o2-work> sicne they're the ones already building it
<wolf31o2-work> ;]
<zhen> we can already do on the fly installs for grp
<wolf31o2-work> so we can't replace universal+packages until at least that \
functionality works <wolf31o2-work> no... on-the-fly *creation*
<zhen> yeah, quickpkg
<wolf31o2-work> right
<zhen> ok, so why do we need the installer for grp then?
<zhen> just document how to use quickpkg
<wolf31o2-work> because I don't want to write a script that does "quickpkg \
cat/package" for every single GRP package and installs it, etc when the installer \
guys are already doing it for me <gustavoz> zhen: would be nice at some point for \
anxious users <zhen> i guess that i am missing the point
<wolf31o2-work> I'd prefer not leave that to the user, if possible
<wolf31o2-work> I think you are
<wolf31o2-work> they could have this ready *now* if I wanted it
<wolf31o2-work> it is a separate module for the installer
<wolf31o2-work> the entire installer is modular
<wolf31o2-work> like catalyst
<zhen> right
<zhen> i guess that I am having a problem with a traditional release for .1
<roger55> why can't we simply write the cd to hd, why is quickpkg needed?
<zhen> 9 months seems like a long time for the installer crew to get a beta going
<wolf31o2-work> roger55: what if you don't want KDE but only Gnome
<pvdabeel> roger55: quickpkg solution allows you to build subsets of the cd
<pvdabeel> wolf31o2-work: exactly
<pvdabeel> you could copy the entire cd and start unmerging stuff
<wolf31o2-work> zhen: that is a beta of the full installer... aside from what we're \
doing <zhen> pvdabeel: unnecessary overhead
<gustavoz> you could just avoid installed the kde stuff to begin with which is easier
<pvdabeel> quickpkg has the overhead of tar and untar
<gustavoz> *installing even
<roger55> it would be a quicker install though wouldn't it?
<wolf31o2-work> anyway... I would really us rather worry about 2005.0 now
<zhen> wolf31o2-work: sure
<wolf31o2-work> we could have another meeting afterwards, no
<zhen> yep :)
<wolf31o2-work> I'm kinda at work, so I'd like to not spend the rest of the day in \
this meeting... *grin* <zhen> heh
<zhen> ok, so a wrap up:
<zhen> (summary)
<wolf31o2-work> wait a second
<wolf31o2-work> forgot naming
<wolf31o2-work> heh
<zhen> oh
<zhen> what was your proposal again?
<wolf31o2-work> well... this is pretty simple
<beejay> packages-subarch-2005.0.iso
<wolf31o2-work> I have a proposal to rename the "livecd" to
<wolf31o2-work> "installcd" as it makes more sense to people, it also allows for \
using <wolf31o2-work> livecd as a name for the full-blown environment... this would \
give us <wolf31o2-work> installcd/minimal, installcd/universal, packagecd/packages, \
and <wolf31o2-work> livecd/livecd (eventually)
<beejay> sounds good
<gustavoz> no problem with that naming
<zhen> yup
<wolf31o2-work> for directory structure and such
<zhen> sounds good to me
<wolf31o2-work> cool
<zhen> ok :)
<gustavoz> livecd isn't that "live" :)
<wolf31o2-work> so we would refer to the "traditional" CD sets as "install cd" rather \
than "livecd" <beejay> what about internal codenames? Tortellini for 2005.0? ;D
<plasmaroo> Heheh.
<gustavoz> goatboat!
<zhen> heh
<zhen> lol
<wolf31o2-work> heh
<zhen> goatboat sounds ok ;)
* plasmaroo nods.
<wolf31o2-work> also... netboot stuff
<zhen> we are waiting on gmsoft
<wolf31o2-work> k
<zhen> so let's defer that
<gustavoz> i'll probably look into the sparc aspect of that
<zhen> (well, we have to defer it until he gets some catalyst patches to us)
<gustavoz> maybe fix something x86 in the way, but i can't promise
<wolf31o2-work> heh... ok
<zhen> alright, summary time :)
<roger55> wolf31o2-work: we need a date for documentation updates, so the doc guys \
won't want to kill us last minute... <wolf31o2-work> roger55: snapshot date sounds \
good to me <zhen> I will mail it out to -dev and -releng, Chris - can you take care \
of the 2.6/2.4 stages mail pelase? <wolf31o2-work> so Jan 21st
<wolf31o2-work> zhen: yeah... that one's going to start a flamewar from hell
<wolf31o2-work> what does -releng recommend? no 2.4 stages?
<gustavoz> just mention that hardened can stick to whatever they like most
<wolf31o2-work> it seemed to work fine for amd64 and ppc
<gustavoz> you'll avoid 70% of the flame with that
<wolf31o2-work> gustavoz: definitely... since they have their own stages, etc
<zhen> i would clearly state that we recommend nothing and are asking the community \
for their input <zhen> which gives hardened their 2.4 stages :)
<beejay> that won't change anything
<zhen> and avoids flames
<gustavoz> and a big disclaimer "for arches that are ready" (that should get ciaran \
calmed down) ;-) <beejay> if most of the users say "go for 2.6", then some devs will \
say "our users are stupid maggots" <zhen> beejay: sure it will
<zhen> we are following the kernel team's lead to move to 2.6 on selected arches
<zhen> and we need to gauge what arches/ projects still require 2.4 stages
<zhen> because we will go with the default (which will be 2.6) unless told otherwise
<wolf31o2-work> I honestly don't think we should ask anyone... it seems this is a \
x86-only issue... and both beejay and myself agree we shouldn't provide stages for \
2.4... and hardened provides their own stages... so I'm not sure I understand what \
non-hardened 2.4 stages would give us other than more work to do... ;] <zhen> because \
we should commmunicate our intention <zhen> intentions
<wolf31o2-work> I'm pretty sure everybody understands that when the kernel team says \
"we're going 2.6 as default" that that means the release will, too <zhen> releng does \
not need the reputation of being secretive and closed <wolf31o2-work> right
<zhen> that is a lot of assumption
<wolf31o2-work> but you're saying we need to ask everybody what they think
<zhen> if you word the mail correctly, there should not be a flame war
<wolf31o2-work> I think we just need to tell them what we're doing
<wolf31o2-work> rather than ask for opinions... because opinions are like assholes... \
and well... we have a lot of "opinions" in our development team... ;] <zhen> heh
<zhen> but we do not know all of the special cases
<zhen> i can write the mail if you wish ..
<gustavoz> remember to ask for gcc 3.4.3 for all arches :-P
<wolf31o2-work> yeah... that might be better simply because I would have a hard time \
writing it objectively since I am 100% against providing 2.4 stages <zhen> \
wolf31o2-work: :) <wolf31o2-work> gustavoz: DIE!
<zhen> i will take care of it then
<gustavoz> hehehe
<zhen> ok, I have to run
<wolf31o2-work> ok
<zhen> can someone post the log please?
<wolf31o2-work> sunnary
<wolf31o2-work> summary, yo
<zhen> i will send it to -dev
<wolf31o2-work> :P
<zhen> unless you want me to summarize here as well
<wolf31o2-work> sure
<zhen> ok
<zhen> here goes
<wolf31o2-work> makes it pretty for the logs
<zhen> SUMMARY:
<zhen> 2.4/2.6 stages - arches/ projects that require 2.4 stages will get them, \
otherwise, we will follow the lead of the kernel team and supply 2.6 stages by \
default <zhen> Dates - er, Chris, you will have to post these someplace
<zhen> Snapshot Coordination - the snapshot will be on toucan - Chris and zhen will \
manage it <zhen> 2005 Roadmap - Traditional releases for .0 and .1, with the \
possiblility of a switch to xLiveCDs for .1. We are now on a biannual release \
schedule. <zhen> Addl Release Media - no netboot until gmsoft gets us catalyst \
patches, XLiveCDs in the works for .1 <zhen> the future of GRP - dependent on the \
installer team. may change for .1. <zhen> CD naming scheme changes: livecd=installcd
<zhen> (un)Official Release name for .0 - "GoatBoat"
<zhen> i'm done :)
<wolf31o2-work> heh
<wolf31o2-work> later
<zhen> Goooooooooooooooooooooooooooooooooooo GoatBoat!
<gustavoz> heh
--- plasmaroo has changed the topic to: Nothing to see here: go back to your work.
<zhen> bye all :)
<beejay> omg
<zhen> hm?
<beejay> bye Dr. Davis


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]