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 []