[19:59:47] have we started already? [19:59:52] -*- dilfridge here [19:59:56] -*- WilliamH is here [19:59:58] dilfridge: not really ;) [20:00:00] -*- blueness here [20:00:00] nope [20:00:01] no we haven't started. [20:00:09] I'm sure we're all listening in though :) [20:00:12] now it's 1900 [20:00:12] false start :D [20:00:14] we are [20:00:18] -*- dilfridge reads backlog [20:00:34] so speak up, councilors [20:00:37] dilfridge, don't read the backlog, it iwll damage your brain forever! [20:00:41] -*- ulm here [20:00:45] nah it is just fun to read and be quiet :) [20:00:47] -*- scarabeus here [20:00:56] -*- blueness here again [20:01:05] -*- rich0 still here [20:01:17] ok that's everybody [20:01:38] i attempted to order the topics so that the more controversial stuff was at the end, so we don't end up debating that for the whole meeting [20:01:56] -*- WilliamH is here [20:02:36] first off, i just wanted to note that the gpg signing glep is now an actual glep, although robin hasn't requested a vote yet [20:03:11] dberkholz: yeah, I made that stuff, but I want to read the eu crypto regulations and discuss them with robin first [20:03:40] dberkholz: can you please link the agenda real quick? [20:03:47] next time we should be able to finish it, there just wasnt enough time for the 90 pages [20:03:56] yeah it's here: http://dev.gentoo.org/~dberkholz/council_agenda_20140225.txt [20:04:06] do we need a final vote on the gpg glep? [20:04:24] there are minor changes between robbat2's mail and the wiki version but nothing serious [20:04:34] so hopefully next meeting we can vote on that [20:04:40] k [20:04:43] I recommend we wait until next meeting with the formal vote, or do it in between via bug [20:04:49] I think it needs a bit of documentation cleanup, but the policy side looks fine to me [20:04:53] -*- blueness is collecting agenda items already ;) [20:05:05] dilfridge: can you explain point 8. of the Recommendations section in a nutshell? [20:05:16] wait [20:05:21] -*- dilfridge fires up browser [20:05:32] that fifthhorseman thingy [20:06:10] yeah, that had me scratching my head [20:06:13] Didn't dig up the docs. [20:06:21] for the details you have to ask robbat2, but as far as I can remember it's a workaround for a protocol weakness (which will be hardcoded in some future standard) [20:06:31] --> dwfreed (~dwfreed@encoded/developer/dwfreed) hat #gentoo-council betreten [20:06:34] it was discussed on the ml long time ago [20:06:42] k [20:06:50] I'll try to dig it up then [20:06:56] Is that a literal, or is that a ? [20:07:09] the fifthhorseman bla is just some arbitrary identifier, which was once chosen on the gnupg mailing list [20:07:41] That wasn't obvious to me. [20:07:42] my internet is slow, can anyone give me a direct link to the wiki page? [20:07:49] https://wiki.gentoo.org/wiki/GLEP:63 [20:07:57] -*- dilfridge is on gsm / gprs [20:08:29] 10s quassel lag [20:09:06] afaik gnupg inserts some variable there a la printf [20:09:11] page still loading [20:09:25] --> grknight (~Thunderbi@50.120.197.130) hat #gentoo-council betreten [20:09:32] In any case, that was the sort of thing I meant by doc issues- it is a bit hazy on how to follow the guide. The policies themselves seem fine. [20:09:53] rich0, ditto regarding setting an expiration date [20:09:58] It references some general howtos, but simply following those doesn't ensure compliance [20:10:02] sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g [20:10:43] the %g is replaced by gnupg. the issuer-fpr@notations.openpgp.fifthhorseman.net= is an identifier that was once (arbitrarily) chosen and stays the same now. [20:10:56] k [20:11:03] alright [20:11:04] not very obvious, though [20:11:13] that's all I can say right now [20:11:24] yeah it would be great if few people who are not gnupg experts could try running through it and see how it goes for them [20:11:27] such as all of you [20:11:44] and then report back on your experiences and any issues that crop up [20:12:21] on that note, i don't think we're going to make any more progress today on the glep so let's move on, shall we? [20:12:25] so we postpone voting till next month? [20:12:32] yes please [20:12:32] ulm, yes [20:12:41] sounds good [20:12:43] item #1 next month [20:12:46] the first new topic is EAPI deprecation [20:13:16] anyone have any concerns to raise before we vote? [20:13:41] everyone seen these graphs? http://www.akhuettel.de/~huettel/plots/eapi.php [20:14:44] Yup - the QA meeting log was also helpful [20:15:02] dberkholz, do we vote on each eapi? [20:15:06] Honestly, they already covered most of the key observations [20:15:15] ie 4 votes/ [20:15:23] i'd like to try a group vote to just approve everything at once, unless someone has a specific concern [20:15:39] dberkholz, just one concern [20:15:44] eapi=0 and toolchain [20:16:03] blueness: the vote is to complain about eapi0 not ban it. [20:16:03] its only a warning, but much of the toolchain stuff is still eapi=0 [20:16:12] deprecation in general is no problem, with banning it's not 100% clear what it means [20:16:18] WilliamH, understood [20:16:35] so we should at least mention this in the minutes as a concern for eapi=0 [20:16:41] dilfridge: banning means no new ebuilds of that eapi are allowed [20:16:53] deprecation as a step to banning [20:17:01] WilliamH: right, adding a new ebuild file won't be allowed [20:17:04] Yeah, I have no issues with deprecating. Honestly, I wouldn't necessarily even mind a ban with a toolchain exception or whatever (they can just ignore repoman). [20:17:11] changing an existing one is still fine [20:17:12] how did that attempt to new eapi toolchain went actually? [20:17:34] scarabeus, i don't know, i never heard back from dirtyepic [20:17:49] I think it is being worked. [20:17:49] he said mgorny had done some work here, but i'm not sure its ready [20:18:20] ( In the QA meeting it came up that one needs to be clear whether you ban 1) in-place edits, 2) revision bumps and/or 3) new versions; in this case, "new ebuilds" would be interpreted as (2) and (3). ) [20:18:20] okey [20:18:32] new files simply is the best [20:18:35] blueness: on toolchain? not that i know of :) [20:18:37] ban anything that is new file [20:18:39] okay so the concern is noted for the minutes ... to keep in mind that we can't go the next step and ban eapi=0 without ack from toolchain when this comes up in the future [20:18:54] if you inline edit you are fine [20:18:54] you should actually not inline change eapi ever [20:18:56] ;) [20:19:09] alright. [20:19:10] by inline i mean in one file [20:19:21] how about security revbumps? [20:19:41] mgorny: same deal, new file = update the eapi [20:19:45] i don't think we should make special cases [20:19:58] 0 can stay 0 [20:20:05] 1 is practically irrelevant [20:20:12] 2 can be changed to 3 easily [20:20:36] k [20:20:55] i'm ready to vote on mass [20:20:57] en masse [20:21:09] yeah lets try first en masse :) [20:21:35] so i think the vote can be, deprecate EAPIs 0 and 3, and ban EAPIs 1 and 2. repoman should warn about new deprecated ebuilds and block new banned ebuilds. [20:21:37] How about we do a bunch of them at once instead? [20:21:57] dberkholz: one vote only? [20:22:03] WFM [20:22:09] I'm against banning eapi 2 [20:22:12] rich0: that's what we are doing ;-) [20:22:12] If it fails we can tweak it until it passes [20:22:12] if we can't manage to pass it in one vote, we can break it down [20:22:31] --> jdhore2 (~jdhore@gentoo/developer/jdhore) hat #gentoo-council betreten [20:22:54] can't we have the votes indicated in the agenda? [20:23:15] fine, i don't care. [20:23:28] vote to deprecate EAPI 3 [20:23:34] yap [20:23:35] -*- rich0 yes [20:23:36] -*- ulm yes [20:23:38] yes [20:23:39] -*- WilliamH yes [20:23:40] -*- blueness yes [20:23:43] -*- dilfridge yes [20:23:48] vote to deprecate EAPI 0 [20:23:51] -*- rich0 yes [20:23:52] -*- scarabeus yes [20:23:53] -*- ulm yes [20:23:55] yes [20:23:57] -*- dilfridge yes [20:23:57] -*- WilliamH yes [20:24:00] -*- blueness yes [20:24:09] a bit slower please :| [20:24:20] vote to ban new EAPI 1 ebuilds [20:24:24] -*- ulm yes [20:24:25] -*- rich0 yes [20:24:27] -*- dilfridge yes to ban EAPI 1 [20:24:29] -*- blueness yes [20:24:30] yes [20:24:31] -*- scarabeus yes [20:24:35] -*- WilliamH yes [20:24:43] vote to ban new EAPI 2 ebuilds [20:24:46] -*- ulm no [20:24:50] yes [20:24:50] -*- rich0 yes [20:24:51] -*- blueness yes [20:24:56] -*- scarabeus yes [20:24:57] -*- dilfridge abstain [20:25:04] -*- WilliamH yes [20:25:18] nice work, team. 4 votes in 2 minutes. [20:25:28] --> seemant (seemant@unaffiliated/seemant) hat #gentoo-council betreten [20:25:34] If only we could be paid by the vote... [20:25:41] do we get effectivity achievement? [20:25:46] rich0: wait you are getting paid? :D [20:25:52] next topic is "Stable keywords on testing architectures [20:25:57] scarabeus: what, you're not embezzling? [20:26:09] -*- WilliamH wants part of that paycheck ;-) [20:26:38] can someone clarify what archs we are talking about? [20:27:03] sh s390 m68k [20:27:06] ulm, the ones we dropped to ~arch [20:27:13] as dilfridge [20:27:33] what happened was vapier continued to mark m68k stable after the last concil vote to drop them to ~arch [20:27:56] blueness: not just m68k, all of them I think. [20:27:57] his point was that its not a problem because if we mark those arches exp in profiles.desc then repoman won't complain [20:27:59] not just m68k, all of them [20:28:13] dilfridge, WilliamH oh okay, i only say the mass m68k stuff [20:28:30] I've seen some for s390 too [20:28:46] I don't have a problem with arch teams redefining "stable" for their arch, as long as it is clear that maintainers can ignore the flag and treat it like ~arch otherwise [20:28:56] leaving dependencies in inconsistent state, so repoman -d would barf [20:29:24] if it's "exp" repoman won't barf [20:29:27] ulm: that's why we would mark the profiles exp in profiles.desc [20:29:54] that's repoman -e then? [20:30:02] -*- ulm never used that one [20:30:05] ulm, i think so yes [20:30:17] --experimental-inherit= [20:30:17] Enable experimental inherit.missing checks which may misbehave [20:30:17] when the internal eclass database becomes outdated. [20:30:33] sorry [20:30:37] -e , --include-exp-profiles [20:30:38] -e , --include-exp-profiles= [20:30:38] Include exp profiles in dependency checks. [20:30:39] include exp profiles in dependency checks [20:30:40] -e , --include-exp-profiles= [20:30:40] Include exp profiles in dependency checks. [20:30:42] yeah [20:30:49] :) [20:31:00] so we can have it both ways [20:31:25] -*- WilliamH doesn't have a problem with marking the profiles exp and being done with it ;-) [20:31:33] developers can ingore stable/unstable for sh/s390/m68k (and not do repoman -e) [20:31:39] i'm pretty happy with the 'exp' solution [20:31:49] --> Chainsaw (~chainsaw@gentoo/developer/chainsaw) hat #gentoo-council betreten [20:31:50] while those arch teams that want to mark stable and keep consistent stable can use repoman -e [20:31:53] anyone got an issue to raise with it, or should we vote? [20:31:59] i'm ready to vote [20:32:00] me too... one suggestion, [20:32:17] maybe eshowkwd could group exp-only arches out somehow [20:32:27] but that's a technical detail. [20:32:44] -*- WilliamH agrees [20:32:55] it shouldn't stop this vote [20:33:06] sounds great, look forward to that commit [20:33:33] Never realized eshowkwd even existed prior to that thread. I still have grep KEY * on the brain. [20:33:34] dilfridge: the problem is that "stable arch" and "arch having stable keywords" are not the same thing [20:33:50] eshowkw [20:33:51] yes [20:33:53] no d at the end [20:33:56] that is something for the future [20:34:27] I want to bring that up, because i agree with kensington that profiles.desc is not really the right place to define which arch is stable [20:34:27] blueness: it is quite straight forward to reorder/whitespace/etc there [20:34:31] ulm, i like that distinction -> "stable arch" vs "arch having stable keywords" [20:34:42] does this working make sense? minor archs with inconsistent keywording should be marked 'exp' [20:34:45] wording* [20:34:52] yep [20:35:11] but the profiles.desc semantics is something for a future meeting. [20:35:25] yes [20:35:35] and we should have more types there [20:35:40] (meaning of "stable" profiles vs. arch having stable keywords) [20:36:01] -*- WilliamH doesn't get the distinction. [20:36:20] dilfridge: I encounter the same problems in app-emacs/ebuild-mode [20:36:31] which also has some keywords logic [20:36:56] WilliamH, package maintainers don't have to worry about stable keywors on "minor arches that have stable keywords but are not stable arches" [20:37:27] WilliamH: too complicated to describe now on the fly... mailing list first [20:37:38] exp = minor arches that may or may not have stable keywords [20:37:58] dilfridge: ok [20:38:16] alright, let's try a vote: minor archs with inconsistent stable keywording should be marked 'exp' [20:38:53] -*- WilliamH yes [20:38:58] yes [20:39:02] -*- blueness yes [20:39:04] -*- rich0 yes [20:39:08] -*- ulm yes [20:39:26] -me yes [20:39:31] -*- dilfridge yes [20:39:36] cool. [20:39:53] the 2nd half of this issue seemed more complex and i don't know if we can resolve it today [20:40:12] The non-responsive arch concern? [20:40:17] what should be done about keywords on 'exp' archs when cleaning old ebuilds [20:40:39] I suspect the concerns went beyone the 3 exp ones. [20:40:40] dberkholz, don't worry about them ;) [20:40:55] don't give square about them i agree [20:41:02] But next meeting is in two weeks. I can try putting some proposals out on the list to try to summarize the options. [20:41:06] -*- WilliamH agrees [20:41:32] If an arch is set to exp don't worry about the keywords [20:41:32] dberkholz, scarabeus this is like mips, i just add/remove ~arch keywords to packages and no one knows the difference [20:41:47] because mips falls under the radar of repoman [20:42:19] but mips is "dev"? [20:42:19] I think the exp ones are easy - prune at will. The non-exp ones are more of an issue. Once upon a time they had time to stabilize something, now they don't. [20:42:24] no maintainer gets annoyed that they have to stabilize dependecny [20:42:30] ulm, it shouldn't be in my opinion [20:42:35] its dev but with ~arch only [20:42:37] ulm: no, it is exp? [20:42:48] it should be exp with both stable and unstable [20:42:51] WilliamH, its both [20:42:52] It should be exp probably if it isn't. [20:42:55] WilliamH: some of its profiles are dev [20:43:17] WilliamH, ulm its *effectively* exp because everything is ~arch [20:43:20] mips doesnt have "inconsistent stable keywording" [20:43:35] dilfridge, precisely [20:43:35] it has no stable keywording, meaning it can well be dev [20:44:06] dilfridge, it might be meaningful to reduce it all to exp and start adding stable keywords as vapier does for sh/s390/m68k [20:44:07] there's nothing wrong with an arch being in 'dev' if it's all ~arch keyworded. it would probably have to get moved to 'exp' if someone wanted to start a stable version of it, during the keywording process [20:44:13] dilfridge: that's a simantics issue, but it probably should be exp. [20:44:15] we've been talking about it in the mips team [20:44:36] dberkholz, exactly -> there's nothing wrong with an arch being in 'dev' if it's all ~arch keyworded. it would probably have to get moved to 'exp' if someone wanted to start a stable version of it, during the keywording process [20:44:37] but that is again going painfully in the direction of profiles.desc semantics [20:45:29] dberkholz, so what's the second half of the vote? [20:46:16] according to the agenda there isn't one? [20:46:34] yeah, i wasn't really sure whether we even needed to make a decision. [20:47:01] do we need to say it's ok to drop the last stable version for an 'exp' arch? [20:47:13] No, that's understood. [20:47:37] dberkholz, there is no expected consistency [20:47:44] because you don't care about keywords for an exp arch. [20:48:26] fair enough [20:48:44] i don't think there's anything else we need to decide on this topic, then [20:49:26] let's move on to the whole gtk/QA kerfluffle [20:49:37] yay [20:49:37] permission to address the council about this? [20:49:58] my expectation today is that we will be able to vote on the first part of this but probably not the second [20:50:09] creffett|irssi: sure, no problem, go ahead [20:50:14] dilfridge: thank you [20:50:27] just wanted to say a couple things about this from my perspective as QA lead [20:51:04] first, there was basically no outcome of the GTK situation that would please everyone. Either we vote as we did and tick off GNOME, vote to keep the GNOME solution and tick off a different set, or do nothing and tick off a third set of people [20:51:47] I know we don't know all the intricacies of the GTK situation perfectly, but the thing is, we (or at least I) voted this way because I feel that the GNOME team solution does not really make sense. [20:52:02] and I got the impression from the ML discussion that several non-GNOME devs feel that way [20:52:33] now, I know there were concerns that we did not give enough time for debate, but this is a topic that has been argued for a long, long time, and I felt that further discussion would not bring up anything new [20:52:55] so we voted, we decided as we did, and now we get to deal with the results [20:53:12] nothing further from me [20:53:37] creffett|irssi: curious as to whether you still feel discussion would profit more in light of today's thread? That is, anything new/concerning here from your perspective? [20:53:48] rich0: which part of the thread? [20:53:56] Everything sent today on -dev. [20:54:10] Just whether any of that hasn't already been considered by QA. [20:54:44] You could be forgiven for not keeping up for the last few hours. :) [20:54:44] I'm sorry, but I don't have the ML in front of me right now [20:54:49] np, thanks [20:55:12] -*- creffett|irssi has to run now, very sorry about that, will try to get back on in a few if possible [20:55:46] let's start with the whole QA tree policy thing [20:55:58] So, I already said this on the list, but I think that in general it might not hurt to propose policies but give a little time for comment before they're effective, when not urgent. [20:56:28] is the right vote/wording whether QA owns tree policy? [20:56:29] rich0: there is nothing currently stopping qa from doing that. [20:56:33] I have no issues with QA being able to set policy like this. Maybe there are lessons to be learned about how to go about it. [20:56:44] WilliamH: agree completely. [20:56:50] may I address the council about this? [20:56:56] well, this was discussed in two monthly qa meetings [20:57:02] dberkholz: "has authority over tree policy" (as in the agenda) sounds better [20:57:08] rich0: The question was whether qa has the authority to set tree policy. [20:57:11] k [20:57:14] chithead: yeah go ahead [20:58:46] WilliamH: However, it could become a requirement that QA need to have non-crucial policy changes survive two meetings; in the first meeting, we vote on it being a proposal and if it survives that as well as further thoughts the following meeting will make the proposal policy. (Although, I think it is kind of what a council decision overriding QA does; a different party looking into it, fair approach) [20:59:29] chithead: ? [20:59:30] thank you. basically, leio summed up the reasons why I think that QA should not have tree policy authority in his most recent email (19:49 utc) to gentoo-project. there is no proper process in place, and maintainers feel that their concerns have not been taken into consideration enough [21:00:34] that doesn't seem to be a problem with QA owning policy [21:00:34] chithead, can you repeate leio's point here in brief [21:00:46] so much as it is a problem with how they're going about implementing changes in it [21:01:28] chithead: do you mean this mail? http://article.gmane.org/gmane.linux.gentoo.project/3339 [21:01:32] AFAIR, leio was even present at the last QA meeting [21:01:51] Understand leio's concerns. QA really is new to all of this, and I think we should give them the opportunity to correct/etc. I defintely support them putting things out for comment. That said, when issues arise people have to be prompt about dealing with them. [21:02:00] -*- WilliamH needs to go now [21:02:21] I quote him: "I applaud such initiatives of consistency, however I severely question the process in which this has been undertaken. [...] We are suggesting to be part of a due process to come up with a properly discussed, agreed and with all use cases thought about and considered properly." [21:02:29] I get a bit concerned that sometimes when policies are being created everybody is quiet, and then after they're proposed suddenly there is a mess. [21:02:29] ulm: leio's point was that he was present but not prepared, as he just happened to be around at the time [21:02:38] I want to add a quick comment. [21:02:44] chithead, thank i got the point [21:03:17] I felt that way a bit with the -project thread. I think decent points were raised, it was just a bit frustrating that they get raised two hours before the meeting. [21:03:31] rich0, ++ [21:04:08] To be honest, I'm a bit astonished why the qa vote so much surprised everyone. The discussion was ongoing for a while, and it was perfectly clear they were going to vote, long before the meeting. [21:04:14] Devs aren't required to read -dev, but that doesn't really mean that you get to pick apart everything after the fact... [21:04:31] i need to go in the next 10 minutes or so too, fyi [21:04:41] i'd like to get through at least the first vote [21:05:16] dberkholz, regarding the question whether "QA owns tree policy" i would have difficulties voting either way because its sounds too open ended [21:05:22] first what do you mean own? [21:05:30] I don't think the role of QA needs any change. Certainly we need to find better ways of working together, but I wouldn't put all of that on QA. I don't think a policy change RE GLEP48 and such is warranted. [21:05:31] enforce policy set by council? [21:05:39] or set their own policy and enforce it? [21:05:55] i mean creates policy as glep 48 states about qa standards [21:06:12] I have no issues with them setting policy, and it is already subject to council override if necessary. If that becomes a regular occurence we can always revisit. [21:06:16] dberkholz, in that case, why a new vote? [21:06:18] its already there [21:06:32] rich0: (Responding to "QA really is new") Imo the QA team needs to apply more knowledge codification and be more public with things; I think it is fundamentally wrong that https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL%20blocked%3A420493 (which came up in private to the QA team the first week of January) didn't come up in public, etc...; I think we should also contact or even invite affected [21:06:34] parties to the agenda, meetings, ...; as well as write down cases and their associated information on the wiki, etc... It takes a bit of getting used to before we get to good practices (kind of like the QA team applying QA on themselves). [21:06:38] sort of back, nothing to say about what has been said so far [21:06:41] I think that the gtk flag was fair game for them. It affected more than just gnome, and there were inconsistencies in the tree. [21:06:55] it would be the interpretation whether QA can have "QA standards" means that they can introduce new tree policy [21:06:56] blueness: because we're the council and it's our job to address issues that gentoo devs ask us to deal with [21:07:36] dberkholz, true but i wanted clarification on what we were voting on [21:07:46] it wouldn't be fair of me to just leave it off the agenda because i personally disagree. if someone thinks it's unclear, then it may be worth clarifying [21:08:01] dberkholz, of course [21:08:09] dberkholz: ++ yup, we can vote even if it is just to say that no further action needed, or whatever [21:08:32] then everybody gets to beat us up - that's why we're paid so much [21:08:40] lol [21:08:48] yeah, i am going to need a beer after this meeting is over. [21:09:25] dberkholz, we can just reaffirm then that qa has the right under glep 48 to address the question of the gtk* flag names [21:09:45] <-- graaff (~graaff@gentoo/developer/graaff) hat das Netzwerk verlassen (Quit: Leaving) [21:09:54] blueness: ++ [21:10:18] flag names and functionalities [21:10:52] I certainly encourage them to consider the latest feedback/etc, and discuss. They can try to be more proactive about putting proposals on -dev or whatever. [21:11:10] ok [21:11:40] They should also reply on -dev about expectations around when their policy goes into effect, that is if they want to tweak it, or if they still want it to be the "final answer" [21:11:48] well that's my second point, i think qa and gnome should keep talking, i couldn't keep up with the nuances of the gtk+{,2,3} meanings [21:12:22] blueness: ++ - yup, my intent earlier was to probe, not to gloss over. I think there are some legitimate questions that are bigger even than gtk. [21:12:36] Libs vs consumers of libs, and so on. [21:12:37] so should we vote to clarify that QA's right to create standards in glep 48 includes flag names/functions [21:12:51] dberkholz: ++ [21:12:54] dberkholz, yep [21:13:04] yeah let's vote [21:13:07] alright, let's do it. consider that the vote. [21:13:09] we are acting as judges interpreting the law [21:13:28] -*- rich0 yes [21:13:30] yes from me [21:13:32] -*- blueness yes [21:13:49] -*- dilfridge yes [21:13:58] I abstain, because I'm QA member myself [21:14:08] (and it already has a majority) [21:14:11] yeah conflict of interest [21:14:22] alright that's 4 in favor, 2 abstaining (including williamh who's gone) [21:14:33] scarabeus? [21:14:57] doesn't really matter i guess but you can get your voice heard =) [21:14:59] sorry disconnected 2 mins ago [21:15:03] gimme time to read [21:15:08] yep [21:16:14] -*- scarabeus votes yes [21:16:18] k cool [21:16:57] open floor? [21:17:04] i think that negates the next point about gtk flag names, yeah. [21:17:34] so to be clear, yoj are affirming QA's decision? [21:17:51] *you [21:18:40] we are affirming qa possibility to make the decision [21:18:52] okay [21:19:01] creffett|irssi, my reading is that you do have the right to set flag name/function policy, but i personally would urge you to work with gnome on this [21:19:27] creffett|irssi: Given I assume that you missed out on leio's mail; he has asked the council to not address it this time, as to have the GNOME team and QA team discuss this further outside of this context. From what I recall in #gentoo-desktop, Eva was writing up something based on the blocker bug; so, I suspect they will bring reasoning forward soon, feel free to ask leio for confirmation about this [21:19:29] and what GNOME team's plan about this is. [21:19:31] you can do what the heck you want there, but if people come screaming to us you didn't talk you should be backed up by hard evidence [21:19:38] Yes, we didn't explicity uphold or denonuce the decision [21:19:57] i think we should wrap for today [21:20:11] Open floor? [21:20:12] dberkholz, when do we have the next meeting? [21:20:12] let that discussion with QA and gnome continue, since it's obviously still ongoing [21:20:15] basically, we're saying this is within your rights to do. [21:20:23] because we were off schedule? should i try to get us back on? [21:20:37] blueness: suggest we get back on the original schedule - two weeks [21:20:43] rich0, will do [21:20:48] i'll send out the call for items tomorrow [21:20:55] i would do that, yeah. next one on march 11 [21:20:59] k [21:21:08] let's have open floor for a couple of minutes and then close [21:21:25] anyone, council or not, got new issues to raise? [21:21:38] I think council was asked to explicitly affirm the gtk flag policy? [21:21:38] (my dogs says, let's go for a walk NOW!) [21:21:52] we have a problem with banning EAPIs 1 and 2 [21:21:54] Okay, in the context of the MATE discussion; I would like to ask the council whether one should prefer "consistent category naming" or whether one should prefer "bigger categories over smaller categories"? [21:21:58] with "eapis-banned = 1 2" in layout.conf repoman will complain about any ebuild with these EAPIs being present [21:22:08] so repoman needs to be patched [21:22:32] I've deprecated 0 and 3 in layout.conf, for the time being [21:22:43] ulm, that doesn't seem a big deal, is it? [21:22:55] ulm: didnt expect otherwise... let's talk to the portage guys [21:23:01] ulm: no issues with delaying implementation of the policy until things are fixed/etc. [21:23:10] exactly [21:23:18] chithead: what i said there was 20:20 < dberkholz@> let that discussion with QA and gnome continue, since it's obviously still ongoing [21:23:22] ulm: Not that I speak for creffett, but creffett|irssi and I (or anyone interested) could patch repoman to do as such. Otherwise this becomes a PMS issue; which, I think we're not going to have addressed any time soon. [21:23:52] Well, we can consider it banned even if repoman isn't patched. [21:23:55] who is taking care of portage these days? is it dol-sen? [21:23:56] --> billie_ (~billie@gentoo/developer/billie) hat #gentoo-council betreten [21:24:04] Just nobody will be yelling at you for it just yet. [21:24:08] TomWij: layout.conf is not in PMS [21:24:14] blueness: A whole team, dol-sen is the leader. [21:24:22] open a bug [21:24:23] ulm: Sorry, excuse me; I'm reading between the lines. [21:24:51] (New leader in ~3 weeks IIRC) [21:24:52] TomWij: probably a new variable would be best [21:25:08] and keep the meaning of present eapis-banned [21:25:26] ulm: In that case; then yes, that would work. [21:25:28] TomWij: i tend to prefer bigger categories personally. [21:25:50] TomWij: i have a script around that makes recommendations on category size. probably d.g.o/~me/scripts/ [21:25:58] (And we name the other one in a way that it indicates "no new ebuilds" or so.) [21:26:24] TomWij: let's bikeshed this in #-portage ;) [21:26:29] dberkholz: Yes, someone brought up to me in #gentoo-desktop that past discussion(s) on the ML (eg. the new games category) reveals that larger categories are preferred. [21:26:36] TomWij: if you need anything more formal, next meeting is coming up in just a couple of weeks [21:26:56] TomWij: it's mainly pragmatic having to do with most new categories involving package moves for negligible benefit [21:26:59] Call for agenda will probably go out in the next day or two :) [21:27:12] alright, we're gonna close the meeting, but feel free to keep discussing here [21:27:15]