path: root/meeting-logs/20161113.txt

<ulm> 19:00
<ulm> roll call
* K_F here
* blueness_ here
* dilfridge here
<prometheanfire> here
<ulm> jlec: rich0: WilliamH:                                            [20:01]
* jlec here
<blueness_> who’s chair?                                                [20:02]
<ulm> let's give them 5 minutes
<blueness_> k                                                           [20:03]
<K_F> blueness_: ulm
<rich0> Here, sort of
<ulm> does anyone have WilliamH's phone number?
<dilfridge> anyone got a # of WilliamH or jlec?
<ulm> jlec is here
<dilfridge> right
<jlec> dilfridge: I am here
<K_F> sending SMS to willian                                            [20:04]
<dilfridge> you were faster
<dilfridge> e-mail 27.07.2015                                           [20:05]
* WilliamH is here
<ulm> agenda:
      https://archives.gentoo.org/gentoo-project/message/d29f0c78f786d3b314d51825f9239a3e
<ulm> Stabilisation workflow
<ulm>
      https://archives.gentoo.org/gentoo-project/message/1ccf2b07b96f4b164e6f69fb5d2d6cc7
<ulm> K_F: can you report on the status?                                [20:06]
<K_F> I sent a written report on the list at
      https://archives.gentoo.org/gentoo-project/message/70b28773ada15c2f4d1bcf1428ffa6a9
<ulm> thanks                                                            [20:07]
<K_F> not sure if there are other questions related to it, but we're going
      forwards, somewhat slowly, but that is to be expected given that there
      is a lot of room for discussion of various aspects
<ulm> any action for the council at the moment?
<K_F> no, I believe it got a case because the submitter wasn't aware of the WG
<K_F> Shentino: you might want to elaborate on your agenda proposal?
<blueness_> K_F: can you summary the major time saving mechanism in your
            report?                                                     [20:08]
<K_F> blueness_: not sure if we can do it at this point, as we haven't come to
      any recommendations
*** blueknight (~blueknigh@gentoo/developer/blueknight) has joined channel
    #gentoo-council
<blueness_> K_F: k
<K_F> one of the things we'll likely end up with is an update to GLEP to allow
      self-stabilization                                                [20:09]
*** alicef (~none@gentoo/developer/alicef) has joined channel #gentoo-council
<K_F> and change bugzilla workflow to include stabilization as part of the
      steps, so not timestaving per se, but moving stabilization of some
      things away from arch teams if hardware is accessible
<K_F> but currently the discussion is about proper testing procedures etc, and
      even just documenting current policy                              [20:10]
<prometheanfire> what about allarches self stabilization?
<K_F> as a trivia, can anyone point to a policy that states self-stabilization
      is OK today
<WilliamH> K_F: nothing formal.
<blueness_> we could sepearate critical from non-critical packages and do an
            allarches stabilization on non-critical packages
<ulm> for amd64, some mail from kingtaco from several years ago
<K_F> blueness_: yes, separation of core and leaf, and even libraries and end
      apps is part of the discussion
<dilfridge> right now the main thing that keeps up allarches is, it seems not
            to fit into the arch team workflows                         [20:11]
<blueness_> K_F: i can see that working
<prometheanfire> K_F: ya, nothing formal, but I was told by an AT that I could
                 self stablize my stuff for x86/amd64
<K_F> libraries are easier to write test suites for, so recommendation might
      include recommendation for maintainers to ensure proper test suits
<WilliamH> I think we need to evaluate which arches we maintain stable
           profiles for also.
<dilfridge> so usually, even if the allarches flag is set, arches only
            stabilize their own keyword
<K_F> prometheanfire: it is explicitly prohibited by GLEP 40
<dilfridge> and afterwards f.ex. for perl packages I go through the list,
            check if one arch has stabilized, and stabilize the rest
<prometheanfire> dilfridge: ya, but for a maintainer workflow it may work
                 better
<K_F> "It is time for x86 to no longer be an exception to the standard
      keywording guidelines. Thus, an x86 arch team should be responsible for
      moving packages from ~x86 to x86. "                               [20:12]
<prometheanfire> K_F: just saying what I was told
<blueness_> K_F: it would be nice if we could get repoman to target an arch
<dilfridge> anyway,
<ulm> seems that work is in progress
<dilfridge> independently of the report we've also been talking informally
            about reviving existing procedures
<blueness_> so repoman —arche=ppc64 full would show the dep tree on that arch
<K_F> anyhow, nothing to dwell on as we're likely going to recommend it being
      possible in certain cases when properly tested, but yes, work in
      progress
<ulm> should we table this item until next month?
<K_F> ulm: not even sure if we have a final product by then
<dilfridge> kensington has done very nice work summing up stabilization
            procedures                                                  [20:13]
<prometheanfire> K_F: thanks for running this :D
<K_F> dilfridge: yes, that is part of this
<ulm> K_F: I think we won't get to vote about any motion today
<K_F> correct
<K_F> so I suggest we just leave it as that for now, but welcome input in
      #g-wg-stable                                                      [20:14]
<jmbsvicetto> K_F: iirc, amd64 still has a policy that states any dev with the
              hardware is allowed to mark a package stable for the arch
<K_F> jmbsvicetto: yes, but not backed by any council approved policy
<jmbsvicetto> K_F: no, but by the arch team itself
<ulm> K_F: backed by their arch team lead, at the time
<ulm> and I think it was confirmed at least once at a later point       [20:15]
<WilliamH> Yes, the arch team lead at the time set that up
<K_F> jmbsvicetto: anyhow, as said above, it is mostly curiosity as
      documenting current procedures to know what to change, GLEP 40 will
      likely be propsed replaced as part of htis
<jlec> I am really unsure what I should think about the whole stabilisation
       thing.
<jmbsvicetto> Those questions used to be part of the devmanual arch chapter(s)
<jlec> I am running ~arch since years with little problem
<dilfridge> in the past being an arch tester was seen as a good way to get
            into gentoo                                                 [20:16]
<jlec> And I hardly ever got a serious regression reported as part of the
       stabilisation process.
<dilfridge> you learn a lot about packages, build systems, ebuilds
<jlec> mostly minor-minor things
<jmbsvicetto> btw, I've been hearing and participating in discussions about
              stabilization policies for at least the last 6 years
<WilliamH> jlec: but there's always the chance you can get hard breakages
           running full ~arch.
<K_F> dilfridge: yes, but that only works if there are active arch teams to
      mentor
<jlec> WilliamH: sure, this is why we need stabilization                [20:17]
<dilfridge> right, so we need contact volunteers
<jlec> But I mean we shouldn't take it to serious
<jlec> It is more important that we see users installing them
<K_F> jlec: I tend to disagree, it is very serious if I'm unproductive due to
      failure on laptop or my server starts doing strange things without me
      noticing due to a breakage somewhere
<jlec> Which might be a good extra indicator. If we could get reporting about
       succesfull installs an user system, we would have a guideline of the
       maturity.                                                        [20:18]
<K_F> anyhow, I propose we move on, comments welcome in the WG channel
<ulm> anything else for this topic?
<ulm> 2. Stabilisation workflow                                         [20:19]
<blueness_> i’m good
<ulm> sorry
<jlec> me too
<ulm> 3. Status of contributors (nominate Foundation liaison)
<ulm>
      https://archives.gentoo.org/gentoo-project/message/4a88db38253494c6612a29117b2b19c8
<ulm> do we have any further information on this?
<ulm> from trustees?
* WilliamH isn't quite sure what that's about either                    [20:20]
<veremitz> o/
<NeddySeagoon> prometheanfire: your on
<ulm> prometheanfire: can you summarise what this is about?
<prometheanfire> ok
<prometheanfire> so, the idea to do a 'reorg' of gentoo has come up in
                 discussion a few times in various discussions, on the
                 foundation side and on the council side.               [20:21]
<prometheanfire> I'm willing to volunteer to help put together a plan (glep /
                 bylaw proposal) to help move that idea forward, but I'd like
                 to have someone from the council side to help.
                                                                        [20:22]
<K_F> I'd personally like to see a written up rationale for why such a change
      would be needed to begin with                                     [20:23]
<blueness_> prometheanfire: i never really understood what problem we’re
            trying to solve here
<prometheanfire> I'd rather not this be seen as coming down from on high, I'm
                 not even suggesting that this MUST be implimented once
                 proposed
<dilfridge> We're trying to solve a non-existing problem here.
<blueness_> K_F: +1
<prometheanfire> K_F: I don't think change is NEEDED, but I do think the
                 status quo could be better                             [20:24]
<K_F> wasting everyones time on something not expected to be implemented is
      even more fruitless, we have manpower issues to begin with, this will
      only make it worse
<dilfridge> At least as long as everyone sticks to their responsibilities,
            things are working fine.
<ulm> +1                                                                [20:25]
<K_F> but generally, I believe it is a good thing to write up GLEPs for
      special projects, I'm working on the security glep
<K_F> so a comrel glep is likely a good thing, without a major reorganization,
      to document things and stipulate requirements such as council approval
      of comrel lead
<K_F> but that will happen independently anyways
<ulm> does anyone want to come forward with a motion for this item?
<K_F> at this point I don't see anything for council though             [20:26]
<prometheanfire> this is primarily to get gentoo in line with the actual
                 reality that the foundation owns gentoo, to have comrel/pr
                 under council doesn't make much sense for legal (ianal)
                 reasons and having unfra under council does not as well (in
                 my opinion)
<ulm> I disagree with the statement that the foundation owns gentoo
<prometheanfire> ulm: legally it does                                   [20:27]
<prometheanfire> at least in the US
<ulm> it owns the trademark, and has control over funds
<blueness_> prometheanfire: i have no idea what’s going on here, how does
            reorgainizing staff vs dev bring things in line with “foundation
            owns gentoo” if it ev en does?!
<ulm> but little else
<dilfridge> prometheanfire: here's the thing. consider the election
            manifestos.                                                 [20:28]
<dilfridge> http://dev.gentoo.org/~dabbott/manifest.html
<prometheanfire> dilfridge: yes?
<dilfridge> https://dev.gentoo.org/~prometheanfire/trustee-manifesto.html
<dilfridge> ^ dabbott, prometheanfire, trustees
<K_F> I propose a motion that "insufficient information and documentation was
      provided for a proper discussion of the matter at hand. As such there is
      no council action at this point. If applicable be resubmitted at a later
      stage with proper written memorandum outlining what is being asked
      council and a description of the rationale for such a change."
<dilfridge> https://dev.gentoo.org/~rich0/council-manifesto-2016.txt
<dilfridge> https://dev.gentoo.org/~dilfridge/Manifest-2016.txt
<K_F> "if applicalbe it can be"*
<dilfridge> ^ rich0, dilfridge, council
<dilfridge> so now, my question to you is, who has been given the task to
            oversee the community?                                      [20:29]
<prometheanfire> K_F: that's all I was looking for help from
<prometheanfire> dilfridge: comrel/pr
<ulm> K_F: fine with me
<dilfridge> that's not the question, the question is trustees/council
<prometheanfire> I was hoping for rich0's help
<K_F> "asked from council"                                              [20:30]
<K_F> with fixes: " "insufficient information and documentation was provided
      for a proper discussion of the matter at hand. As such there is no
      council action at this point. If applicable it can be resubmitted at a
      later stage with proper written memorandum outlining what is being asked
      from council and a description of the rationale for such a change."
<ulm> K_F: hold on, discussion still going on
<rich0> Sorry, a bit hard to chat right now, but I'm happy to still generally
        work with you on ideas                                          [20:31]
<prometheanfire> K_F: I didn't expect any decision about this at this meeting
<prometheanfire> rich0: thanks, that'd be appreciated
<blueness_> i’d like to know what the issue is
<prometheanfire> blueness_: I'd say the crux of it is that Gentoo as a two
                 headed beast does not reflect the reality of actually running
                 it.  I wish to fix that.                               [20:33]
<prometheanfire> I'm aware this has been brought up in the past, a few times
                 even
<dilfridge> To be honest I get less and less happy with Gentoo's two-headed
            structure, since it allows abuse by third parties (playing one
            part against the other).
<prometheanfire> dilfridge: indeed...
<jmbsvicetto> prometheanfire: I feel the current discussion on #-trustees and
              the project ml is going in the wrong direction. Trustees and
              Council need and should work together, but I won't accept a
              proposal to make council an entity under the Trustees rule
                                                                        [20:34]
<K_F> dilfridge: it is only abused if we let them though
<K_F> personaly I belive the lines are already clear on responsibility, and as
      such it doesn't constitute a conflict
<prometheanfire> jmbsvicetto: ya, I'm not sure what to do about that myself,
                 I'm totally open to suggestions though
<ulm> my feeling is that a more concrete outline will be needed before we can
      move on with this
<NeddySeagoon> jmbsvicetto: both entitien need to change so we can become one.
                                                                        [20:35]
<prometheanfire> ulm: of course, like I said, didn't expect a vote at this
                 meeting
<ulm> unless any council member would want to volunteer at this time
<dilfridge> well, there's always the way of Debian, Arch, and LibreOffice
<NeddySeagoon> SFI ?
<dilfridge> yes
<ulm> yep
<K_F> dilfridge: yes, umbrella org might be something worth considering
<prometheanfire> NeddySeagoon: ya, one suggestion recently was one joint
                 council/foundation with more officers handling specifics, I
                 liked that                                             [20:36]
<NeddySeagoon> Thats been discussed in the past too
<jmbsvicetto> prometheanfire / NeddySeagoon: another sensitive issue is that
              some developer have opted not to be members of the Foundation
              and I don't think they'll be happy to be put under the
              Foundation when they chose not to join it
<prometheanfire> ya, it's been rejected because of the loss of autonomy
<prometheanfire> jmbsvicetto: that's one of the major things, I'm aware
<Soap__> prometheanfire: are there any problems with comrel being under the
         council?
<NeddySeagoon> anyway, rich0 offered to help out.  We won't get further right
               now                                                      [20:37]
<ulm> K_F: shall we vote on your motion still?
<prometheanfire> Soap__: personally, I think it should be under foundation for
                 legal reasons, but like I siad before, ianal
<prometheanfire> ya, I'm happy if rich0 can help as a sounding board
<K_F> ulm: if we are to vote on anything I'd prefer that over any council
      sanctioning of this process                                       [20:38]
<dilfridge> we can probably do that without any vote
<K_F> however individuals are of course free to cooperate outside of it
<ulm> sure
<NeddySeagoon> Why is a motion required?
<ulm> it is not
<K_F> main reason is I haven't seen clear goals and background outlined,
      starting any process requires a level of preparation to be handled in a
      professional manner                                               [20:39]
* WilliamH doesn't see the need for a motion either
<prometheanfire> I'd suggest tabling this til next meeting
<WilliamH> If rich0  is going to work with prometheanfire, that's all that's
           needed at this point
<blueness_> yes table i\t
<dilfridge> +1
<K_F> wfm
<ulm> everyone o.k. with tabling it?                                    [20:40]
<WilliamH> wfm
<jlec> me too
<ulm> ok, let's move on then
<ulm> 4. Copyright matters
<ulm>
      https://archives.gentoo.org/gentoo-project/message/60481da5b44b778ca5c4405da28f61c7
<ulm> mgorny: rich0: ^^
<prometheanfire> wasn't copyright mentioned earlier as being a foundation
                 issue?                                                 [20:41]
<WilliamH> Yes, I think it is a foundation issue.
<K_F> agreed
<WilliamH> Gentoo technically has copyright assignment.
<dilfridge> works for me
<ulm> agreed from me too                                                [20:42]
<ulm> so not an issue for the council
<WilliamH> Agreed.                                                      [20:43]
<ulm> anything else, or can we move on?
<jlec> yes
<mgorny> is the foundation capable of solving this?
<prometheanfire> was talking about running the various social media included
                 in this issue?
<ulm> mgorny: that's not up to the council to decide
<WilliamH> prometheanfire: that was a separate thread but not brought to the
           council.
<prometheanfire> ah, ok
<ulm> 5. Open bugs with council involvement                             [20:44]
<ulm>
      https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3344668&query_format=advanced
<prometheanfire> mgorny: I feel we could task council with doing something,
                 but I don't know the issue well enough to say
<dilfridge> mgorny: well rich0 is also officially a foundation officer, so
            this is just changing the discussion venue but not that much
            what's happening
<K_F> prometheanfire: various social media should likely go through PR to
      begin with before council
<dilfridge> anyway not our task
<prometheanfire> K_F: agreed
<ulm> bug 571490
<willikins> ulm: https://bugs.gentoo.org/571490 "Missing summary for 20151025
            council meeting"; Documentation, Project-specific documentation;
            CONF; mgorny:council                                        [20:45]
<ulm> bug 596678
<willikins> ulm: https://bugs.gentoo.org/596678 "Missing log and summary for
            council meeting 2016-09-11"; Documentation, Project-specific
            documentation; CONF; k_f:jlec
<ulm> missing summaries
<mgorny> well, considering that council somehow sets up the direction for the
         whole community, i think it's important to decide on copyright here
<dilfridge> working on it, about half done (the first of the two)
<mgorny> rather than some foundation who most developers treat as remote
         entity that has to exist but otherwise is completely alien
<ulm> jlec: any progress with the September summary
<WilliamH> mgorny: that's a legal issue; the council has no jurisdiction over
           it.
<ulm> mgorny: we have moved on
<jlec> Yes, I know. I write the logs ASAP
<ulm> then the 4 games bugs
<dilfridge> eww                                                         [20:46]
<ulm> can we take council out of CC there, and leave it to QA and Comrel?
<K_F> +1
<ulm> 3 for qa, 1 for comrel, that is
<blueness_> was i supposed to do 1025?
<blueness_> or 612?
<dilfridge> I dont think these are so problematic, since work to update the
            ebuilds is ongoing
<WilliamH> ulm, dilfridge: I believe wizardedit was doing a lot of work on the
           games issues.
<dilfridge> yes
<dilfridge> blueness_: 1025 is mine                                     [20:47]
<blueness_> k
<ulm> WilliamH: the question is if council has to stay in CC
<K_F> yes, there is currently nothing more for council to do on the issue, so
      removal from CC is correct
<dilfridge> we can take it out
<ulm> I believe QA can handle it, and CC council again if necessary
<ulm> ok, I'll remove council from CC of all four then, and add QA if
      necessary
<ulm> bug 579460                                                        [20:48]
<willikins> ulm: https://bugs.gentoo.org/579460 "please make repoman ignore a
            missing "# $Id$" header line"; Portage Development, Repoman; IN_P;
            dilfridge:dev-portage
<ulm> is that in stable repoman?
<K_F> that is already implmeented in vcs
<K_F> not in stable yet (2.3.0 has it)
<K_F> but nothing more from council required on that either
<ulm> so un-CC there too?                                               [20:49]
<K_F> that'd be my suggestion
<ulm> or do we want to keep track of it
<dilfridge> so now the question of removing the Id header follows...
<ulm> yeah, maybe we should stay in CC, in order to remove Id later
<WilliamH> dilfridge: If it is in stable repoman, there's nothing stopping
           that from happening.
<ulm> oh, I see we already have a decision on removal of CVS headers    [20:50]
<ulm> so indeed no council action required
<K_F> yes, we're done
<ulm> so, remove from CC there too                                      [20:51]
<ulm> bug 565566
<willikins> ulm: https://bugs.gentoo.org/565566 "New ChangeLogs are in
            chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF;
            patrick:infra-bugs
<WilliamH> again, that's waiting for infra?
<ulm> anyone from infra here who can report on status?
<jlec> There is progress isn't it?
<ulm> mgorny?
<mgorny> ulm: dunno, i'm just sweeping floors in infra                  [20:52]
<K_F> we should follow up on email with infra and ask for a status update
<prometheanfire> ya, I do about the same
<prometheanfire> in infra
<mgorny> but
<ulm> K_F: action item for you then :)
<mgorny> i think someon (robbat2?) is working on splitting/removing changelogs
<dilfridge> hehe... seems like things are pretty clean there
<mgorny> so maybe that'd be handled as part of it
<K_F> ulm: yes, I can write up a short email on it
<prometheanfire> ya, it'd be him
<ulm> K_F: thanks
<ulm> that's all bugs, I believe                                        [20:53]
<ulm> Open floor
<Soap__> ok so
<Soap__> there were questions whether some more archs could be added to the
         list of "can drop stable keywords"                             [20:54]
<mgorny> Soap__: ago already relieved the situation
<K_F> Soap__: if anything is to be done there it should be a regular agenda
      item in any case
<mgorny> also, isn't stablewg supposed to handle that?
<K_F> but yes, it also fits nicely into the WG
<Soap__> mgorny: do you think the general slowness of ppc/sparc ATs will go
         away?
<ulm> Soap__: that would be something for discussion in the -dev ML, and
      possibly agenda item for a later meeting                          [20:55]
<K_F> Soap__: #gentoo-wg-stable, it fits nicely into our dsicussions there
<dilfridge> We probably need to drop keywords more.
<Soap__> ok, next time round
<mgorny> so
<mgorny> i heard gentoo is dying
<dilfridge> Also witout feedback from arches if it doesnt arrive in time.
<dilfridge> mgorny: it certainly isn't as shining bright as it was in wltjr's
            times anymore.                                              [20:56]
<blueknight> Some arches have support for ancient CPU's, which probably slows
             down the process
<WilliamH> K_F: I think wrt wg-stable we should really look at which arches
           have stable profiles.
<mgorny> maybe we should found a WG to restore gentoo to its former glory
<Soap__> we need to get wltjr back on! Make Gentoo/Java great again!
<K_F> WilliamH: agreed (it is already in notes)
<blueness_> Make Gentoo Great Again!                                    [20:57]
<WilliamH> blueness_: heh
<ulm> ok, I think it's time for me to bang the gavel
<K_F> since open floor, FOSDEM 2017 stand acceptance is scheduled to be
      announced tomorrow
<dilfridge> Well, considering Perl, I guarantee you there’s no problem. I
            guarantee you.
<ulm> K_F: great
<K_F> I hope we get a stand and that people are ready to fill up the stand
      slots once we get there.
<prometheanfire> K_F: yarp                                              [20:58]
<prometheanfire> blueness_: you are going to fosdem? right?
<K_F> if we want to recruit new devs, we need to be visible
* WilliamH might go to scale
<K_F> any talk about changing of recruiters etc is moot if there isn't anyone
      to recruit, so for me the line starts at PR..
<blueness_> prometheanfire: nope
<prometheanfire> blueness_: :(
<ulm> any other item for open floor?                                    [20:59]
<jlec> blueness_: we just got a tag line at work "Make IT inspire R&D" :D
* ulm bangs the gavel
<jlec> Make Gentoo inspire IT
<ulm> meeting closed
<jlec> thanks ulm
<K_F> ulm: thanks for chairing
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: 2016-12-11 19:00 UTC |
    http://www.timeanddate.com/worldclock/fixedtime.html?iso=20161211T19 |
    https://wiki.gentoo.org/wiki/Project:Council"
<dilfridge> ulm: thank you!!!
<dilfridge> !!!1!                                                       [21:00]
<ulm> rich0: you will be next chair
<blueness_> i got to go guys tata
<ulm> heh, we kept it to one hour :)
<K_F> for once :)