<ulm> so, should we start?
<dilfridge> no worry I only just arrived
<ulm> who wants to chair?
<dilfridge> whoever asks that question first :D
<ulm> k
<WilliamH> heh
<ulm> agenda:
      https://archives.gentoo.org/gentoo-dev-announce/message/6b32250b8bf53cd3016331aebd75c956
* jlec here
<ulm> roll call                                                         [20:07]
* dilfridge here
* WilliamH here
* jlec still here
* rich0 here
* K_F here
<ulm> blueness was here a few minutes ago
<blueness> here                                                         [20:08]
<dilfridge> :)
<ulm> 1. Vote for holding meetings every 2nd Sunday of the month at 1900 UTC
<dilfridge> wfm
* jlec yes
* WilliamH yes
* dilfridge yes
<ulm> everyone o.k. with Sunday, or should we shift to another day?
* K_F yes
<rich0> The current schedule has worked well for me                     [20:09]
* ulm yes
<blueness> yep
<K_F> I prefer keeping sundays at least                                 [20:10]
<ulm> unanimous, if I count dilfridge and rich0 as yes
* dilfridge yes
* rich0 yes
* dilfridge yes yes yes
<rich0> :)
<ulm> 2. Vote for continuing last council's workflow considering sending call
      for agenda items (2 weeks in advance), sending the agenda (1 week in
      advance) and have the meeting focussed, e.g., have major discussions on
      -project ML prior to the meeting                                  [20:11]
* K_F yes
* WilliamH yes
* jlec yes
<ulm> anyone wants to discuss this?
* dilfridge yes
<ulm> seems not :)
<WilliamH> ulm: what would there be to discuss?
* ulm yes
<jlec> I haven't seen any issues with this workflow
<jlec> ever
<blueness> ulm: to be clear, this is the only time we’re meeting at 1800 UTC?
* blueness yes
<blueness> except for the fact that i always need to be reminded, i’m okay
           with this :)                                                 [20:12]
<ulm> blueness: yep, will be 19:00 UTC
<blueness> i’m like that in real life too, i always get lost in time
<rich0> All works for me
<ulm> rich0: is that a yes?
* rich0 yes yes yes                                                     [20:13]
<ulm> unanimous then
<ulm> 3. Appoint chairmen for this term's meetings
<ulm> I can take November and/or December
* dilfridge volunteers for nov,dec,jan
<K_F> I don't have any particular requirements
<blueness> i’d like to have the last two again, because i don’t teach during
           the summer
<dilfridge> ok then I do jan/feb/mar
<blueness> so i’d like may and jun                                      [20:14]
* WilliamH will take a couple, not nov or dec though
<jlec> I take what is left over. No preference for any date
<rich0> I should be able to take any two
<ulm> hmm
<ulm> blueness may/june
<ulm> dilfridge jan/feb/mar
<blueness> ulm: yes please
<ulm> ulm nov/dec
<K_F> anyone actually need to take 3?                                   [20:15]
<ulm> K_F: no
<rich0> NOpe - that's why I didn't do any last year :)
<K_F> iirc last year we didnt have enough to go around :)
<ulm> WilliamH: mar/apr?
<rich0> Too many eager people taking 3...  :)
<WilliamH> ulm: ok, that should work.
* K_F signs rich0 up to write a few summaries :p
<rich0> But, don't let me stop you :)
<ulm> dilfridge: jan/feb then :p
<dilfridge> works for me
<ulm> so what's left? aug/sep/oct                                       [20:16]
<K_F> I can take aug/sept
<jlec> Let me take Sep/Oct then
<WilliamH> Are we going to do a meeting w/ agenda items this month or just
           start that in Aug?
<K_F> ok I can take aug
<K_F> WilliamH: my understanding is the latter                          [20:17]
<ulm> K_F aug, jlec sep/oct
<jlec> copy that
<WilliamH> K_F: ok
<ulm> all settled, except rich0 wants to take one
<rich0> What's untaken?
<ulm> nothing, but I have 3 if I count this meeting too                 [20:18]
<rich0> If all are taken, I can just be backup/etc.
<ulm> rich0: nov/dec?
<ulm> one of them, I mean
<rich0> Sure, either is fine                                            [20:19]
<ulm> ulm nov, rich0 dec then
<ulm> 4. Open bugs with council involvement                             [20:20]
<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=3227130&query_format=advanced
<dilfridge> eh right. soon.
<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> Did folks see my msg in here about the May summary?          [20:21]
<ulm> WilliamH: I did
<WilliamH> ChangeLogs are dead, infra just hasn't removed them yet.     [20:22]
<ulm> currently no action for the council in #565566 I think
<WilliamH> We made that decision a few meetings back
<WilliamH> So that bug is obsolete
<ulm> then we have #566498 #574080 #574082                              [20:23]
<blueness> WilliamH: i honestly have no recollection of that, but imo
           ChangeLogs should go bye bye
<ulm> all about games.eclass
<dilfridge> well someone is working on it, which is progress
<ulm> blueness: yeah, we left that to infra
<blueness> ulm: yeah bug #574952 is particularly disturbing
<willikins> blueness: https://bugs.gentoo.org/574952 "Extremely uncooperative
            behavior from games team"; Community Relations, Developer
            Relations; CONF; mgorny:comrel
<WilliamH> Yes, the games.eclass work is being done.                    [20:24]
<ulm> blueness: right, four games.eclass bugs by now
<ulm> all with council in CC
<ulm> any suggestion how to proceed?
<rich0> Is anything actually blocking progress?                         [20:25]
<jlec> I htink we need to encourage QA to do their job here.
<dilfridge> leave it for the moment, I'll try to trigger some internal
            discussion in comrel first
<ulm> dilfridge: noted
<rich0> dilfridge++
<K_F> good enough for me
<WilliamH> ulm: I think the tech work is being done, last time I checked
           wizardedit is working with others on games.eclass deprecation
<jlec> We decided the direction but now it is up to QA to have a look onto
       this and have to executed
<rich0> IT seems more like a people issue at this point, not a policy one.
<WilliamH> dilfridge: I can attest to the comrel issue as well.         [20:26]
<ulm> ok, so waiting for qa and comrel
<blueness> if work is getting done, let’s wait and see
<jlec> sounds good
<ulm> then, bug 571490
<willikins> ulm: https://bugs.gentoo.org/571490 "Missing summary for 20151025
            council meeting"; Documentation, Project-specific documentation;
            CONF; mgorny:council
<jlec> who?
<K_F> dilfridge: ^^                                                     [20:27]
<ulm> that's the people volunteering for 3 chairs :p
<K_F> ulm: :)
<blueness> i just remembered i have to do the summary for the last meeting
<jlec> exactly my thought
<ulm> anyway, action item for dilfridge                                 [20:28]
<dilfridge> yep
<ulm> last, bug 579460
<willikins> ulm: https://bugs.gentoo.org/579460 "please make repoman ignore a
            missing "# $Id$" header line"; Portage Development, Repoman; IN_P;
            dilfridge:dev-portage
<WilliamH> Is that in 2.3?                                              [20:29]
<K_F> nothing for us to do there and it is implemented already
<ulm> WilliamH: no idea
<K_F> dol-sen mentioned it being in 2.3.0_rc1
<ulm> it's blocking the portage-2.2.30 bug
<WilliamH> The person to talk to would be dol-sen probably              [20:30]
<K_F> but yeah, he already commented it is included.. nothing for us to do
*** blueness (~blueness@gentoo/developer/blueness) has quit: Quit: blueness
<ulm> ok, I'll check if that bug can be closed
<ulm> 5. Open floor                                                     [20:31]
<WilliamH> hang on a sec, I have one wrt m-n and old packages.
<K_F> ulm: can be closed once it is in stable
<WilliamH> maybe discussion
<K_F> ulm: so if anything should be InVCS keyword etc
<WilliamH> no vote
<WilliamH> hang on
<WilliamH> wrt the discussion  about old packages.                      [20:32]
<WilliamH> I got a couple of suggestions.
<WilliamH> 1. when a maintainer puts a package up for grabs, they assign it to
           m-n and p.mask it to encourage someone to take it.           [20:33]
<WilliamH> after 30 days, they remove it.
<WilliamH> or
<WilliamH> (i'm pulling this from an email)
*** blueness (~blueness@gentoo/developer/blueness) has joined channel
    #gentoo-council                                                     [20:34]
*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +o
    blueness
<WilliamH> 2. only remove broken packages... leave m-n as is.
<rich0> Personally, I say leave them in the tree until they actually cause a
        problem, then aggressively treeclean.
<jlec> rich0: ++
<awilfox> blueness: https://bpaste.net/show/e97e7ff9b121
<WilliamH> But if a bug is filed against a m-n package, that would be when we
           would mask it to get someone to step up and fix the bug and take
           the package.                                                 [20:35]
<rich0> Well, a serious bug.
<rich0> If some package is missing a desktop entry or something, I doubt the
        submitter would have wanted it removed as the solution.
<K_F> I tend to prefer packages being actively maintained  and some
      responsible for its state, at least for stable tree
<ulm> I wouldn't mask it unless there is a good reason
<ulm> missing ebuild maintainer alone isn't sufficient for masking
<WilliamH> ulm: missing maintainer + a bug is                           [20:36]
<WilliamH> ulm: open bugs against m-n packages aren't good.
<WilliamH> ulm: especially packages with stable versions                [20:37]
<rich0> Many bugs are trivial.  I don't see the need to clean just because a
        package isn't perfect.
<jlec> I didn't completely followed the bitcoin package thread, but for
       packages which can cause real world problems like those, or scientific
       packages potentionally creating false results or packages closely
       related to security, I think we should also allow/encourage tree
       cleaning instead simple dorpping to m-n
<rich0> But, if it is serious, of course.  Just get rid of it.
<ulm> rich0: +1
<rich0> jlec: sure, if we're talking about things with a serious impact.
                                                                        [20:38]
<rich0> I think some discretion is needed.
<blueness> sorry guys, connection dropped :(
<blueness> awilfox: ty
<blueness> jlec: i was going to p.mask a bunch of *coin pkgs
* WilliamH also likes the graveyard overlay. 
<rich0> I just don't like the rush to just close bugs and get rid of things
<WilliamH> I'm surprised we haven't been using it.
<blueness> i was able to give away a few, the rest i’m going to drop to m-n
           except for namecoin which has issues, its getting p.masked and
           dropped to m-n
<rich0> WilliamH: why would anybody want to put that overlay in their repos,
        given that overlays are all-or-nothing?                         [20:39]
<rich0> If it isn't actually cared for?
<rich0> If it weren't horribly broken, it would be in the tree.
<jlec> similar for testing vs stable, we should strive to get everything
       stable, but there is no harm in keeping packages testing. Bu twe should
       give a false impression of a package being maintained if actually it
       isn't
<rich0> blueness: something like that seems reasonable
<rich0> jlec: stable =/= maintained, IMO
<rich0> stable just means it has been tested, and works                 [20:40]
<jlec> Some packages doesn't simply get shiny features or security pathcing,
       but sometimes it turns out that calculations are wrong and updates
       tackle that
<K_F> stable has security support, testing does not
<jlec> rich0: this also can happen to stable packages
<jlec> But if they are mn, no one will update and care                  [20:41]
<rich0> jlec: sure, but those calculations still work as well as the day we
        considered them stable :)
<rich0> I think that people using a package in some kind of serious
        application probably do their own QA, and closely monitor it.
<jlec> sure, but if latest research says thet are wrong we shouldn't tell the
       user today that old version is stable and should be used         [20:42]
<rich0> But, known serious bugs are of course a fair reason to drop something
<rich0> I'd just prefer to assume innocent until proven guilty.
<jlec> I just want to mae sure, we are banning pm if the stepping down
       maintainer sees a requirement for active maintainership for a package
                                                                        [20:43]
<WilliamH> The problem with packages sitting in m-n is that no one cares about
           them.
<jlec> *are not banning
<ulm> WilliamH: which is fine as long as the package is working
<WilliamH> ulm: so, is it also ok to drop a new package in the tree straight
           to m-n?                                                      [20:44]
<ulm> WilliamH: no
<ulm> but the maintainer can step down at any later time
<blueness> WilliamH: under what circumstances would that happen?        [20:45]
<jlec> blueness: people dodo that
<WilliamH> blueness: I asked, because I thought I heard that people do that.
<jlec> mike, mr_bones and others
<blueness> jlec: WilliamH that’s just crazy, why?!
* jlec not exactly sure about mr_bones                                  [20:46]
<dilfridge> seriously
<ulm> why would someone commit a package when he's not interested in
      maintaining it?
<dilfridge> if someone commits to the tree straight maintainer-needed, I
            recommend a quick patrick solution
<dilfridge> (immediate revert)
<dilfridge> I doubt anyone (be it qa, comrel, council) would see any problems
            with that
<ulm> maybe we should make a statement on this very point
<jlec> I think mgorny pointed out sch a case either to comrel or g-dev lately
                                                                        [20:47]
<dilfridge> yes
<WilliamH> But, ulm just said a maintainer can step down whenever, so if I
           commit to the tree, then drop to mn aseparate commit that's ok.
<blueness> it is very strange indeed, are they suggesting that someone else
           pick it up?
<dilfridge> but that was already some time ago
<rich0> IF nothing else it should make sense to care for it for a short time.
        In a more communal world maybe everything woudl be m-n, but we don't
        really work that way.
<ulm> dilfridge: wording for motion?
<mgorny> just to be clear, i don't remember anymore what package was that and
         what happened with it                                          [20:48]
<blueness> rich0: no, its just like real socialism, no one takes
           responsibility ;)
<K_F> I really siggest no voting during open floor
<WilliamH> Yeah this should not be a voting issue
<K_F> can have it on agenda for next meeting
<ulm> WilliamH: IMHO "any time" means after a reasonable period
<ulm> not after 5 minutes :)
<dilfridge> The council affirms existing policy that packages added to the
            gentoo repository must have a declared maintainer. Commits adding
            packages without such should be immediately reverted.
<WilliamH> dilfridge: no voting on an open floor issue, let's do that next
           meeting                                                      [20:49]
<ulm> yeah, maybe we should postpone it
<ulm> it's not an urgent issue
<K_F> besides, gate opens here soon, so will be off in few mins anyways
<ulm> https://wiki.gentoo.org/wiki/Project:Council#Meeting_chairs
*** prometheanfire (~promethea@gentoo/developer/prometheanfire) has joined
    channel #gentoo-council
<ulm> ^^ please check if I've got things right there
<rich0> Agree, might not hurt to include general point in the summary as
        non-binding for now, except insofar as existing policy applies.
<jlec> ulm: lgtm                                                        [20:50]
<rich0> wfm
<blueness> ulm: looks good
<ulm> anything else for open floor?
* awilfox politely raises hand; are users and proxy maintainers allowed to
  suggest topic for open floor?                                         [20:51]
<dilfridge> go
<ulm> sure
<K_F> awilfox: yes
<WilliamH> sure, open floor is open floor ;-)
<blueness>                                                              [20:52]
<awilfox> I am very interested in becoming a gentoo developer myself, too,
          actually, I just had a small suggestion: I am quite happy that
          gentoo finally has a working comrel project that seems to be able to
          give justice where it is needed, but I have been a little
          disappointed with the lack of response to my inquiries in places
          where I have personally been involved.  is there any way to make it
          so that comrel
<awilfox> is a little less.. black-box-y is the word I want?  so that devs and
          users can know what is happening...
<awilfox> I understand that issues need to be kept private so that there is no
          spill of drama and such, but I am personally involved in a case
          where someone was harrassing me both on the bugzilla and followed me
          to my social media... and I don't even know what happened in that
          case                                                          [20:53]
<blueness> awilfox: i think comrel is best for more senior devs just because
<ulm> dilfridge: that's a question for you, I think
<awilfox> was this person talked to, was it handled, did nothing happen, etc..
          makes me a bit hesitant on doing quizzes and becoming a dev
                                                                        [20:54]
<blueness> awilfox: oh strike my comment i misunderstood                [20:55]
<dilfridge> ok I vaguely remember that incident. I *think* nothing happened,
            since at the time everyone was busy otherwise. (e-mail 5 Feb?)
<K_F> likely best to email comrel alias for that
<awilfox> dilfridge: yes, with a follow up near 1 Mar
<ulm> awilfox: can you try to work this out with comrel?                [20:56]
<dilfridge> we can talk about this
<awilfox> ulm, sure, I can fire another email out.
<WilliamH> dilfridge, awilfox, go ahead. :-)                            [20:57]
<awilfox> but this was in general, I know someone else who had similar
          experience, basically my question was is there any support in
          council on making comrel a bit more transparent so people are not
          kept out of the loop
<jlec> awilfox: I would suggest, please try to contect comrel and see if you
       can get some more clarity. If that doesn't work out, Council can
       potentionally check if ComRel is really reacting in a timely manner and
       provides adequate information to the parties involved
<jlec> Would that work for you?
<awilfox> jlec, certainly!
<dilfridge> comrel was very inactive for a long time. mostly because some team
            members were completely absent and some others were busy with real
            life.
<dilfridge> this is hopefully getting better now.
<awilfox> glad to hear this :)                                          [20:58]
<awilfox> thank you for your time.
<rich0> Certainly I support as much transparency as possible, considering, and
        I think most of us do.
<ulm> anything else?
<ulm> seems not                                                         [20:59]
<ulm> meeting is closed then
<jlec> ulm: thanks for chairing
<K_F> thanks for chairing
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
    "Next meeting: 2016-08-14 19:00 UTC |
    http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160814T19 |
    https://wiki.gentoo.org/wiki/Project:Council"
<rich0> ulm: ++
<ulm> thanks everybody                                                  [21:00]