path: root/meeting-logs/20180114.txt

<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