path: root/meeting-logs/20060817.txt

18:30 -!- kloeri [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
18:30 -!- Irssi: #gentoo-council: Total of 17 nicks [4 ops, 0 halfops, 0 voices, 13 normal]
18:30 -!- Irssi: Join to #gentoo-council was synced in 2 secs
18:55 <@Koon> 18:55
19:00 <@SwifT> ping!
19:01 <@Koon> pong?
19:01 <@SwifT> yes!
19:01 <@SwifT> ping!
19:01 <@Koon> No route to host !
19:01 <@SwifT> okay then... tnsping!
19:02 <@Koon> aw.
19:02 <@Koon> It's time to start our last meeting
19:02 <@Koon> seemant is on his way here
19:03 <@Koon> solar: are you with us ?
19:03 <@Koon> agriffis: same
19:03 <@Koon> az is missing, no answer fro mvapier yet
19:03 <@SwifT> we should all be absent so a reelection must occur ! :)
19:03 <@Koon> about time, yes :)
19:04 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
19:04 -!- mode/#gentoo-council [+o seemant] by ChanServ
19:04  * Koon looks around in the room to see if there are council candidates taking notes
19:04  * SwifT watches left
19:04 <@seemant> aha
19:04  * SwifT watches right
19:04 <@seemant> I was in here, but not here
19:04  * agriffis is here
19:04 <@seemant> irssi thought I was, but there was no activity or response
19:04 <@seemant> so weird
19:04 <@seemant> sorry about that, all
19:05 <@SwifT> don't worry, always fun to see people zap in :)
19:05 <@SwifT> okay, first point on the agenda... open floor
19:05 <@SwifT> :)
19:05 <@Koon> kudos to kloeri and spb then
19:05 < kloeri> hi all :)
19:05 <@seemant> hi bryan
19:06 <@Koon> On the plate for today, the discussion Stuart asked for on how to better handle critical stableization steps
19:07 <@Koon> My question to start : does GLEP42 answer to taht question (after all, it's the answer to all)
19:07 <@SwifT> like the baselayout thingie?
19:07 < kloeri> yeah, came up because of the baselayout stabling afaik
19:07 <@Koon> SwifT: I think that's what started it, yes
19:07 <@SwifT> well, I don't think GLEP42 is the answer.... but it is a major part of the answer
19:07 <@Koon> SwifT: what's left ?
19:08 <@SwifT> good communication of all participants prior to the news?
19:08 <@Koon> because the pre-discussion of the GLEP42 Newsarticle on -dev serves as a dev warning
19:08 <@SwifT> like, if baselayout stabilises, informing devs in advance or so
19:08 <@SwifT> not blaming here, didn't follow it all
19:09 <@SwifT> (just in case :)
19:09 < kloeri> I think Stuart wants to go a bit further, like having upgrade guides and so on
19:09 <@Koon> Ah. Documentation things. See SwiFT :)
19:09  * Koon can't read.
19:09 < kloeri> but we'd also need to decide on what 'critical packages' are if anything is to be done
19:09 <@SwifT> i'm not active in it currently :p
19:10 < kloeri> could define it as 'system' but that'd be a bit silly imo :)
19:11 <@Koon> kloeri: so we would have a list of critical packages that need (1) advance warning (2) an upgrade guide and (3) a GLEP42-style news article (when available) ?
19:11 < kloeri> yeah, I guess that's what Stuart wants
19:11 <@Koon> if vapier was there, I'd say that common sense would do better than a rule here
19:11  * agriffis doesn't like the sound of this, goes to read GLEP42
19:11 <@Koon> he'd say
19:12 < kloeri> yeah, I'm not sure I'd like to force upgrade guides etc. down the throat of some devs either
19:13 < kloeri> GLEP42 + common sense should cover most of it imo
19:13 <@agriffis> GLEP42 makes sense to me, i.e. a standard mechanism for distribution.
19:13 <@Koon> + some spanking of non-observant devs
19:13 < kloeri> agreed
19:13 <@Koon> critical packages = baselayout, gcc, ...
19:14 <@Koon> only for major versions
19:14 <@agriffis> The requirement part, which doesn't seem to be part of GLEP42 anyway, bothers me because I don't like holding anything up for process.  I'd rather see things move forward without good process, rather than see things held up... of course, the best is when common sense is used and news and progress coincide :-)
19:14 <@solar> shat. thanks seemant I was getting carried away building stuff
19:14 <@Koon> solar: stop building :P
19:15 <@seemant> yeah, I'm with Aron on this, I really don't like the idea of adding bureaucracy
19:15 < kloeri> agriffis: completely agree on that - GLEP42 is a good vehicle to distribute news items but common sense is needed to decide when to use the news system
19:15 <@seemant> (or rather, *even more* bureaucracy)
19:16 <@solar> the world needs a new hardened-sources
19:16 <@Koon> kloeri: also on the baselayout subjects, there were plenty of signs that it was going to stable... It's not like if they pushed it without talking to anyone
19:16 < kloeri> Koon: right, I don't personally have a problem with baselayout going stable (as an arch lead I was asked in advance anyway)
19:16 -!- bonsaikitten [n=pal@gentoo/developer/bonsaikitten] has joined #gentoo-council
19:17 <@Koon> so I'd say if there had been GLEP42 in place there would have been a discussion around it and the need for a separate upgrade guide
19:17 < kloeri> I haven't actually talked to Stuart about this but as he doesn't seem to be around I'm trying to guess what he wants
19:17 <@seemant> now, I don't see anything wrong, per se, about having had an upgrade guide, or a "new sexy features" blurb somewhere about it
19:17 < kloeri> seems we all agree that force / policy / whatever isn't the right solution
19:17 <@Koon> so in essence my position on this is that GLEP42 goes a long way to solve this problem, and I'm reluctant to adding more rules where common sense usually suffices
19:18 < Stuart> lo
19:18 < Stuart> sorry, had to wait for an fsck
19:18 < kloeri> Stuart: ahh, there you are :)
19:18 <@Koon> Stuart: ah !
19:18 <@solar> I already talked with UberLord.. There is no way on earth he diserves any flack for putting together a nice baselayout and waiting for as long as he did for other people to stop being slackers
19:19 < Stuart> he's not getting any flack
19:19 < Stuart> not from me, anyway
19:19 < kloeri> I don't think it's about flack at all, more about avoiding similar problems in the future if possible
19:19 <@Koon> Stuart: doesn't GLEP42 sufficiently answer your worries (when/if available) ?
19:20 < Stuart> Koon: no, it doesn't
19:20 <@Koon> Stuart: ok, please elaborate
19:20 < Stuart> ok
19:21 < Stuart> the issue I have is that we stabilised one of the most fundamental parts of Gentoo w/ no announcement, and no upgrade guide on www.g.o
19:21 < Stuart> GLEP42 doesn't solve that, because a) there's nothing stopping folks making announcements today, even w/out GLEP42,
19:21 < Stuart> and b) GLEP42 isn't an outlet for upgrade guides
19:22 < Stuart> it's irresponsible
19:22 < Stuart> I'm all for stabilising baselayout-1.12
19:22 < Stuart> I'm just saying that doing so by stealth isn't good
19:23 < Stuart> clearly, the "common sense" argument that folks love to fall back on isn't up to the job, or there'd have been an announcement and an upgrade guide
19:23 <@Koon> Stuart: but in the newsarticle prediscussion on -dev, someone could mention the need for an upgrade guide
19:23 <@solar> so what are you saying.. that every package in 'system' needs prior approval befoe going stable?
19:23 <@Koon> I agree that the other problem remains
19:24 < Stuart> solar: something that'll take out boxes, yes please
19:24 <@solar> I've not seen any shitstorm of bugs related to it and I've updated quite a few. What major breakage was caused?
19:25 <@Koon> solar: not only in system. The Apache new configuration style brought down quite a few web servers
19:25 < Stuart> Koon: which is why we posted upgrade guides and plenty of announcements first :)
19:25 < kloeri> Koon: the apache upgrade was announced quite heavily though
19:25 <@solar> the only thing I'm aware of is a courier-imap initscript in relation to the new baselayout
19:25 -!- dev-zero [n=BerryRyd@gw.ptr-80-238-206-183.customer.ch.netstream.com] has joined #gentoo-council
19:25 < kloeri> Koon: just goes to show that no amount of announcements, guides etc. is going to save everybody in case of major changes :)
19:25 <@Koon> yes, I didn't say that as an example of failure
19:26 <@Koon> juust to prove that it's not just "system"
19:26 < Stuart> solar: some folks had network breakages, and it was stabilised w/ a known problem w/ courier-imap.  the quality of the code isn't the issue here
19:26 < Stuart> I'm not saying it wasn't ready to go stable
19:26 <@Koon> to me GLEP42 is there to announce any changes that can bring down a service or a box
19:26 -!- |jokey| [n=jokey@e176101132.adsl.alicedsl.de] has joined #gentoo-council
19:27 < Stuart> Koon: GLEP42 is a red-herring in this discussion
19:27 < Stuart> folks can already post announcements
19:27 < Stuart> I'm more concerned with the fact that no-one did
19:27 < kloeri> critical packages are hard to define imo as that set will differ from server to server, from person to person if we're to include stuff like apache etc.
19:27 < Stuart> kloeri: I think we can agree that baselayout is a critical package :)
19:28 <@Koon> Stuart: so you want a hard rule that critical changes should always be announced
19:28 < kloeri> Stuart: sure but I'm not sure what else to include in that set
19:28 < kloeri> Stuart: baselayout, toolchain, what else?
19:28 <@Koon> because I see no way of enforcing it with our current QA system
19:28 <@solar> Stuart: did you attempt to take this up with UberLord vs going directly to the council?
19:28 < Stuart> solar: yes
19:28 <@solar> what was his reaction?
19:28 < genstef> kloeri: cups, X11
19:29 <@solar> genstef: those dont prevent a system from booting.
19:29 < Stuart> solar: he said that he was too busy to write one, and that folks could just read the new example file
19:29 < genstef> solar: apache does not prevent that either
19:29 < kloeri> solar: neither does gcc but it's probably critical to gentoo systems
19:29 < Stuart> solar: that's not meant as a critisism of uberlord - I know he's worked hard this week to fix bugs as they've been reported
19:30 <@agriffis> Stuart: the part that bothers me about this: emerge -upv system/world will show you that baselayout is making a relatively major version transition.  It's the administrator's responsibility to pay attention to that, in fact they should be paying close attention...  I'm not sure I agree this an issue with existing Gentoo practice.
19:30 <@solar> genstef: and thus it's not valid
19:30 < Stuart> agriffis: I agree, but 1.11 to 1.12 does not look like a major bump
19:30 < kloeri> Stuart: that's a bit harsh imo - he said he was busy at work and couldn't immediately take care of any bugs / write any guides iirc
19:30 <@agriffis> Stuart: ok, I agree with that
19:30 <@solar> it's valid. But not vital as it wont prevent the admin from logging in and running etc-update and stuff.
19:30 < Stuart> agriffis: and anyway, with no announcement and no upgrade guide, where can they go to read about the changes? :)
19:31 < Stuart> kloeri: I did say I wasn't here to critise him
19:31 <@Koon> solar: then nothing prevents you from booting anoter OS to fix the wreckage
19:31 < Stuart> kloeri: tbh, I'm much more concerned that the arch teams thought this was acceptable :)
19:31 <@agriffis> Stuart: I wish the versioning were more obvious.  It *is* true that etc-update or dispatch-conf will show a large delta in net.example, including a pretty exact demonstration of the changes.
19:31 <@Koon> I'd say any non-trivial upgrades need to be announced
19:31 < Stuart> agriffis: at that point, it's a bit late perhaps :)
19:31 <@agriffis> Stuart: no, because at that point, it's still perfectly possible to back the version down
19:32 < kloeri> Stuart: arch teams had been testing it for quite a while - using it to build the new release etc.
19:32 < Stuart> kloeri: again, this isn't about the quality of baselayout-1.12
19:32 <@solar> Koon: I'm saying as long as the box comes back up on the same interfaces as you rebooted it with. I'm not seeing any reason to try and force yet another policy.
19:32 <@Koon> kloeri: it's not a question of stable, it's a question of upgrade
19:32 < kloeri> Stuart: but no (reasonable) amount is going to catch all problems unfortunately
19:32 < Stuart> kloeri: it's about providing folks with a bit more help than just some code dumped on their harddrive :)
19:32 < kloeri> Koon: yeah, but people have been testing upgrades too
19:33 < Stuart> agriffis: mmm ... how well do we test downgrading baselayout upgrades?
19:33 <@agriffis> Stuart: I've done it plenty
19:33 < Stuart> agriffis: cool
19:33 < kloeri> it's not that I'm against upgrade guides or anything, I'm just saying that the new baselayout saw quite a bit of testing before being stabled
19:33 <@agriffis> though I won't claim I make a practice of testing each possible downgrade path :-b
19:33 <@Koon> Stuart: how about this rule : any non-trivial upgardes should be announced (with GLEP42 when available, on -dev in the meantime)
19:34 < Stuart> Koon: I'd be very happy w/ that
19:34 <@Koon> again, that's common sense but better write it down
19:34 <@solar> who defines non trivial?
19:34 < Stuart> Koon: not that common, or else at least one of the folks involved in this stabilisation would have done it :)
19:34 <@Koon> non-trivial = you can't keep your config files the way they are
19:35 < Stuart> Koon: that's a good definition
19:35 <@solar> thats going to upset gregkh
19:35 < Stuart> solar: greg makes a living upsetting folks. he'll cope
19:36 <@Koon> so you have to announce it when you break forward-compat
19:36 <@agriffis> greg doesn't cope, he fights back, and in the gentoo case, he'd probably just quit
19:36 <@Koon> solar: gregkh ? on udev ?
19:36 < Stuart> he'd quit over being asked to keep users informed when things aren't b-c anymore?
19:36 <@solar> Stuart: tbh.. To me it really sounds like 42 will cover this. and it was simply a matter of really what he said. not enough freetime and or he saw it as trivial.
19:37 <@solar> I'd really not like to try and enforce this. But just encourage others to try to be more careful
19:37 <@Koon> solar: the thing is no rule forces you to announce anything, GLEP42 or not
19:37 < Stuart> solar: 42 is just an outlet. no-one is required to use it
19:38 <@agriffis> Stuart: I don't know what gregkh would do, I have no idea how attached he is to Gentoo.  However announcing every udev b-c breakage is *way* harder than the existing process of simply bumping it.
19:38 <@agriffis> That's a good example, really, because it suggests to me that the *rule* of informing when b-c breaks might be too much.
19:39 <@Koon> I think that's the minimum that is due to the users
19:39 <@agriffis> I'm all about making devel easier, it's nearly the only thing I care about in the context of Gentoo.
19:40 < Stuart> there has to be a balance
19:40 <@Koon> anyway, the best is probably to GLEP the rule as I spelled it, throw it to gentoo-dev and see it go down in flames or survive the test
19:40 <@agriffis> I can see it as a rule of thumb, but not something I'd like to see enforced by anything other than shaming of devs that break systems by not informing.
19:40 <@agriffis> i.e. by not providing instructions/guide/etc.
19:41 < Stuart> agriffis: and if that doesn't work?
19:41 <@Koon> agriffis: there is no way to enforce it anyway
19:41 <@Koon> except call devrel in for repeated "errors"
19:42 -!- jokey [n=jokey@gentoo/developer/jokey] has quit [Connection timed out]
19:42 <@agriffis> Koon: sure there is.  we've seen devs ejected because we set up rules, then had to enforce them, where "we" is gentoo not necessarily the council.
19:42 <@agriffis> Any time you make a rule you have to think about enforcement, somebody's going to file a bug and want you to enforce it eventually.
19:42 <@Koon> I still think announcing b-c breaks to the users is a minimum
19:43 <@agriffis> I dunno, maybe this is a *good* one for that, but I'm just slow to make rules. :-)
19:43 <@Koon> but maybe nobody is with me and Stuart on this one :)
19:43 <@agriffis> Koon: for what set of packages?
19:43 <@Koon> I'd say "all" in stable
19:44 <@Koon> it's not that common
19:44 <@agriffis> ok, and what consitutes "announcing"?
19:44 <@SwifT> damnid... guys, I need to go, some incident at work
19:44 <@Koon> use GLEP42-system when available, use -dev in the meantime
19:44 <@solar> my fear is that you put such a rule in place.. Then you have a dev that has not upgraded in many moons. He forgets to etc-update; reboots and his services dont all start.. users start calling him. he starts screaming cuz he did not get a upgrade guide.
19:44 <@Koon> SwifT: that's not a good way to end your Council term :P
19:45 < Stuart> agriffis: a minimal "we're releasing blah on set date; it breaks your system; go here to read what to do about it"
19:45 < Stuart> solar: said dev'd quickly get his ass handed back to him for wasting folks time, I'd hope
19:45 <@Koon> This should definitely be discussed on -dev as a GLEP rather than here
19:46 <@solar> Stuart: sorry but I feel like this is what has happened here.
19:46 -!- kallamej [n=kallamej@gentoo/developer/kallamej] has joined #gentoo-council
19:46 < Stuart> solar: ??
19:46 <@Koon> and the next council can adopt it with everything balanced
19:46 < Stuart> Koon: that sounds sensible to me
19:47 <@solar> Stuart: cuz the upgrade was rather painless tbh. Nothing to major broke. All boxes I've rebooted came back up on the same IP's and all services started.
19:47 <@solar> imap is the only thing I really am aware of.
19:47 < kloeri> personally I think it's going to be very hard to define any reasonable rules for this
19:48 <@Koon> solar: the point is nothing prevents a larger break to occur
19:48 <@solar> Can you point at some bugs as reference
19:48 <@solar> Koon: yeah I know nothing prevents it.
19:48 < genstef> solar: there is a tracker bug
19:48 < kloeri> one of the problems with the baselayout upgrade afaik was related to the GATEWAY variable - and that's been deprecated for more than a year now
19:48 < Stuart> solar: I keep saying that it's not about the quality of the code
19:48 < kloeri> so how far back should upgrade guides go?
19:48 <@Koon> solar: and there is no rule/advice on how to handle b-c breaks in Gentoo
19:48 < genstef> solar: http://bugs.gentoo.org/143988
19:49 < kloeri> we don't have any formal ideas about which versions we still support
19:49 < Stuart> kloeri: I'm happy w/ upgrade guides only going back as little as possible
19:49 <@agriffis> so here's a question... is a guide needed, or does a warning suffice?  "Warning: This upgrade contains config changes that are not backward compatible.  Be careful when etc-updating!"
19:50 <@agriffis> Is it an announcement that's needed, or a guide?
19:50 <@Koon> agriffis: to me, an announcement
19:50 < Stuart> agriffis: in general, folks like apache, php, gcc, X and java have tended to post guides as well as warnings
19:50 < genstef> agriffis: it would be nice if we had an announcement on -dev one day before
19:51 <@Koon> when the announcement is posted, someone else can write up a guide if he wants to
19:51 < genstef> agriffis: like I will be marking baselayout stable, any blockers?
19:51 <@agriffis> I'm not suggesting to drop guides, I think they're *great* and I've made use of them before, but I'm wondering what's the lower limit that a dev could provide to fulfill due diligence.
19:51 < Stuart> agriffis: for stuff that's gentoo-specific, if we don't provide a guide, where is a user going to get the information from? :)
19:51 <@solar> agriffis: einfo/elog seems ok to me
19:52 <@Koon> agriffis: the rule can be to announce it. If the discussion that ensues shows the need to have a guide, then someone can step up and write it, but the rule doesn't require it
19:52 <@agriffis> Stuart: baselayout has net.example which is kept religiously up to date.  A diff, given by etc-update or dispatch-conf, shows clearly what has changed.  So a warning to Be Careful in that case would seem to be sufficient, that is to fulfill bare miminum requirements.
19:52 < Stuart> solar: something that folks can read before upgrading would be useful, if there's any prep required (like having some free time to rewrite the config files)
19:53 <@agriffis> Koon: so if the discussion decides that a guide is needed, and the dev who is not *writing* a package but only maintaining the ebuild is not able to provide the guide, and nobody steps up to write one, then a warning about b-c breakage would suffice?
19:53 <@agriffis> I'm sorry, I'm not wanting to split hairs here, or drive anybody crazy...
19:53 <@Koon> agriffis: for me, yes. But I won't be the one that will vote the GLEP when it will be written anyway
19:54 < Stuart> agriffis: why wouldn't the dev be able to provide the guide?
19:54  * Stuart is suffering packet loss atm :(
19:54 <@Koon> Stuart: he can, but he doesn't have to
19:54 <@agriffis> I'm trying to understand how to keep things super-easy for devs in the minimal case, so that nothing gets clogged by the introduction of new requirements.
19:54 <@agriffis> Stuart: time, desire, etc.
19:54 <@Koon> Stuart: the mimimum enforced is the announcement
19:54 <@solar> From that tracker only 143914 seems like it could cause an admin from not being able to log inyto a remote host
19:55 < genstef> agriffis: well, if the punishment is a "hall of shame" in the GWN then I think that can be made a requirement, yes
19:55 <@agriffis> I think udev is a fantastic example.  There's no (gentoo-specific) upgrade guide, I don't want to require greg to start providing one, or make him wait for another dev to write one.
19:55 <@Koon> Stuart: but once again, this should be GLEPped, and our advice is worth almost nothing since we won't be voting it, this is our last meeting
19:55 <@agriffis> Btw, there is a very good Gentoo udev guide, I'm not talking about that.  I'm referring to udev changes between version stabilization.
19:56 < Stuart> does greg maintain a non-gentoo-specific upgrade guide?
19:57 <@agriffis> Stuart: sorry, I left that open because I don't know
19:57 < genstef> Stuart: greg deo snot maintain udev upstream, kay sievers does that
19:57 <@agriffis> deo snot, eh? ;-)
19:57 < genstef> Stuart: in fact udev in gentoo is often not up to date because greg has not much time
19:58 < Stuart> I'd be happy w/ just announcements for now, and see how it goes
19:58 <@solar> Stuart: pre install would be unneeded in most cases. etc-update and having the instructions/examples in/around the # $Header$ comments should be fine.
19:59 <@solar> I have to leave. I think I have about the same view point as agriffis here. einfo/elog preinst if needed. I'd go for suggesting people just try to do a better job next time vs shoving another rule down peoples throats.
20:00 < Stuart> solar: I couldn't agree w/ you less wrt etc-update being good enough
20:00 <@Koon> OK, let's end the meeting then, this should be GLEped and discussed on -dev anyway
20:00 <@agriffis> well, I think at least this discussion has provided a good starting point for any discussion on -dev.
20:00 <@solar> I'm rejected it now
20:00 <@solar> n/m a glep.
20:00 <@Koon> thanks everyone for this year, it was great to work with you all guys
20:01 <@Koon> and good luck to the next Council
20:01  * kloeri waves goodbye to the old council :)
20:01 <@solar> you guys try to be on baselayout and see how little gets done with this rule
20:01 <@solar> base-system rather
20:01 < Stuart> solar: having a QA guy complain about being asked to tell folks when stuff breaks ... that doesn't look very good :)
20:02 <@Koon> Stuart: solar has many personalities
20:02 < Stuart> anyway, appreciate you all discussing this at short notice
20:02 <@agriffis> Hey guys, I had a good time on Council this year.  It's been a fun team through some ups and downs.  Thank you.
20:02 < Stuart> and waiting for my hard drive to finish fsck'ing :)
20:03 <@solar> Stuart: I understand that breakage sucks really bad. I'm just saying putting a rule into place for everything everytime something goes a little left is not ideal for such a organic distro
20:03 <@agriffis> Koon: will you be posting the minutes and log?
20:03 <@solar> we should focus on improving common sense vs alot of rules. thats all
20:03 <@Koon> agriffis: no, I don't have the log
20:04 <@agriffis> ok, I have it
20:04 <@agriffis> I can post it and the meeting summary if that's okay with everybody.
20:04 < genstef> http://genstef.homelinux.org/gentoo-council.08-17.log
20:05 < Stuart> solar: I agree with the sentiment, but the reality is a little different
20:05 <@solar> Stuart: I just want gentoo to remain fun.
20:05 < genstef> Stuart: how would you enforce such a rule, btw?
20:05 < Stuart> solar: so do I.  but we have to have fun responsibly
20:06 < Stuart> genstef: ideally, the arch teams should enforce it, because they stabilise packages, not package maintainers
20:06 <@solar> Stuart: I think you should just try to encourage people to be a little more aware. If it becomes a major problem over time then revisit.
20:07 < Stuart> solar: I'd rather take a little step now, and avoid there ever being a major problem
20:07 <@solar> well I just hope the next council decides to not try and enforce such a thing.
20:08 <@solar> cuz it sounds like a bunch of nofun.
20:08 < genstef> do we have a stabilization guide? Maybe just add a line "when it is an important update, please inform users before marking it stable"
20:09 <@solar> it passed the QA tests of every arch team.
20:10 <@solar> genstef: sure. notice the wording on that. "please"
20:10 <@solar> which differs from required. Don't get me wrong. I'm not saying it's ok to break things left and right.
20:11 <@solar> things just change. Sometimes in unforseen ways that are unknown at the time of the stable marking.
20:12 < Stuart> solar: and that's fair enough
20:12 <@solar> k now I gotta split. Have fun guys.. And please keep gentoo fun for everybody :)
20:12 < Stuart> cya solar
20:15 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["have fun"]
20:15 -!- Stuart [n=stuart@gentoo/developer/Stuart] has left #gentoo-council []