Log for 20160710 meeting.

1 files changed, 383 insertions, 0 deletions

diff --git a/meeting-logs/20160710.txt b/meeting-logs/20160710.txt
new file mode 100644
index 0000000..d683ddc
--- /dev/null
+++ b/meeting-logs/20160710.txt
@@ -0,0 +1,383 @@
+<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]