diff options
Diffstat (limited to 'meeting-logs')
2 files changed, 397 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:
+* 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]
+<dilfridge> eh right. soon.
+<ulm> bug 565566
+<willikins> ulm: "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: "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: "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: "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:
+<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
+*** 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 |
+ |
+<rich0> ulm: ++
+<ulm> thanks everybody [21:00]
diff --git a/meeting-logs/20160710.txt.asc b/meeting-logs/20160710.txt.asc
new file mode 100644
index 0000000..411a835
--- /dev/null
+++ b/meeting-logs/20160710.txt.asc
@@ -0,0 +1,14 @@
+Version: GnuPG v2