path: root/meeting-logs/20140114.txt

[20:00:39] <scarabeus> ahoj
[20:00:41] <scarabeus> :)
[20:00:45] <dberkholz> hi all
[20:00:46] <dberkholz> roll call
[20:00:48] <scarabeus> that is czech hi :)
[20:01:03] <dilfridge> ho ho ho
[20:01:06] -*- dilfridge here
[20:01:21] -*- rich0 here
[20:01:26] -*- ulm here
[20:02:17] <dberkholz> just pinged blueness on #-dev
[20:02:33] --> _AxS_ (~axs@gentoo/developer/axs) hat #gentoo-council betreten
[20:02:54] <dberkholz> let's give him till 1905, then we'll move on
[20:03:13] --> few_ (~few_@88.150.18.76) hat #gentoo-council betreten
[20:03:54] --> grknight (~Thunderbi@50.120.197.130) hat #gentoo-council betreten
[20:04:17] -*- WilliamH here
[20:05:58] <dberkholz> alright, let's get into the agenda
[20:06:16] <dberkholz> first topic is notifications for the EAPI=5 profile flip
[20:07:21] <dilfridge> one remark
[20:07:45] <dilfridge> as ciaran states, there's not really an EAPI for the whole profile tree, just for single directories
[20:07:57] <dilfridge> so, to clarify this, I'd suggest
[20:08:21] * dberkholz has changed topic for #gentoo-council to: " Next meeting: 14 Jan 2014 at 1900 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://thread.gmane.org/gmane.linux.gentoo.project/3247"
[20:08:41] <dilfridge> "Making the whole profile tree EAPI=5" means, "anyone can increase the eapi in any profile directory to 5 if the features are needed"
[20:08:50] <dberkholz> that's kind of the opposite
[20:08:56] <dberkholz> the decision was default to 5
[20:09:00] <dilfridge> ok
[20:09:09] <dilfridge> then we have to place an eapi 5 file in every dir
[20:09:11] <dberkholz> so what i think we should do is provide 30-day notice for people to drop in an older eapi file, then put 5 into anything that's left empty
[20:09:22] <dilfridge> fine with me too
[20:09:28] <rich0> dberkholz: ++
[20:09:36] <ulm> why would we place an eapi file in dirs where the features are not needed?
[20:10:03] <_AxS_> what will this do to those running say, pkgcore, that doesn't support EAPI5 yet; this would effectively make any profile incompatible with it, no?
[20:10:16] <dberkholz> the vote on that topic was a year ago ulm
[20:10:37] <dilfridge> _AxS_: yes. however, all non-deprecated profiles are already incompatible for a year.
[20:11:11] <_AxS_> dilfridge: true, but one could at least make their own profile that inherits from base, if base isn't EAPI5
[20:11:32] <rich0> Do we REALLY want to support non-EAPI5 indefinitely?
[20:11:38] <dilfridge> the whole point of the exercise was to make base eapi=5 capable
[20:11:46] <dilfridge> (and all the other places)
[20:11:50] <rich0> There was a year's notice, and we're giving another month's notice...
[20:12:09] <rich0> You can always make an overlay that is EAPI4 for whatever subset of the tree still works on EAPI4--
[20:12:24] <dilfridge> which is probably not much
[20:12:39] <dberkholz> if we keep rehashing and pushing off previous council decisions whenever we actually have to take action on them, we're not going to get anywhere
[20:12:47] <rich0> It just doesn't seem all that feasible to avoid EAPI5 as a user, and it just doesn't seem like there is any real reason to support it.
[20:13:01] <ulm> dberkholz: can you point me to the place where we have decided that we would put an eapi 5 file in every profile directory?
[20:13:08] -*- WilliamH agrees with dberkholz 
[20:13:12] <rich0> If I thought the previous decision didn't make sense I'd be all for questioning it, but I think they made the right call...
[20:13:12] <ulm> I cannot find it in the 20130109 log
[20:13:20] <ulm> *0108
[20:13:28] <rich0> Deadlines should mean something, unless it is suicidal to hold to them.
[20:13:34] -*- WilliamH agrees with rich0 
[20:14:01] <dilfridge> Vote on proposal "Stable USE masks in the main portage tree" by
[20:14:01] <dilfridge> Michał Górny [1].  There are three suggested approaches:
[20:14:01] <dilfridge> 1) by adding new profiles requiring EAPI=5, requiring all users to
[20:14:01] <dilfridge>    change, and then deprecating the older profile trees [if chosen; a
[20:14:01] <dilfridge>    subsequent vote on the timeframes involved will follow]
[20:14:01] <dilfridge> [...]
[20:14:11] <dilfridge> The council agreed unanimously to vote between the three proposed solutions. 
[20:14:11] <dilfridge> Solution #1 won with 7 votes.
[20:14:17] <WilliamH> deadlines are deadlines; if they haven't been able to fix it in time it is on them we don't have to hold back and wait for them
[20:14:42] <scarabeus> i agree with ya guys, deadlines are deadlines as WilliamH says :)
[20:14:48] <dberkholz> ulm: that's an implementation detail. the vote was "a 1 year deprecation period for current EAPI<5 profile trees"
[20:15:02] <dberkholz> as per http://www.gentoo.org/proj/en/council/meeting-logs/20130108.txt
[20:15:33] <dberkholz> and further clarification of "Removal of the old EAPI<5 profile trees."
[20:15:46] <ulm> dberkholz: still doesn't imply that every little dir needs the file
[20:15:50] <dilfridge> I would interpret this as "it's allowed to use eapi 5 everywhere", not "everything has to be eapi 5"... 
[20:15:57] <ulm> dilfridge: right
[20:16:29] <dberkholz> anything else makes things more confusing for developers at little tangible benefit
[20:16:29] <dilfridge> the net effect on users is the same since for sure we'll do it in base, and the arch teams are also interested for their directories
[20:17:02] -*- WilliamH agrees with dberkholz  there has been anple time; let's make everything eapi 5
[20:17:25] <dilfridge> meh I dont care between the two options, that difference is not related in any way to the deprecation timeframe
[20:17:28] <ulm> yeah, just put the file where it's needed
[20:17:40] <ulm> no need to spam the tree with 600 files
[20:17:53] <rich0> WE're talking about the profile, not all packages.
[20:18:10] <dberkholz> i didn't realize we had 600 profiles but thanks for the hyperbole.
[20:18:18] <ulm> $ find /usr/portage/profiles/ -type d | wc -l
[20:18:20] <ulm> 609
[20:18:20] <rich0> Individual ebuilds can be non-EAPI5.  They just will not work on a non-EAPI5 PM due to the profile unless the user uses an overlay/etc.
[20:18:24] <dilfridge> it's 609 directories
[20:18:39] <rich0> The number doesn't really concern me.
[20:18:45] <ulm> well, some are to be removed, tbh
[20:18:49] <rich0> Just ignore the commit messages for a day, etc.  :)
[20:18:55] <ulm> but it's some 400 still
[20:19:00] <WilliamH> question...
[20:19:17] <WilliamH> If we make base eapi 5, doesn't that mean that everything that inherits from it is eapi 5?
[20:19:25] <rich0> Set it once in base, or 609 times, the technical impact seems to be the same to me.
[20:19:27] <ulm> unfortunately not
[20:19:32] <ulm> ^^ WilliamH
[20:19:39] <dberkholz> no, pms says otherwise
[20:19:43] <dilfridge> no, because the eapi is not inherited from parents
[20:19:45] <dilfridge> however
[20:19:49] <rich0> So, just conform to PMS and do it 609 times.
[20:20:05] <dilfridge> this has no meaning w/r to deprecation, since the package manager will have to support eapi 5 anyway
[20:20:15] <ulm> that's 2.5 MB of disk space on ext4
[20:20:24] <dberkholz> so?
[20:20:40] -*- ulm just noting
[20:20:49] <WilliamH> ulm: maybe it should be fixed in pms?
[20:20:58] <dberkholz> i don't think we're getting anywhere with this endless argument so why don't we vote on it, again
[20:21:32] <dberkholz> vote: 30-day notice for people to add an eapi file to profiles, then we're dropping eapi 5 into any empty ones
[20:21:42] <ulm> WilliamH: not sure if it can be fixed easily
[20:21:52] <ulm> not immediately, at least
[20:22:15] <ulm> dberkholz: eh, that makes no sense at all
[20:22:27] <ulm> why would we want eapi < 5 files anywhere?
[20:23:01] <ulm> if we put a file, it should be newest eapi
[20:23:26] <dilfridge> how about two separate votes, as follows:
[20:23:29] <dberkholz> newest would be the default, this provides an opt-out for anyone with a significant reason otherwise
[20:23:30] -*- ulm is just concerned about it being several 100 files
[20:23:39] <dberkholz> who in the world cares about several hundred files
[20:23:46] <dberkholz> we have tens of thousands in the tree, it's a couple of MB of space
[20:23:56] <dilfridge> a) 30-days notice, then everything in profiles may require eapi 5
[20:24:06] <dilfridge> b) drop eapi 5 files everywhere?
[20:24:16] <ulm> dberkholz: we would have one million if we were always as careless :p
[20:24:44] --> rafaelmartins (~rafael@gentoo/developer/rafaelmartins) hat #gentoo-council betreten
[20:25:00] <WilliamH> Why two votes? why not just a vote that in 30 days we will drop eapi 5 files everywhere?
[20:25:06] <ulm> dilfridge: sounds good
[20:25:36] <rich0> I don't care how we vote.  However, if we vote yes and then no I think we create a potential PMS mess.
[20:25:48] <rich0> does anybody really think we should do a but not b?
[20:25:59] <ulm> rich0: yes ;)
[20:26:18] <dilfridge> let's think, what is the difference on the profile level exactly?
[20:26:21] <rich0> I mean, sure, I wish PMS were otherwise, but do we want to try to change it before we implement this?
[20:26:23] <_AxS_> ulm: fwiw, currently there are 265'ish 'eapi' files in profiles/ , so there would only actually be about 357 new additions..
[20:27:15] -*- WilliamH thinks we should just give 30 days then do b
[20:27:21] <ulm> dilfridge: it specifies how the contents of the particular dir is read
[20:27:29] <_AxS_> ulm: plus, technically we can remove a bunch of files after everything's eapi5 right? since anything related to legacy (non-eapi5) profiles no longer has a point being in profiles/
[20:27:35] <ulm> no influence on parents or children
[20:28:26] <ulm> _AxS_: right
[20:28:44] <rich0> _AxS_: good point, plus for every one of those items there is the directory tree, parent records, and other files in the tree.  So, this is adding 350 files to a collection of thousands
[20:28:59] <dilfridge> rrriight... slowly I'm getting convinced that placing eapi 5 everywhere is the better solution.
[20:29:31] <rich0> I'm all for finding a better way to handle profiles long-term, but that seems like a different issue
[20:29:43] <dilfridge> dberkholz: how about "30-day notice, then we're dropping eapi 5 into any profile dir"?
[20:29:56] <ulm> rich0: maybe the real issue is us having too many profiles
[20:30:14] <WilliamH> ulm: that's a separate issue...
[20:30:19] <dilfridge> actually that is another point, which we sshould immediately address after this one :]
[20:30:35] <dilfridge> because the 10.0 profiles have no reason to exist then anymore
[20:30:41] <dberkholz> i have an idea! let's fix every problem with gentoo before we end this council meeting!
[20:30:46] <dilfridge> :P
[20:31:00] <dilfridge> your turn mr chair
[20:31:08] <dberkholz> if we just keep it open and let people go in and out for the next year, i bet we could do it.
[20:31:47] <dberkholz> ok, can i just get a quick sense of who's opposed in theory to dropping eapi 5 files into every profile in 30 days?
[20:31:52] <WilliamH> dberkholz: so is dilfridge's statement abov what you were proposing we vote on?
[20:32:05] <dberkholz> not a formal vote, since it's not carefully phrased
[20:32:35] -*- dilfridge is happy with both versions, but slowly thinking that making every dir eapi5 is the cleaner solution
[20:32:37] <ulm> dberkholz: and update existing eapi files to 5, too?
[20:32:49] <dberkholz> ulm: probably a good idea
[20:33:02] <dberkholz> everything eapi5, minimize complexity
[20:33:46] <dilfridge> "big untested change" though
[20:34:13] <rich0> I'm in favor of dumping eapi5 in every dir in 30 days
[20:34:29] <rich0> It isn't any uglier than find /usr/portage/profiles
[20:34:30] -*- WilliamH is in favor
[20:34:31] <ulm> yeah, let's do it then
[20:34:33] <ulm> it would save devs from looking up the eapi for every dir
[20:34:44] <dilfridge> good point
[20:34:55] <dberkholz> alright, here's our vote: we will send 30-day notice and then switch all profiles to eapi 5
[20:35:04] -*- WilliamH yes
[20:35:08] <dilfridge> s/profiles/profile directories/
[20:35:13] -*- dilfridge yes
[20:35:20] <ulm> *sigh*
[20:35:22] -*- ulm yes
[20:35:27] <dberkholz> yes from me
[20:35:42] <dberkholz> ulm: ha, i'll buy you a beer or other beverage at fosdem
[20:35:56] --> blueness (~blueness@gentoo/developer/blueness) hat #gentoo-council betreten
[20:36:03] <blueness> damn! off by 1 hour
[20:36:18] <ulm> hi blueness :)
[20:36:19] <scarabeus> yes
[20:36:27] <rich0> blueness: no problem - you can tackle fixing all the profiles after we leave as pennance.
[20:36:33] <dilfridge> I volunteer do the stuff
[20:36:36] <blueness> i'm so sorry guys, i miscalculated UTC
[20:36:47] <dilfridge> (did the last changes too, so...)
[20:36:54] <dberkholz> blueness: just in time to get your voice heard on the vote: we will send 30-day notice and then switch all profiles to eapi 5
[20:37:04] <blueness> dberkholz, definite yes on that
[20:37:15] -*- rich0 yes
[20:37:43] <dberkholz> dilfridge: i might have to duel you for those rights, i need to do some committing or i'll get rusty =)
[20:37:49] <dilfridge> hehe
[20:38:09] <dilfridge> do we need to vote on the following cleanup? (2 parts, 
[20:38:24] <dilfridge> a) move eapi-5-files/* to a better place
[20:38:29] <dilfridge> b) remove 10.0 profiles
[20:38:31] <dilfridge> )?
[20:38:47] <ulm> dilfridge: just do it
[20:38:50] <dilfridge> ok
[20:38:52] <dilfridge> no problem
[20:39:06] <dberkholz> that's just implementation details, don't think we should care
[20:39:40] <dilfridge> yay, someone owes me beer at fosdem or similar :)
[20:39:52] <dberkholz> i've got ya.
[20:39:55] <blueness> :)
[20:40:03] <dberkholz> cool, next topic
[20:40:08] <dilfridge> none of you both, someone else... :)
[20:40:22] <dberkholz> glep 1/2 updates: changes to the workflow and move to the wiki
[20:40:35] <ulm> in case anyone has missed it, creffett has posted an updated patch for GLEP 1: http://article.gmane.org/gmane.linux.gentoo.project/3241
[20:40:47] -*- creffett here if there are any questions
[20:41:13] <blueness> i liked the template, saw no problems with it
[20:41:28] <dberkholz> key changes are (1) submit gleps and modifications via bugzilla and (2) gleps will be stored on the wiki and formatted appropriately. some other minor ones
[20:42:12] <dberkholz> anyone have a problem with the proposal?
[20:42:30] <blueness> i'm good with it
[20:42:31] -*- dilfridge likes it
[20:42:40] <ulm> my only comment is that I'd have left public-domain GLEPs alone and not change them to CC-BY-SA
[20:42:40] -*- WilliamH is fine with it
[20:42:44] <ulm> but that's a detail
[20:42:53] -*- scarabeus read it bit back and it looked quite fine
[20:42:56] <blueness> ulm, why?  what's the concern?
[20:43:02] <scarabeus> ulm: does the lrelicense pose concern?
[20:43:07] <WilliamH> ulm: We could ask the authors if they are willing to change them if they are still around
[20:43:15] <ulm> no real concern
[20:43:36] <ulm> but also no reason to go from PD to more restrictive
[20:43:54] <ulm> but I won't oppose it
[20:44:17] <blueness> can't someone with pd remove the author?
[20:44:24] <dberkholz> there are some legal questions about whether it's even possible to put something into the public domain
[20:44:28] <blueness> that's the only difference i think there is between cc and pd
[20:44:54] <dberkholz> and it would be of value to unify all our content under a single license to make sure sharing stays easy
[20:45:18] <dberkholz> for example if someone pulls other wiki content into a public domain thing, suddenly they have to realize the license changes
[20:46:17] <dberkholz> the closest thing to public domain is probably CC0 but i don't think we specified that anywhere.
[20:46:30] <ulm> in principle you'd have to check in what legislation the author is located
[20:46:32] <ulm> but the intent should be clear if he has marked his stuff as PD
[20:47:34] <WilliamH> dberkholz: Do we need a formal vote on the proposed glep changes?
[20:47:38] <blueness> ulm, what i like about CC-BY-SA is that no one can legally "steal" your kudos
[20:47:49] <ulm> anyway, I'm still fine with the proposal as it is
[20:47:53] <blueness> 5 second read -> http://creativecommons.org/licenses/by-sa/3.0/
[20:47:57] <dberkholz> so ulm is fine with the thing as is, nobody else has objected, let's vote
[20:48:07] -*- blueness yes
[20:48:10] -*- WilliamH yes
[20:48:11] -*- ulm yes
[20:48:13] -*- dilfridge yes
[20:48:18] <dberkholz> yes
[20:48:25] <scarabeus> yep
[20:48:39] -*- rich0 yes
[20:49:02] <dberkholz> how about that, we're only 3 minutes behind schedule
[20:49:08] <dberkholz> on to the open bugs/issues
[20:49:15] <ulm> dberkholz: was this vote about GLEP 1, or 1&2?
[20:49:33] <dberkholz> 1 & 2 since 2 is just an templated example of following 1
[20:49:38] <ulm> k
[20:49:59] <dberkholz> if anyone has an objected, speak now or forever hold your peace
[20:50:03] <dberkholz> objection*
[20:50:36] <dberkholz> re the open issues, i caught up with robbat2 about the gpg signing and he said he hasn't had time to submit it yet as a glep. creffett|irssi also noted that he wanted to run through the new process we just approved with it
[20:50:54] <dberkholz> so we're still waiting on external efforts for progress on that
[20:51:35] <blueness> one question i had which i never got answers was how gpg signign was going to be enforce
[20:51:50] <blueness> scripted or human (aka QA)???
[20:51:53] <dilfridge> different problem
[20:51:56] <blueness> true
[20:51:57] <dberkholz> there's https://wiki.gentoo.org/wiki/Project:Gentoo-keys
[20:52:40] <blueness> dberkholz, thanks i didn't see that
[20:52:55] <dberkholz> it's in the references section of robbat2's draft glep =)
[20:53:42] <dberkholz> anyway, those folks are sorting out that side of things
[20:54:30] <rich0> I'm fine with the gist of what was propsoed for GPG.  It just sounds like there are details to be worked out - it needs finalization before we can really give it a yes/no.  I don't see anything objectionalbe so far.
[20:54:40] <blueness> ditto
[20:55:06] <dberkholz> i just made new keys last week as per the glep
[20:55:42] <dberkholz> alright, let's move on to the open floor
[20:55:48] <dberkholz> council members or others, any issues to raise?
[20:56:09] <WilliamH> I think I'm going to ask us to revisit our stabilization policy again.
[20:56:26] <WilliamH> bug 487332 is still open withno movement from arch teams
[20:56:28] <willikins> WilliamH: https://bugs.gentoo.org/487332 "sys-apps/openrc-0.12.4 and net-misc/netifrc-0.1 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:openrc
[20:57:05] <WilliamH> imo there isn't a reason for arch teams to take so long on this stuff. :(
[20:57:14] <dberkholz> WilliamH: do you have something more concrete in terms of solutions?
[20:57:24] <_AxS_> WilliamH: a lot of arch teams are short staffed, after ago left to pursue security only...
[20:57:35] <WilliamH> dberkholz: apply the package-by-package policy to all arch's
[20:57:48] <creffett> ago's doing security only now?
[20:58:07] <blueness> uh oh
[20:58:18] <blueness> he burned out
[20:58:29] <blueness> (i'm guessing)
[20:58:57] <ulm> the bug was filed only three months ago, and maybe one should be extra conservative with removing important packages like openrc
[20:59:09] <WilliamH> _AxS_: I understand that the arch teams are short staffed, but  there has to be a better solution than maintainers being forced to keep old versions of packages around because of that.
[20:59:12] <ulm> because in this case it would hurt our users
[20:59:22] <_AxS_> re ago; the move was more political, iirc..  some sort of conflicts with other devs..
[21:00:15] <WilliamH> ulm: The package-by-package policy gives us permission to remove them from some arches after 90 days if there is no response, but it doesn't cover all arch's.
[21:01:05] <WilliamH> ulm: the arch teams do not necessarily prioritize important packages when they stabilize.
[21:01:45] <WilliamH> ulm: I pinged one of the arch teams on that bug on irc weeks ago and was just told that it takes time.
[21:02:27] <WilliamH> I guess my over all question is, if arch teams can't keep up, how relevant is their stable tree anyway?
[21:02:31] <blueness> WilliamH, okay how do you want to proceed?
[21:02:36] <ulm> WilliamH: this concerns ia64 only?
[21:03:16] <WilliamH> blueness: I"m not bringing anything here for a vote right now, just wanting to know what the rest of the council thinks...
[21:03:42] <WilliamH> ulm: let me pull up the bug again...
[21:03:46] <dberkholz> WilliamH: are you looking for something more along the lines of force-stabilizing newer versions or dropping stable?
[21:04:39] <rich0> We solved this in theory for a few specific archs, but we didn't make it a general policy, notably for x86/amd64.
[21:05:36] <WilliamH> ia64 is the one arch on that bug we solved it for.
[21:05:57] <WilliamH> We allow removal of stable versions on that arch.
[21:06:42] <WilliamH> It is the other arch's that haven't responded that we didn't do anything for, see the decision I pointed to in the bug.
[21:07:47] <blueness> what about a policy allowing devs to stabilize their own packages after a timeout?  provided they ahve access to the arch
[21:08:01] <dilfridge> I understand that it's frustrating if the stablereq bug is just silent for ages
[21:08:02] <blueness> that sounds a bit dangerous
[21:08:04] <rich0> Would that help here?
[21:08:15] <dberkholz> blueness: it sounds like the way we did things before starting arch teams
[21:08:24] <blueness> dberkholz, and how did that go?
[21:08:25] <ulm> maybe we could go for something along the lines of "after x days, responsibility for the old stable ebuild will move from the pacakge maintainer to arch teams still relying on it"
[21:08:30] <rich0> Ultimately our choices are to help push along stable, or drop it.
[21:08:36] <rich0> Or keep the old package around.
[21:08:47] <ulm> although I'm not sure if that wouldn't lead to a total mess
[21:08:49] <dberkholz> blueness: reasonably well, it was largely a time sink for people who wanted to work on other things
[21:08:55] <WilliamH> Before we had arch teams we stabilized our own stuff after 30 days
[21:08:56] <rich0> Pushing potentially affects quality, dropping potentially destroys stable, keeping frustrates maintainers.
[21:09:05] <dberkholz> blueness: small quality hit but less than you might think
[21:09:14] <blueness> dberkholz, i self stabilize only hardened specific packages, hardened-sources and gradm
[21:09:29] <blueness> dberkholz, we could have a hybrid
[21:09:43] <rich0> If you drop stable entirely then basically all users end up moving to ~arch anyway, so is pushing harder on stable really an issue, such as by letting maintainer stabilize.
[21:09:44] <blueness> the self-stabilize after a timeout
[21:09:44] <WilliamH> ulm: No, keeping the old package still causes issues.
[21:10:00] <rich0> I thik letting the maintainer stabilize makes more sense than dropping stable entirely, especially for something like openrc.
[21:10:09] <blueness> rich0, i agree
[21:10:17] <rich0> No stable openrc basically means no stable at all.
[21:10:57] <WilliamH> I could go with a policy that allows maintainers to auto stabilize after a timeout.
[21:11:01] <_AxS_> rich0: in the case of openrc (at least this time) it's not just openrc iirc -- kmod is also interrelated here.  at any rate, often multiple packages need to go stable together.
[21:11:07] <dberkholz> the argument is always what stable means
[21:11:18] <dilfridge> there is no easy solution
[21:11:24] <dberkholz> does it mean actually tested by an arch user, or does it mean we try to provide you with something that we hope works
[21:11:38] <ulm> dberkholz: the former
[21:11:44] <dberkholz> with the aim of not breaking your upgrades vs not breaking your running system
[21:12:00] <ulm> ~arch is the latter
[21:12:15] <ulm> and no keywords or masked means we don't know if it works
[21:12:20] <dberkholz> i would prefer to drop stable vs force-stable untested software, then people have to explicitly ~arch it
[21:12:29] <dilfridge> +1
[21:12:57] <rich0> dberkholz: good point
[21:13:05] <rich0> at least they know what they're getting
[21:13:21] <rich0> though that raises the question of whether stable packages can depend on unstable
[21:13:29] <dberkholz> alright WilliamH, do you want to kick off a discussion on -dev about a broader stabilization timeout for more arches and possible options
[21:13:36] <rich0> If not you end up cascade-destablilizing half the tree for a critical dep
[21:13:40] <dberkholz> we could discuss this for a long time here and not make much more progress i think
[21:13:59] <ulm> rich0: that question is sort of moot if you don't have stable openrc
[21:14:02] <rich0> ++ - I like the discussion so far, but this isn't going to get resolved in this meeting
[21:14:24] <WilliamH> dberkholz: I can do that, but it is basically two options. 1) allow maintainers to stabilize after 90 days, or 2) removing stable packages.
[21:14:38] <rich0> ulm: my thought is that there is a difference between package.keyword for just openrc vs having to accept ~arch for the entire tree
[21:14:45] <dberkholz> or 3), make maintainers leave old ebuilds around
[21:14:52] <blueness> rich0, should we bring this up on #gentoo-dev ... the fact that we don't ahve the manpower for stabilizatoin we used to
[21:14:56] <blueness> and see what the community wants
[21:14:57] <rich0> WilliamH: sure, but there could be nuances and we can at least hash it out.
[21:15:07] <rich0> ++
[21:15:24] <rich0> we aren't going to make the problem go away with any decision - I think this needs some open discussion/debate
[21:15:36] <ulm> rich0: my point was that we don't need to care about tree consistency if important packages are missing from stable
[21:16:04] <ulm> for the affected archs, that is
[21:16:20] <WilliamH> ulm: the issue seems to be that arch teams don't see system packages as more  important than others...
[21:16:29] <rich0> sure - I just wanted to toss it out there - it is a change in the letter of policy
[21:16:42] <WilliamH> ulm: I just remembered another part of the irc conversation I had.
[21:16:45] <rich0> letter of policy suggests that if you de-stabilize glibc you de-stablize 80% of the tree
[21:16:49] <dilfridge> that (@system) is actually a good point
[21:16:52] <ulm> WilliamH: was this ever different?
[21:17:22] <ulm> I still remember waiting for stabilisation for about one year in 2007 or 2008
[21:17:30] <ulm> on minor arches
[21:17:47] <blueness> that's why i'm glad mips is ~arch!
[21:17:53] <blueness> it makes my life so much easeri
[21:18:00] <dberkholz> alright, let's wrap this meeting up
[21:18:19] <ulm> blueness: I think it even was on arm then ;)
[21:18:22] <dberkholz> thanks all for helping make progress on a couple of tricky and useful issues
[21:18:46] <dberkholz> till next time! i'm chair next time and then handing off to blueness for march
[21:18:51] <ulm> dberkholz: thank you for chairing
[21:19:03] <dilfridge> thanks everyone!
[21:19:09] <blueness> ta ta
[21:19:13] <dberkholz> thanks ulm for prodding on notifications =)