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