<ulm> agenda: https://archives.gentoo.org/gentoo-dev-announce/message/def6128d1ec624db82bed7c1d657a82d <ulm> roll call <ulm> !proj council <willikins> (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh * K_F here * WilliamH here * dilfridge here * mgorny here [19:01] * slyfox here * b-man here <prometheanfire> here [19:02] <dilfridge> did tamiko leave a message? [19:03] <ulm> does someone have tamiko's phone number? <dilfridge> yes <ulm> can you text him? <dilfridge> but only the german one, will do <dilfridge> sent [19:05] <dilfridge> maybe it even arrives somewhere :P <ulm> anyway, let's start [19:06] <Soap__> he was active earlier <ulm> first topic: architectures without teams <ulm> https://archives.gentoo.org/gentoo-project/message/f0c2d04a35252cc6d5a6e26b7745ce3b <ulm> mgorny: can you comment on this? <mgorny> i don't think i have anything to add, besides what has been said already [19:07] <mgorny> i think it should be a clear requirement that every arch is backend by an arch team <ulm> in my opinion it would be even more important to announce a new arch in the mailing list [19:08] <dilfridge> both <WilliamH> +1 <ulm> and if it's only to bikeshed the name of the keyword <WilliamH> ulm: heh <dilfridge> aarch64 :P <ulm> actually I was thinking of "openrisc" vs "or" [19:09] * tamiko is here! <mgorny> and that team has at least alias so people can contact it <tamiko> ... <ulm> good, so we're complete <tamiko> Sorry for being late. <prometheanfire> riscv? <WilliamH> tamiko: no big deal we are just getting started. [19:10] <slyfox> or finished :) <K_F> we likely want to separate handling of things forward and what to do with the current ones <mgorny> sorry, i seem to be having horrible lag <K_F> the latter likely requires some form of grace period <mgorny> given that creating a project is cheap and has the bikeshed property, i'd say we require that all new arches form a project with rfc etc. [19:11] <dilfridge> yep <WilliamH> +1 <dilfridge> including an alias as clear method of contact [19:12] <WilliamH> dilfridge: that's included in a project isn't it? <mgorny> well, a valid project contact e-mail <ulm> mgorny: how about this as a motion: "introduction of a new architecture keyword requires an RFC in the gentoo-dev mailing list and creation of a project for the architecture team" <mgorny> wfm <dilfridge> ++ [19:13] <tamiko> Sounds good. <ulm> please vote ^^ <K_F> to take bikeshed to meta, is "an" correct there? :) <dilfridge> yes <ulm> where, before RFC? * tamiko yes <K_F> requires an request for comment? <Soap__> K_F: yes <dilfridge> (both as a vote and for the an) [19:14] * ulm yes * mgorny yes * K_F yes * WilliamH yes * dilfridge yes <Soap__> you also say an RNA and a university * slyfox yes <dilfridge> K_F: the hilarious thing is, "a" and "an" is differentiated not through the spelling but the pronounciation <Soap__> exactly <ulm> K_F: it's "an X" and "a U" <slyfox> what is going on? [19:15] <ulm> accepted unanimously <mgorny> ulm: you've linked the old agenda <mgorny> https://archives.gentoo.org/gentoo-dev-announce/message/9daed86bffb02f05a681c9044c00d9ee is v2 <ulm> mgorny: indeed <ulm> thanks <ulm> should we apply this retroactively to nios2 and riscv? [19:16] <dilfridge> so we have a unanimous decision :) <slyfox> those just need a project to be created [19:17] * WilliamH has no idea what nios2 is. ;-) *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: in progress | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180114T18 | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.html | Agenda: https://archives.gentoo.org/gentoo-dev-announce/message/9daed86bffb02f05a681c9044c00d9ee" <mgorny> we should request a new project for each <slyfox> nios is an altera FPGA <dilfridge> there are exactly 2 ebuilds in the tree with nios2 keyword [19:18] <mgorny> given that vapier committed both, i suppose he should create and announce the project <mgorny> the question is, what should happen if he doesn't do that? <tamiko> Well, it looks like that riscv might make it into qemu relatively soon. (Sometime this year.) <Soap__> dont you want to add some more strings? <K_F> mgorny: that is a question for another day <tamiko> So having something around for system level virtualization would be nice :-] <mgorny> llvm has some support for both as experimental but they usually don't even compile [19:19] <dilfridge> so how about, let's give them 2 months grace time, and then we either have a project or the keywords and profiles are removed <tamiko> Agreed. <WilliamH> dilfridge: sgtm <K_F> wfm <ulm> motion: "arches that currently don't have a project page are required to create one within two months from now" <mgorny> 2 months are very long given that vapier is currently active <mgorny> and creating a project is few minutes' work [19:20] <ulm> one month then <dilfridge> wfmt <ulm> motion: "arches that currently don't have a project page are required to create one within one month from now" * tamiko yes [19:21] * K_F yes * ulm yes * slyfox yes * mgorny yes * WilliamH yes * dilfridge yes <ulm> unanimous <mgorny> should we suggest that we'll remove the arch and keywords if that doesn't happen? <ulm> let's decide about that in a future meeting [19:22] <ulm> are we done with this topic then? <K_F> yup <ulm> next: support for minor arches <ulm> https://archives.gentoo.org/gentoo-project/message/ccae9ae9b59dd5481822fbe5a87aab14 <mgorny> good enough for me <mgorny> well, i think we've figured out most of that already, so i'd focus on confirming what we've figured out [19:23] <mgorny> i.e. stable > dev > exp <K_F> as far as I could see there isn't actually any change there [19:24] <ulm> right <mgorny> and possibly requesting that developers don't introduce new depgraph breakage in dev <slyfox> if it causes confusion it has to be documented and placed somewhere where it's easy to find, say into profiles.desc <dilfridge> it's a pity that repoman is so slow [19:25] <mgorny> slyfox: i wanted to put it into devmanual but the current profile doc there is practically nonexisting <mgorny> so if anyone has time to fill it in and correct what's already there, that'd be apprecaited <mgorny> dilfridge: i'd say that shouldn't be a major problem, given that developers run repoman per package <WilliamH> There's supposed to be a new repoman comming, but I don't know how fast it is going to be. <dilfridge> otherwise we could have it warn in dev profiles on things that are errors in stable profiles <WilliamH> coming * <slyfox> devmanual also works <dilfridge> (by default, I mean) <mgorny> WilliamH: those repoman rewrites aren't going to make it faster, they only move code aroun [19:26] <ulm> mgorny: it's still single threaded, right? [19:27] <mgorny> maybe they should look into pkgcheck because pkgcheck doesn't seem to care much about no of profiles <mgorny> i haven't noticed any slowdown since i've enabled dev <mgorny> ulm: yes <WilliamH> pkgcheck/pkgcore doesn't support eapi 6 though does it? <mgorny> but i think it's mostly a matter of caching [19:28] <mgorny> but this is kinda off-topic <ulm> WilliamH: it does <mgorny> WilliamH: it does, except for subslot rebuilds <mgorny> (which aren't relevant for depgraph testing) <ulm> so, do we need to vote on anything here? <WilliamH> It doesn't look that way <tamiko> No need to vote on already established procedures, isn't it? [19:29] <mgorny> we may want to set some policies on moving profiles between dev/exp/stable <mgorny> but it kinda falls into the next topic <ulm> yes, let's move on <K_F> unless we want to clarify no depgraph breakage in dev, and we likely want procedure at least for moving anything to stable <K_F> to/from <ulm> next topic: Profile changes [19:30] <ulm> https://archives.gentoo.org/gentoo-project/message/c9fe58b905fa0b7722a99c6de0e59dbc <ulm> grknight doesn't seem to be here <WilliamH> I would say this is pretty simple, just announce the change somewhere. <mgorny> well, there are multiple things about profiles to be tackled here [19:31] <WilliamH> g-d-a probably <dilfridge> that announcement doesnt really help <K_F> WilliamH: thats not sufficient for users <dilfridge> squirrel? <mgorny> for a start, i wanted to add explicit maintainer tags to profiles.desc <mgorny> https://archives.gentoo.org/gentoo-dev/message/326a59a862508ed72c7d5fcae101429d <mgorny> this would at least let people know who they should contact before they want to change some profile [19:32] <WilliamH> K_F: maybe a newsitem? <K_F> WilliamH: the newsitem is the current source of confusion <dilfridge> the profiles need to be somehow marked in eselect output <mgorny> i think ulm has done that [19:33] <ulm> dilfridge: 1.4.11 outputs the status <mgorny> and i've added big fat warning in handbook <mgorny> https://wiki.gentoo.org/wiki/Handbook:Parts/Installation/Base#Choosing_the_right_profile <K_F> dilfridge: that'd be a step in right direction <prometheanfire> profile grouping in eselect? like the php eselect module does for fpm,cgi,cli? <ulm> dilfridge: bug 643864 <willikins> ulm: https://bugs.gentoo.org/643864 "eselect profile list should display the profile status (stable/dev/exp)"; Gentoo Hosted Projects, Eselect; RESO, FIXE; floppym:eselect <dilfridge> mhh, ok good <dilfridge> I wonder if we should maybe add another property to profiles then [19:34] <ulm> dilfridge: also, it won't you select an exp profile any more <ulm> or only with --force <dilfridge> right now stable/dev/exp mainly addresses repoman / consistency <ulm> yes <mgorny> i don't think stable/dev/exp is really the point <mgorny> it's more about version <mgorny> we don't want people to upgrade to newer version without reading the news item first [19:35] <K_F> isn't that solved easily by keeping profile in dev until it is ready to hit users? <WilliamH> mgorny: there's nothing we can do about that. <K_F> which would ensure consistency anyways <dilfridge> K_F: not really (do you run repoman with -d?) <K_F> dilfridge: sometimes.. but doesn't change things, really <K_F> would need some tinderbox runs etc and attention before moving from dev to stable, sure [19:36] <mgorny> i still think the main point is documentation <mgorny> if we should make eselect-profile more foolproof <WilliamH> There's not much more that can be done mgormy <K_F> dilfridge: announce X(>=30d) days ahead, expecting to move profile to stable, so devs run with -d <ulm> mgorny: eselect is just a tool for convenience there <ulm> users can still set the link manually, and then there's no protection either [19:37] <K_F> I'm fine with that <dilfridge> ok <ulm> I also think it's a matter of documentation and announcing it <K_F> also a bit about timing [19:38] <mgorny> then we should first decide which transitions are 'safe' and which are not <mgorny> or as an easy way out, we may just reject any profile changes if user has any unread news items ;-) <mgorny> ulm: yes, and users can ignore status field in profiles.desc too <K_F> shouldn't add too many changes at same time <K_F> but I don't think we should have any specific policies on it <WilliamH> +1 <WilliamH> We can't protect users from shooting themselves in the foot on this one. [19:39] <ulm> anyone wants to bring forward a motion for this topic? <K_F> I believe we have a suggestion for maintainer for profiels <K_F> profiles* <K_F> although I'm fine with deferring that to QA <ulm> K_F: do we need to vote on that? * WilliamH doesn't think that needs a vote [19:40] <ulm> it's a comment in a file :) <K_F> ulm: probably not :) <ulm> I'd suggest moving on. further discussion in mailing lists <mgorny> let's say we're open to improving the situation if someone has good ideas <mgorny> but the policies in place are good enough <ulm> +1 <dilfridge> ++ <ulm> so, open bugs <tamiko> ++ [19:41] <ulm> bug 635344 <prometheanfire> git log shows it as well (who touches what) <willikins> ulm: https://bugs.gentoo.org/635344 "[TRACKER] manifest-hashes replacement"; Gentoo Council, unspecified; CONF; mgorny:council <tamiko> prometheanfire: Yes, indeed. <ulm> seems that this one is work in progress <mgorny> nothing new there <tamiko> prometheanfire: My number one tool to figure out who has worked on a given ebuild. <mgorny> i mean, besides mroe packages being updated <ulm> yeah, and most of them by yours truly :) [19:42] <ulm> bug 637328 <willikins> ulm: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; CONF; mgorny:security <ulm> any progress there <ulm> ? <ulm> K_F: ^^ <slyfox> no comments on the bug from security@ <K_F> I spoke with security <prometheanfire> tamiko: I use `tig FILENAME`, shows the diffs as well [19:43] <K_F> there is work in progress on updating it <ulm> k <ulm> bug 642072 <willikins> ulm: https://bugs.gentoo.org/642072 "Joint venture to deal with copyright issues"; Gentoo Council, unspecified; CONF; mgorny:council <ulm> nothing actionable by the council (only), I guess [19:44] <mgorny> might be nice to find a champion for that <mgorny> maybe try to streamline the work <prometheanfire> ulm: that bug is on foundations tracker [19:45] <K_F> the way I see it it is mostly a foundation matter <ulm> mostly, yes <prometheanfire> my suggestion is we go over that in the joint meeting, iirc alicef and mgorny both had intrest there <K_F> wfm <ulm> wfm too <tamiko> wfm [19:46] <WilliamH> I guess there'll need to be a way to release devs like myself who have been around long enough from our signed copyright assignment agreements. <mgorny> i'm mostly interested in seeing it done, i don't have any specific knowledge <dilfridge> sounds good <ulm> so, open floor then? *** ulm (~ulm@gentoo/developer/ulm) has changed mode for #gentoo-council to -m <tamiko> Open floor it is :-) <ulm> anyone? <mgorny> i think we wanted to confirm arm64 effort to become stable arch <dilfridge> right <WilliamH> Is there anything for us to do there as the council? [19:47] <mgorny> not sure if we need to confirm every arch though <mgorny> as far as i'm concerned, every arch team can mark its keyword stable when the depgraph is good * WilliamH thinks this is just an arm64 thing. <K_F> as a principle I'd prefer that we do, actually <WilliamH> mgorny: ++ <mgorny> i'm kinda wondering about mips <WilliamH> We don't need to micromanage that <dilfridge> I'd prefer if we do, but I see no problems in this specific case <Soap__> mgorny: like there are really extant arch teams [19:48] <mgorny> i'm wondering if mips can have stable profiles if they don't have stable keywords <K_F> mgorny: probably shouldn't <slyfox> to build stage3 it's better have something that works [19:49] <dilfridge> well, why not, but that brings us to the question again, where is "arch is stable" defined? <mgorny> technically i don't see a reason why not but i think some people may be confused <mgorny> dilfridge: which brings us to your glep <ulm> dilfridge: only in repoman documentation, I fear <dilfridge> yes <mgorny> i think we should disjoin it completely <dilfridge> I'll try to come up with a new version for the next meeting <mgorny> leave profile status only for repoman/pkgcheck/eselect-profile suggestions [19:50] <WilliamH> mgorny: ++ <mgorny> and define arch keywords independently of it <ulm> arch status != profile status, yes <dilfridge> exactly <mgorny> until we have glep for it, i think bugzilla arch field is a good place for that <dilfridge> wfm <mgorny> which brings me to my next question <mgorny> what about stable keywords on m68k/sh [19:51] <dilfridge> ENOGLEP <dilfridge> sorry <mgorny> should we request people to CC those arches on stabilization requests? <dilfridge> no <WilliamH> mgorny: that is up to the m68k/sh teams <dilfridge> ENOTEAM <mgorny> WilliamH: well, they obviously want to stabilize stuff [19:52] <ulm> I generally CC them if there are stable keywords for a previous version <mgorny> they process stabilization requests <K_F> yeah, but it is more a curtosy thing than mandated, and definitely shouldn't require waiting for action to close <ulm> yes <WilliamH> K_F: ++ <dilfridge> K_F++ <mgorny> maybe we should have a three-part split on bugzilla [19:53] <leio> You are doing something wrong if leaving them open is a problem <mgorny> full stable <mgorny> cc on stable but don't wait <mgorny> don't cc on stable <dilfridge> stable, mixed, unstable <K_F> leio: in particular for security bugs it'd look rather odd... <mgorny> leio: i think the main point is that we don't want to leave vulnerable versions for months if arch team don't process requests in time [19:54] <leio> it is trivial to skip something that moves the non-security supported arches into a new bug <K_F> I'd prefer mgorny's description there rather than "mixed" <WilliamH> leio: I don't want to keep old versions of packages in the tree because some one-person arch can't keep up with stabilizations. <K_F> but I'm not sure we should go out of our way to accomodate it <mgorny> i would personally find it more convenient <mgorny> with some broad packages it's useful to be able to grab all 'stable' arches with one 'click' [19:55] *** alunduil (~alunduil@gentoo/developer/alunduil) has joined channel #gentoo-council *** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +v alunduil <leio> I just remove keywords for other arches and call it a day, for until the next sweep, then I ignore the arch and remove it; in particular for fast moving (for other arches) security stabilizations; but whatever <ulm> ok <ulm> anything else? <mgorny> do we approve the suggested bugzilla change? [19:56] <ulm> no votes in open floor <WilliamH> What change? <WilliamH> I'm not convinced that we need one. <WilliamH> ulm: ++ <mgorny> while talking about unstable arches [19:57] <mgorny> i should point out that slyfox is doing a nice job for sparc <slyfox> all credit should go to Dakon :) <ulm> are we done then? [19:58] * mgorny goes silent * ulm bangs the gavel * WilliamH thinks we are done <ulm> meeting closed