diff options
25 files changed, 2981 insertions, 0 deletions
diff --git a/meeting-logs/20160508-summary.txt b/meeting-logs/20160508-summary.txt new file mode 100644 index 0000000..5e17faf --- /dev/null +++ b/meeting-logs/20160508-summary.txt @@ -0,0 +1,43 @@ +Summary of Gentoo council meeting 8 May 2016 + +Agenda +====== +1. Roll call +2. Open Bugs with Council Involvement +3. Open Floor + +Roll call +========= +Present: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + +Open bugs with council involvement +================================== + +These bugs have to do with games issues: + + - Bug 566498 - Use of games group needs to be removed + No action from council + + - Bug 574080 - path customization needs to be removed + No action from council + + - Bug 574952 - comrel complaint w/ council in cc wrt the games team. + no visible progress + + - Bug 579460 - make repoman ignore missing # $Id$ line: + CC only for tracking purposes. + +The following bugs are about missing meeting summaries, so the cc's are +for tracking. + + - Bug 569914 + - Bug 571490 + +Open floor +========== + +Williamh brought up the gtk use flag situation; it was referred to the qa team. + +Dilfridge brought up the idea of writing council meeting summaries in +latex and publishing them in pdf. There wasn't any interest in doing so. + diff --git a/meeting-logs/20160508-summary.txt.asc b/meeting-logs/20160508-summary.txt.asc new file mode 100644 index 0000000..43759de --- /dev/null +++ b/meeting-logs/20160508-summary.txt.asc @@ -0,0 +1,17 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQIcBAABCAAGBQJXfl3PAAoJEJtAqO3K+uczXBcP/2sq63pr36HNAU7tXWKEOtK9 +wYMY4R+EvaguwDZbNqcytZ/FCoVtD8stkAlZ7rGAy3a/qVk88YrQSp0LqEJzvgHu +HHq9k8QCIjE4mW4PsD3N8cmAEzr2oMO5uTXEqD/0kjZKEhoB5dsLPvhAhc7hhu0W +xZbjcrjDqJUdkn1AeJKydXo3SxrzgBARU/D3pYGL4o49nd4jNq29F9wJECRwy94E +nTZR8lSGCyWOofWrgB+8/aAPCDCQxRHGrwo0BNGK3sxGAmIKAz/+DDLRAmNvThfK +WenrHOQPJ682Yeo/5uKP6jxH0RnEwXaSAmGpEfqy9Iu//FrhIaNr9PkeR3sysVNt +BO9fLYRQIOwIMBvwpsFrYhkNwq+Ynbnrj5Zc+GiEC1Z+5gnRgs4KuefQWWKPuDLj +3kzO8ZJkNo6chzE37volnqBS3OpzI4BvxPZ8yIc9G7LH6JRrcCLoFzP20uHXOh9G +wl92qZnSriHXMPAlYNhMQQ3VM/2votQgugM/K2EMPwD8bkRH2L6Jr2YJRe8OsDFX +LvXizpLWFQrCEGkb80/KrLdpueQgLjpfMkCot9YP9KTtnlitalHhuINj9yaB3WQV ++5c5C2GIXDxE8J5bboex1qcfcpRL24pQbjxQv0vMLHq2bHrs9/vI55hngSJwz13f +KlcI7RY0vRNrEcluVOxp +=0XGZ +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20160710-summary.txt b/meeting-logs/20160710-summary.txt new file mode 100644 index 0000000..9906a73 --- /dev/null +++ b/meeting-logs/20160710-summary.txt @@ -0,0 +1,60 @@ +Summary of Gentoo council meeting 10 July 2016 + +Agenda +====== +- Vote for holding meetings every 2nd Sunday of the month at 1900 UTC +- 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 +- Appoint chairmen for this term's meetings +- Open bugs with council involvement +- Open floor + + +Roll call +========= +Present: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + +Meeting schedule +================ +- Vote: Hold meetings every 2nd Sunday of the month at 19:00 UTC. + Accepted unanimously. + +Workflow +======== +- Vote: Continue 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. + Accepted unanimously. + +Meeting chairs +============== +Meeting chairs for the upcoming council term have been assigned. + +Open bugs with council involvement +================================== +- Bug 565566 "New ChangeLogs are in chronological order": + Currently no action from council required. + +- Bug 566498 "games.eclass: use of games group needs to be removed wrt + 20151011 Council meeting", + bug 574080 "games.eclass: Path customization needs to be removed wrt + 20151213 Council meeting", + bug 574082 "[Tracker] games.eclass deprecation", + bug 574952 "Games team intentionally ignoring messages and bugs in + order to stall QA and Council": + Waiting for QA and ComRel. + +- Bug 571490 "Missing summary for 20151025 council meeting": + Action item for dilfridge. + +- Bug 579460 "please make repoman ignore a missing "# $Id$" header line": + Implemented in repoman, no action from council required. + +Open floor +========== +Items discussed: +- Policy for removal of maintainer-needed packages +- Transparency of Comrel responses diff --git a/meeting-logs/20160710-summary.txt.asc b/meeting-logs/20160710-summary.txt.asc new file mode 100644 index 0000000..3de8e6f --- /dev/null +++ b/meeting-logs/20160710-summary.txt.asc @@ -0,0 +1,13 @@ +-----BEGIN PGP SIGNATURE----- + +iQGcBAABCAAGBQJYKJXKAAoJEJQzkH1pP7W4GTAMAKbU1nbDVWoKjKQTO/stp3Vl +TCCrDrdihSTfV9vCMiFQL7TA31oPQY4FT+sUdYJrp3B9JEl97Ybh3yYEZnuuGHWT +8NFtFDupr2cLx2kuw2X2DLFwRGA5AWKqYu86wFs3pZsZDNHKwx0nUYBhF7Ow3cwm +qmeNvu+1HsyxAvf6CcSxpvBt2WzS3Dy82GNznyVp3sZ0CPoGdb6S+4jURHGeBIWa +rzyHH/eZ8V0eLBLMAyCpKQP2p/1CP7uxD7wnMhXbeg7wRReSROl3cynIAF78vh/k +I2BwO3JfJFtV2/sOAJ+HNqi4x7VdrQG8Zoy3ld0KhCOQJewDovx3iars/ItbXcXu +NOI6GjY0EU6PNP+x/t3jq5mtNmxI0cjf77lXqZFS91EqOOuRbxi54hkIUs86hoox +evYry2qbwBF8oErK7fd3PwPtT3zH9x3qN4/72NM0GeoP1iNlzB5xDH7ZXMl2hA6O +Qs48dRUAcPNHRn75uYqfN/i1S/n3IxzYY4BvWMiiiQ== +=paQq +-----END PGP SIGNATURE----- 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] 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 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQGcBAABCAAGBQJXgp5fAAoJEJQzkH1pP7W4MYUL/jA45/mULhVwrvU3AHvSmNPj +RxKZ9LFlMxpz0Pohl8D+11aGxWTIpfF3VkzTcvnWMud1dg5hAwgkjnfBV+75tSBC +6XKS6m0od+zpDI/PvXY8DRdmxx8uDsMyMn/DaNg/DMoQRb8d5fN7sax/lcCCYRm4 +hkCcKa5kmrLrtOAcgP9jzYZjneWcUejLV/J3rK9QUJXQBjI4e8y7NZdpzdr/m9gj +V2cHd3CDh6MbSRlv/FPMMxw9DXeBc5eybXIUu+JRPqvjqkGE79dC/ZAnjannHAkP +8uWjj3EGwJpGeR0YkvkXcA0LBtGzhswi7BUPbx60u9bA3pPViqXdAjx/yZsEtblT +spr4WD+3ZoAm1Dc18Gl5Nhr+0IgoZLut3IdSxYa3/IMrZdjSkEa3Vr2u35E8ef4D +Sv34xgg9oPnmn1pUfxGE6V1PDus6B+qPJHe5MSxEjksPv112fp4H4rXKN7sgRbJq +BEmTzn55iuWF3F1rpvn6V9w2abIVN2LSVnC6fOAH8A== +=fkdq +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20160814-summary.txt b/meeting-logs/20160814-summary.txt new file mode 100644 index 0000000..453efee --- /dev/null +++ b/meeting-logs/20160814-summary.txt @@ -0,0 +1,37 @@ +Summary of Gentoo council meeting 14th August 2016 +1) Roll call +================================================ +Present: blueness dilfridge jlec K_F rich0 ulm WilliamH + +2) Discussion on the state of the stable tree[0] +================================================ +Various aspects of the state of the stable tree were discussed in the meeting +and the Council decided on setting up a Working Group (WG) chaired by K_F to +continue discussions and come back to the Council with recommendations at a +later meeting on how to improve the state of the stable tree. + +3) Bugs with council participation[1] +================================================ +Bug 590972 titled "repoman should prevent people from adding a new package +with a metadata.xml pointing to maintained-needed directly" was discussed. +Adding a repoman check to stop addition of new packages directly to +maintainer-needed was determined to be within current understood policy, +and as such did not require a specific vote. Due to the bug report requesting +a confirmation from Council, one was provided. + +The Council walked through the rest of the list of bugs listed for Council +action and concluded that no new action that requires Council attention at +this time has come up with them. + +4) Open floor +================================================ +It was briefly discussed whether an infra-side git push check could mitigate +issues such as the one discussed in Bug 590972, but it was concensus that such +a check would add little additional value. + +References: +================================================ +[0] +https://archives.gentoo.org/gentoo-project/message/fb5d6fe4d6f84eeb5fedff2e968675fb +[1] +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=3253044&query_format=advanced diff --git a/meeting-logs/20160814-summary.txt.asc b/meeting-logs/20160814-summary.txt.asc new file mode 100644 index 0000000..e1827d2 --- /dev/null +++ b/meeting-logs/20160814-summary.txt.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP SIGNATURE----- + +iQEcBAABCgAGBQJXxzQ6AAoJECULev7WN52FbEUH/1/kHppB7DpfUWZdMDoGxMk9 +qX8eC9wdSjPHfMdS+a5rJ/EtbeibgzqxxDXJNxL0D5Mt5WqPZApCgOWXINRbofPE +xeZiSHewLgM+Sbh5pFGtVMiX1thUDn1l1smZj4HQDZZbiXo6ZJw5T4NG8rn4X2y2 +hTTiKGaMHIh2WvIGEvFmmKHaOU9MdqD4aooazqwPQhU5UJzKDOotkqna7VS1MAfR +Nz0pNjuUbwU1cS+NLmp38c5TMlQ0BcA9VHv6rPLorxJ/UP42lEZVArU7kuPO/ZXW +fMlpbQiL8f7dOkdpt10AUeTiDv20aXJ4/3ADQsIcRgpPcD1rbnGdX4KUBX12aUs= +=Maqc +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20160814.txt b/meeting-logs/20160814.txt new file mode 100644 index 0000000..3eb1995 --- /dev/null +++ b/meeting-logs/20160814.txt @@ -0,0 +1,433 @@ +2016-08-14 20:59:45<@K_F> 4 1) Roll call +2016-08-14 20:59:58 * K_F is here +2016-08-14 21:00:08 * dilfridge feeds blueness a razz berry +2016-08-14 21:00:08 * rich0 is here +2016-08-14 21:00:12 * dilfridge here +2016-08-14 21:00:17 * WilliamH here +2016-08-14 21:00:34 * blueness here +2016-08-14 21:00:36 * ulm here +2016-08-14 21:01:04 * jlec here +2016-08-14 21:01:27<@K_F> So, the only non-standard item on today's agenda is 2) Discussion on the state of the stable tree[0] +2016-08-14 21:01:35<@K_F> https://archives.gentoo.org/gentoo-project/message/fb5d6fe4d6f84eeb5fedff2e968675fb +2016-08-14 21:01:54<@K_F> WilliamH: since you proposed the item, do you want to have a short introduction on what your focus is? +2016-08-14 21:02:04<@WilliamH> K_F: sure. +2016-08-14 21:02:37<@WilliamH> K_F: Basically, our stable tree is firmly stuck in the past, because arch teams, including amd64 these days, are having difficulty keeping up. +2016-08-14 21:03:00<@WilliamH> My focus isn't on getting rid of arch teams or changing what they do. +2016-08-14 21:03:28<@WilliamH> Our past decision on the issue was that after a package sits in ~, with an open stable request for 90 days, +2016-08-14 21:03:36<@WilliamH> and no arch teams respond, +2016-08-14 21:03:48<@WilliamH> the maintainer can remove the old stable version. +2016-08-14 21:04:01<@WilliamH> That hasn't played well because it breaks the depgraph etc. +2016-08-14 21:04:18<@blueness> WilliamH: i can speak for ppc/ppc64, arm and mips +2016-08-14 21:04:54<@WilliamH> blueness: ok, I want to say one more thing first. :-) +2016-08-14 21:04:58<@blueness> sure +2016-08-14 21:05:34<@WilliamH> blueness: What I'm interested in finding is a way for maintainers to move forward after stable reqs sit around for a long time so that the stable tree can be more current... +2016-08-14 21:05:56<@WilliamH> maybe allowing maintainers to stabilize the newer versions where the older versions are stable... +2016-08-14 21:05:56<@rich0> In the case of amd64, maintainers are already allowed to stabilize as long as the general requirements are met. +2016-08-14 21:06:08<@K_F> I have a few questions to that, but blueness was first so go ahead :) +2016-08-14 21:06:16<@ulm> rich0: we could generalise that rule to all archs +2016-08-14 21:06:19<@WilliamH> blueness: go for it. +2016-08-14 21:06:41<@blueness> i was just saying that i can speak for those teams, but i don’t have much to add specifically +2016-08-14 21:06:44<@ulm> i.e. if the maintainer has access to such a machine, he's allowed to stabilise himself +2016-08-14 21:07:07<@WilliamH> ulm: That's actually not even officially a rule for amd64. +2016-08-14 21:07:08<@blueness> personally i’d like to schedule packages for auto stabilization and then just walk away +2016-08-14 21:07:12<@blueness> ie automate +2016-08-14 21:07:18<@dilfridge> I can add a small datapoint - +2016-08-14 21:07:19<@rich0> ulm: access to such a machine would be the tricky part for all but amd64, but I'm fine with generalizing if they actually test it. +2016-08-14 21:07:34<@dilfridge> ALLARCHES does not work as designed, since most arch teams happily ignore it +2016-08-14 21:07:43< Blackb|rd> The thing about auto-stabilization is that the threshold matters. is 1.2->1.3 significant or not? That very much depends on the package. +2016-08-14 21:07:47<@WilliamH> ulm: the dev manual says that everything goes through the arch teams. +2016-08-14 21:07:48<@jlec> I maintained quite a bunch of packages and I really liked to offload the stabilization to another team +2016-08-14 21:07:51<@ulm> rich0: well, the maintainer cannot declare that things are stable without actually testing it +2016-08-14 21:07:56<@dilfridge> which, then, adds to the load of subsequent arches +2016-08-14 21:08:15<@jlec> Automated testing would be a good step towards simplification +2016-08-14 21:08:41<@blueness> jlec: automation may be difficult because the dependency tree is deep +2016-08-14 21:08:42<@rich0> dilfridge: one solution to the ALLARCHES problem might be automation. If some bot notices one arch stable, it auto-stabilizes the rest. +2016-08-14 21:08:56<@dilfridge> rich0: yes, that is doable +2016-08-14 21:09:02<@K_F> My question/comment is to the way of, the impact of this seems to be very dependent on context so I'm not sure a single solution can necessarily work, but there are several things I'd like to discuss about stable tree in general. very important thing is what impact does keeping the old version vs the new version have on stability, say for a server application +2016-08-14 21:09:09< Blackb|rd> jlec: that depends on hw availability which is basically zero for most fringe archs +2016-08-14 21:09:14<@jlec> blueness: we could at least automate testing like the arch teams aredoing it right now +2016-08-14 21:09:16<@dilfridge> rich0: right now I occasionally do that from the maintainer point of view +2016-08-14 21:09:21<@rich0> In general I'm open to doing things to reduce barriers to testing and stabilization, but I'm not a fan of skipping testing. +2016-08-14 21:09:22<@K_F> should we have same treatment for apache/nginx/etc as for a leaf-application in the tree? +2016-08-14 21:10:06<@K_F> and is the primary issue with the stable tree that applications aren't being stabilized quick enough, or actual bugs being allowed into the stable tree to begin with? +2016-08-14 21:10:17<@jlec> Blackb|rd: true, but at least x86/amd64 could benefit +2016-08-14 21:10:25<@K_F> in which case, will automation or quick stabilization by maintainer have a positive or negative contribution on the issue +2016-08-14 21:11:03<@WilliamH> My question about "fringe" arches is, should they be marked stable in their profiles? +2016-08-14 21:11:09<@K_F> for a lot of cases I'm in favor of allowing maintainer to stabilize, presuming that the maintainer is actually a person that is expected to USE the application more than you can expect others +2016-08-14 21:11:27<@dilfridge> WilliamH: that's yet another question +2016-08-14 21:11:29<@K_F> so they should be most aware of current issues, tracking upstream bugtracker and VCS already +2016-08-14 21:11:40<@dilfridge> and "stable profile" is actually completely unrelated to "stable testing" +2016-08-14 21:12:08<@WilliamH> dilfridge: stable profile means that repoman by default complains if their depgraph is broken. +2016-08-14 21:12:12< Blackb|rd> WilliamH: the problem wiht "not stable" is that is the equivalent of "moribund" +2016-08-14 21:12:16<@rich0> WilliamH: what will de-stabilizing the minor archs solve? +2016-08-14 21:12:29<@rich0> Are you concerned about burden on maintainers? +2016-08-14 21:12:32<@dilfridge> WilliamH: yes, and I think that might be useful even for ~arch only arches +2016-08-14 21:12:44<@dilfridge> so we need to redefine and improve that portage feature, +2016-08-14 21:12:51<@WilliamH> rich0: correct. +2016-08-14 21:12:54<@dilfridge> but it has nothing to do with out current arch testing problem +2016-08-14 21:13:05<@WilliamH> True, maybe that's a red herring... +2016-08-14 21:13:11<@WilliamH> dilfridge: ^^ +2016-08-14 21:13:19<@jlec> With the small size of our dev team "stable" becomes really important, because we cannot guarantee that ~arch packages are well looked after and bugs are fixed. On the other hand, if bugs are fixed in arch, we need ot bring it stable +2016-08-14 21:13:27<@dilfridge> f.ex., it would make sense to keep the ~mips tree consistent +2016-08-14 21:13:31<@WilliamH> So let's go back to the arch testing... +2016-08-14 21:13:36<@dilfridge> but there is no "profile setting" for that +2016-08-14 21:13:44<@WilliamH> K_F: I need to clarify your position. +2016-08-14 21:14:09<@WilliamH> K_F: You are talking about allowing maintainers to stabilize. +2016-08-14 21:14:10< Blackb|rd> And from a personnel POV, I have been keeping Alpha mostly-current mostly by myself. While not sustainable, it also means that the effort for keeping an arch somewhat-current is not insurmountable +2016-08-14 21:14:23<@K_F> jlec: yes, that is a sub-point of mine: I'd like us to consider a formal suggestion that bugs should normally not be marked as resolved/fixed before a version including the fix has been included in the stable tree. In the interim the InVCS keyword is used to mark a fix having been applied to non-stable. +2016-08-14 21:14:38<@WilliamH> K_F: are you saying that maintainers can stable on any arch or just the ones they have access to? +2016-08-14 21:14:41<@K_F> jlec: but we can come back to that later on, along with ulm's suggestion +2016-08-14 21:14:45<@dilfridge> A] The current bugzilla usage is b0rken, since me and many others close bugs when the fix is in ~arch - for the simple reason that I dont want to keep a huge number of "unresolved bugs" until arch teams wake up +2016-08-14 21:14:59<@K_F> WilliamH: they have access to directly or via gentoo infra made available for the purpose +2016-08-14 21:15:13<@K_F> or for that matter non-gentoo infra +2016-08-14 21:15:13<@blueness> how hard would it be to write a utility that finds ebuilds that are ~arch, older than 1 month, and email the maintainers periodic reminders to stabilize them? +2016-08-14 21:15:23<@dilfridge> suggestion for A] -> introduce a new status TESTING (instead of the InVCS keyword) +2016-08-14 21:15:35< Blackb|rd> dilfridge: would it be useful to discern solved-in-~ vs. soved in stabvle? +2016-08-14 21:15:44<@ulm> there is TEST-REQUEST already +2016-08-14 21:15:45<@dilfridge> then a bug goes CONFIRMED -> TESTING -> RESOLVED FIXED +2016-08-14 21:16:01<@WilliamH> ulm: that's also resolved. +2016-08-14 21:16:05<@jlec> dilfridge: or we could have a procedure to add the package automatically to an official stabilization backlog +2016-08-14 21:16:08<@K_F> dilfridge: that can be worth discussing, but atm we have the InVCS for the purpose and it should be used until another suggestion is in place +2016-08-14 21:16:20<@WilliamH> ulm: maybe that's ok though... because then it would go to resolved/fixed +2016-08-14 21:16:20<@K_F> dilfridge: but if it works better for workflow to have another status, I'm fine with that +2016-08-14 21:16:25<@jlec> Currently testing means we send the fix back to user to test +2016-08-14 21:16:26<@dilfridge> K_F: it's not going to be used, since noone wants his open bugs list to explode +2016-08-14 21:16:29<@K_F> the main issue is the bug should not simply be marked resolved +2016-08-14 21:16:44<@K_F> dilfridge: its easy to filter out in search, I have different lists for with and without it myself +2016-08-14 21:16:46<@jlec> We will not change this behaviour +2016-08-14 21:16:51<@ulm> WilliamH: sure, since bug resolution is independent of stable status +2016-08-14 21:16:52<@dilfridge> Blackb|rd: that's what I propose +2016-08-14 21:16:54<@jlec> We need to come up with somethign new +2016-08-14 21:17:02<@WilliamH> K_F: you have to mark it resolved/test-request +2016-08-14 21:17:13<@WilliamH> K_F: which makes sense... +2016-08-14 21:17:20<@ulm> especially, stable status is arch dependent, whereas bug resolution (usually) isn't +2016-08-14 21:17:22<@WilliamH> K_F: then it would go to resolved/fixed +2016-08-14 21:17:22<@K_F> jlec: yes, I believe we need to introduce a new status entry called NEED_STABILIATION or something else explicit if we go that route +2016-08-14 21:17:25<@dilfridge> ulm: RESOLVED TEST-REQUEST means "I need more data, cant do anything now" +2016-08-14 21:17:39<@ulm> that's NEEDINFO +2016-08-14 21:18:00<@dilfridge> well a variant of that, but yes essentially it's a close relative +2016-08-14 21:18:22<@jlec> To me TEST-REQUEST means , I fixed it, please test if the fix helps you as well +2016-08-14 21:18:28<@blueness> RESOLVED TEST-REQUEST means you think the issue is resolved but would like testing +2016-08-14 21:18:29<@dilfridge> "here's a patch, I have no clue if it works, tell me!" +2016-08-14 21:18:36<@jlec> So normally I leave it like this if nothing comes back +2016-08-14 21:18:41<@ulm> jlec: right, and TEST-REQUEST says that the fix is in the tree +2016-08-14 21:18:42<@jlec> Too many bugs to fix +2016-08-14 21:18:47<@jlec> yes +2016-08-14 21:18:52<@jlec> but not stable +2016-08-14 21:18:56 * WilliamH agrees with blueness +2016-08-14 21:19:11<@K_F> yeah, we shouldn't overload current workflow to mean anything else +2016-08-14 21:19:15<@rich0> I think there are a lot of ideas, and they probably should be pursued on thier own merits/etc. +2016-08-14 21:19:18<@dilfridge> so how about, for clarification let's rename TEST-REQUEST to TESTING ? +2016-08-14 21:19:33<@rich0> Incrementally they would probably help. +2016-08-14 21:19:33<@dilfridge> to make clear "it's resolved in testing" +2016-08-14 21:19:34<@jlec> no +2016-08-14 21:19:35<@K_F> dilfridge: is there actually a need to rename it? +2016-08-14 21:19:47<@K_F> dilfridge: TEST-REQUEST seems more intuitive to users +2016-08-14 21:19:51<@WilliamH> No, there's no need to rename +2016-08-14 21:19:51<@dilfridge> yes, since everyone seems to have a different idea what it means +2016-08-14 21:20:12<@jlec> We need something new. Anyttihng close to what we have will not owrk, because people will abuse to have the same behaviour as right now +2016-08-14 21:20:27<@blueness> dilfridge: you just need a better explanation in the tip on bugzilla +2016-08-14 21:20:29<@dilfridge> in my opinion it's similar to RESOLVED OBSOLETE, it's not clear if the issue is actually resolved but maybe someone will test +2016-08-14 21:20:45<@K_F> TEST-REQUEST +2016-08-14 21:20:46<@K_F> The bug is thought to be fixed, but we would like someone who is affected to verify the fix. If the bug is not actually fixed, then the report should be reopened and more details posted (explaining why people believe the bug is not actually fixed). +2016-08-14 21:20:48 * WilliamH agrees w/ blueness +2016-08-14 21:21:04<@K_F> the description seems rather non-ambiguative to me +2016-08-14 21:21:09<@ulm> we could use RESOLVED -> CLOSED when the ebuild enters stable +2016-08-14 21:21:19<@dilfridge> K_F: ok but this ^ has no relation to ~arch statis +2016-08-14 21:21:27<@WilliamH> True. +2016-08-14 21:21:27<@K_F> dilfridge: I'm not saying it is, or should be +2016-08-14 21:21:44<@K_F> but I wouldn't want to overload the old behavior, as having that is useful in the workflow +2016-08-14 21:21:44<@WilliamH> let's go back to moving packages to stable... +2016-08-14 21:22:06<@WilliamH> Right now, things can set infinitely waiting for arch teams to wake up and move them to stable. +2016-08-14 21:22:26<@blueness> i’m not sure how this helps with stabilization +2016-08-14 21:22:29<@blueness> i’d like to think about what proceedure we could use to automate stabilization +2016-08-14 21:22:30<@blueness> i did a lot of stabilizations for ppc/ppc64 in 2012 and it was boooooring +2016-08-14 21:22:31<@K_F> WilliamH: right, and whether that is an issue or not depends on context, e.g is this a library that is required to add another package? +2016-08-14 21:22:31<@blueness> i fatigued quickly and probably made lots of mistakes +2016-08-14 21:22:34<@WilliamH> Is that stil what we want? +2016-08-14 21:22:34<@jlec> We need an easy marker devs can set when closing the bug +2016-08-14 21:22:48<@dilfridge> see Perl... 5.22.2 is supposed to go stable for ages (also sec fix), soon we'll have 5.22.3 with the next bunch of sec fixes +2016-08-14 21:23:39<@WilliamH> Also, see as an example, the kmod stablereq that is open. +2016-08-14 21:23:40<@K_F> blueness: the problem I see with automating stabilization is that upstreams don't necessarily have sufficient unit tests written, so it'd require a lot of downstream work, in particular for GUI applications +2016-08-14 21:24:14<@K_F> blueness: as I don't consider stable process to be build-testing only +2016-08-14 21:24:30<@WilliamH> K_F: imo, that's what the wait in ~arch is for. +2016-08-14 21:24:34<@blueness> K_F: we might have to compromise +2016-08-14 21:24:58<@K_F> blueness: and then it comes back to what is the consequence of waiting, is it other packages being held up, or simply stable being a bit behind +2016-08-14 21:25:17<@K_F> my personal opinion is having an older version that is bug-free and security-wise good, is no issue in itself +2016-08-14 21:25:19<@dilfridge> as long as something is moving, I have no problem with a slightly antiquated stable +2016-08-14 21:25:25<@blueness> K_F: we could semi automate +2016-08-14 21:25:27<@blueness> so +2016-08-14 21:25:32<@dilfridge> just now the ~arch versions are usually more bug-free +2016-08-14 21:25:43<@ulm> I suspect that on some arches waiting for one month doesn't even ensure that even a single user has run the package +2016-08-14 21:25:43<@blueness> a utility would scan the tree for 1 month old ~arch foreach arch +2016-08-14 21:25:48<@WilliamH> K_F: ^^ +2016-08-14 21:26:00<@K_F> dilfridge: which is bad, but I belive that comes down to making a statement on closing bugs before it hits stable as we've already started discussing +2016-08-14 21:26:01<@blueness> it would then find all the deps that also need to be stabilized +2016-08-14 21:26:09<@blueness> and email that list to the maintainers +2016-08-14 21:26:10<@K_F> dilfridge: not simply auto-stabilizing more +2016-08-14 21:26:15<@blueness> just that alone would speed things up +2016-08-14 21:26:36<@K_F> blueness: more tools to that extent can only be a good thing +2016-08-14 21:26:37<@dilfridge> here's more food for thought +2016-08-14 21:26:38<@blueness> i personally am lost on all my pkgs that need stabilization +2016-08-14 21:26:58<@WilliamH> That's my problem too. I'm as guilty as the next guy of not filing stablereqs +2016-08-14 21:27:02<@dilfridge> B] ALLARCHES isnt working since arch teams are ignoring it, to the disadvantage of the next arch team down the line +2016-08-14 21:27:06<@blueness> K_F: then in ppc/ppc64 i could just feed that list to anohter utility and if the build boom done +2016-08-14 21:27:10<@dilfridge> sorry said that already +2016-08-14 21:27:29<@dilfridge> but we could automatize that, true +2016-08-14 21:27:37<@K_F> blueness: if build-testing is only criteria.. which is a big "if" +2016-08-14 21:27:54<@dilfridge> C] does anyone know what the status of the GSoC project is? it's kinda relevant... +2016-08-14 21:28:09<@jlec> no +2016-08-14 21:28:30<@dilfridge> sigh +2016-08-14 21:28:31<@K_F> blueness: in that case, I'd expect a different treatment for a patch release vs a minor/major release, but with upstreams not doing proper branching, that itself is difficult to gauge and to a great extent is maintainer discretion as they should know best by following the package development closely +2016-08-14 21:28:48 * dilfridge drops GSoC and pulls the flush +2016-08-14 21:29:02<@K_F> dilfridge: I'm getting the update emails at least +2016-08-14 21:29:20<@blueness> K_F: generating a list and even automating the compile-test part of it is a step in the right direction +2016-08-14 21:29:49<@WilliamH> I've also heard maintainers say they don't stabilize unless someone asks them to. +2016-08-14 21:29:56<@K_F> "The week was spent in testing, running the deployed server 24x7 with stabilization requests automated to be triggered on Travis CI every 15 minutes for around 4 days. I am currently working on creating an automated overlay of all ebuilds that are successfully stabilized, as well as completing the documentation of the code." +2016-08-14 21:30:31<@K_F> blueness: that is what the GSoC project is doing +2016-08-14 21:30:38<@blueness> K_F: yep +2016-08-14 21:30:40<@blueness> sounds good +2016-08-14 21:30:54<@blueness> we should hijack this person :) +2016-08-14 21:30:54<@WilliamH> it doesn't need to worry about overlays. +2016-08-14 21:31:09<@blueness> WilliamH: well right now he has to work in overlays +2016-08-14 21:31:16<@WilliamH> blueness: True. +2016-08-14 21:32:07<@WilliamH> I guess what I'm asking for is a way to stabilize newer versions on all arches where an older version is stable if the arch teams don't wake up and do it in a reasonable amount of time. +2016-08-14 21:32:19<@K_F> WilliamH: that is a bit worrying, if they have known issues in bug reports that should not have been marked closed without stabilization, and they don't stabilize, the state of stable tree is negatively affected +2016-08-14 21:32:26<@blueness> K_F: is his work bound to just amd64? +2016-08-14 21:32:45<@K_F> WilliamH: so not allowing a resolve fixed before it being in stable tree should incentivize maintainers to create stablereqs +2016-08-14 21:33:01<@K_F> blueness: afaik atm only amd64, but that should be possible to extend +2016-08-14 21:33:10<@K_F> need to start somewhere +2016-08-14 21:33:31<@WilliamH> The devmanual should be updated probably with any new guidelines we come up with. +2016-08-14 21:33:32<@blueness> K_F: travis ci may not permit ppc64 etc +2016-08-14 21:33:46<@K_F> I guess it'd be similar to debian buildhosts etc and checking the build status +2016-08-14 21:34:10<@K_F> blueness: well, if the control machine is running on a different host than the actual build host that should be able to fix anyways, shouldn't it? +2016-08-14 21:34:34<@dilfridge> right +2016-08-14 21:34:36<@K_F> could use one control for all arches in theory, and parse logs etc +2016-08-14 21:34:45<@dilfridge> we're effectively talking about an official tinderbox system +2016-08-14 21:34:45<@blueness> K_F: not sure +2016-08-14 21:34:51<@K_F> dilfridge: right +2016-08-14 21:35:31<@K_F> on that note I'd like to add that toralf is doing a great job on it for amd64 already +2016-08-14 21:35:50<@WilliamH> K_F: agreed, he is. +2016-08-14 21:36:21<@dilfridge> yes, he is +2016-08-14 21:36:31<@dilfridge> so the interesting question is +2016-08-14 21:36:50<@dilfridge> if tinderboxing is to become such a central part of all our workflow +2016-08-14 21:37:00<@ulm> my impression is that he's mainly finding broken reverse dependencies +2016-08-14 21:37:13<@K_F> ulm: that is a good thing to fix on its own, though +2016-08-14 21:37:14<@ulm> but not so many original issues +2016-08-14 21:37:19<@ulm> K_F: sure +2016-08-14 21:37:21<@dilfridge> can we do that with only "inofficial systems"? +2016-08-14 21:37:40<@K_F> dilfridge: my perspective on that is no, if we are to go that route it would need to be official gentoo infra +2016-08-14 21:37:56 * dilfridge suggests we then pass on to the open floor. +2016-08-14 21:38:09<@K_F> dilfridge: bugs with council involvement etc first +2016-08-14 21:38:16<@dilfridge> hrhr +2016-08-14 21:38:29<@K_F> dilfridge: but you propose we don't make any actual resolutions today and keep it open for discussion on -dev? +2016-08-14 21:38:40<@dilfridge> that wasnt fully serious +2016-08-14 21:38:46<@WilliamH> Also, I do think we need to clarify the devmanual wrt stabilization. +2016-08-14 21:38:51<@WilliamH> https://devmanual.gentoo.org/keywording/index.html +2016-08-14 21:39:05<@WilliamH> states that only arch teams can do it. +2016-08-14 21:39:18<@dilfridge> I also like the suggestion by jmorgan to found a project / group / taskforce to work out solutions +2016-08-14 21:39:37<@WilliamH> We even have a separate glep that says x86 is like all other arches. +2016-08-14 21:39:55<@blueness> K_F: dilfridge yeah let’s generate discussion on -dev +2016-08-14 21:40:06<@WilliamH> In the meantime, what do we do? +2016-08-14 21:40:16<@dilfridge> only discussion on -dev probably doesnt help +2016-08-14 21:40:53<@K_F> dilfridge: well, it'd be in preparation for another council meeting in order to have some concrete voting points +2016-08-14 21:41:00<@blueness> WilliamH: i suggest we think of some well defined workflow +2016-08-14 21:41:07<@K_F> such as not allowing to close bugs as being resolved fixed before it is in stable +2016-08-14 21:41:08<@blueness> and then bring it foward to -dev +2016-08-14 21:41:11<@dilfridge> yes, but after some brainwork +2016-08-14 21:41:28<@K_F> but what workflow is best for that, if people don't like the current InVCS and would like a separate status entry, is good to discuss +2016-08-14 21:41:34<@WilliamH> K_F: I don't think that can apply for hosted projects. +2016-08-14 21:41:54<@WilliamH> K_F: actually it doesn't. +2016-08-14 21:41:55<@K_F> WilliamH: that should be a separate project, so not impact the package part of things +2016-08-14 21:42:10<@K_F> WilliamH: but correct, it should be limited to the scope of the Gentoo repository/tree +2016-08-14 21:42:34<@K_F> although that will likely require a few duplicate bug reports, filing stable requests etc +2016-08-14 21:42:42<@K_F> but a good thing to discuss on -dev +2016-08-14 21:43:26<@WilliamH> K_F: so what do we do in the meantimne w/ stuck stable requests... like the one I cited... +2016-08-14 21:43:51<@blueness> WilliamH: what do you suggest we do? +2016-08-14 21:43:55<@dilfridge> I fear that making more patchwork out of policies doesnt help... +2016-08-14 21:43:57<@K_F> WilliamH: it depends on what issue the "stuck stable request" cause, which at this point seems to be a per-request basis +2016-08-14 21:44:17<@WilliamH> dilfridge: true, what do you suggest? +2016-08-14 21:45:25<@dilfridge> continue this discussion outside the meeting for more "radical solutions", including more interested parties +2016-08-14 21:45:30<@K_F> well, I don't believe we'll come to any conclusions today, so I propose I write an email to -dev over next few days to start a thread on discussion on a few related issues, and then we can bring it back up on a later meeting +2016-08-14 21:45:45<@dilfridge> come up with some ideas, propose them on -dev +2016-08-14 21:45:52<@K_F> with specific questions to vote on +2016-08-14 21:45:56<@dilfridge> and develop some new system until the next council meeting +2016-08-14 21:46:01<@dilfridge> so we can vote on it +2016-08-14 21:46:32<@WilliamH> Let's go for that. I do think our policy is a mess, it should be much more simple than it is. +2016-08-14 21:46:33<@dilfridge> but it needs to be realistic, so anything requiring gentoostats is (for now) off the table :P +2016-08-14 21:46:45 * WilliamH agrees with dilfridge +2016-08-14 21:47:05<@WilliamH> We can't depend on vaporware. +2016-08-14 21:47:55<@dilfridge> kent\n also had some nice ideas on the list, but they are one order of magnitude larger than what we can do in a month... +2016-08-14 21:47:59<@K_F> so, anyone want to bring up something else on this matter in this meeting, or should be move on to next agenda item? +2016-08-14 21:48:15<@K_F> s/be/we/ +2016-08-14 21:48:21-!- mode/#gentoo-council [+o blueness] by ChanServ +2016-08-14 21:48:21<@jlec> we should move on. +2016-08-14 21:48:26<@dilfridge> K_F: shall we make some sort of resolution to start up a stabilization task force? :) +2016-08-14 21:48:36<@dilfridge> like jmorgan suggested... +2016-08-14 21:49:07<@K_F> dilfridge: I'm not sure if I'm ready for any funded approach yet, but setting up a workgroup to come with a proposal to council would be fine with me. I'd even volunteer to run it +2016-08-14 21:49:24<@dilfridge> whee a volunteer :D +2016-08-14 21:49:32<@WilliamH> ;-) +2016-08-14 21:50:04<@WilliamH> K_F: I don't think we need a vote for that, just go for it. :-) +2016-08-14 21:50:16<@K_F> WilliamH: well, a vote would be good to get a mandate to work on it +2016-08-14 21:50:24<@K_F> but depends on how bureaucratic we want to be +2016-08-14 21:50:40 * WilliamH doesn't see anyone objecting... +2016-08-14 21:51:16<@K_F> if nobody is objecting I can set up such a working group, to come back with a proposal for the council at a later meeting (not necessarily next one, depends on the discussions etc) and write up a short report with discussion items etc +2016-08-14 21:51:29<@dilfridge> ++ +2016-08-14 21:51:34<@K_F> and start it off asking for participants on -dev (and -dev-announce) MLs +2016-08-14 21:51:40<@ulm> +1 +2016-08-14 21:52:07<@rich0> ++ +2016-08-14 21:52:17<@WilliamH> ++ +2016-08-14 21:52:35<@K_F> ok, sounds good then. next item: Bugs with council participation[1] +2016-08-14 21:52:51 * dilfridge sneaks off +2016-08-14 21:52:51<@K_F> 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=3253044&query_format=advanced +2016-08-14 21:52:58<@K_F> dilfridge: bye +2016-08-14 21:53:10<@K_F> I don't actually see any bugs we haven't discussed previously or that seems to merit action at this point +2016-08-14 21:53:20<@K_F> anyone disagree and would like to discuss any? +2016-08-14 21:53:48<@jlec> no, We have seen them before +2016-08-14 21:54:15<@blueness> sounds good +2016-08-14 21:54:15<@blueness> i don’t want to discuss games +2016-08-14 21:54:28 * dilfridge back +2016-08-14 21:54:39<@K_F> I'm opening up the floor then for the last agenda item +2016-08-14 21:54:45<@dilfridge> actually w/r to games a lot is happening, so no worry there +2016-08-14 21:54:45<@ulm> well, some of these bugs require e.g. infra action +2016-08-14 21:55:01<@K_F> ok, holding off on that, ulm any particular you'd like to discuss? +2016-08-14 21:55:06<@WilliamH> dilfridge: yeah, wizardedit is doing a lot of games work for one. :-) +2016-08-14 21:55:09<@ulm> but nothing has happened since several months +2016-08-14 21:55:25<@K_F> ulm: would that be bug 565566 ? +2016-08-14 21:55:28< willikins> K_F: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs +2016-08-14 21:55:43<@ulm> K_F: right +2016-08-14 21:55:50<@WilliamH> That's waiting for infra +2016-08-14 21:55:57<@K_F> and bug 577722 +2016-08-14 21:55:59< willikins> K_F: https://bugs.gentoo.org/577722 "Multiple packages have broken Manifest"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs +2016-08-14 21:56:15<@dilfridge> that is a really annoying one +2016-08-14 21:56:20<@K_F> of those two, if we are to discuss, the latter is likely most important to fix, as it causes user brakage +2016-08-14 21:56:42<@K_F> but afaik there have been some action by infra to mitigate it already, including the clock skew requirements +2016-08-14 21:56:44<@WilliamH> That's also waiting for infra I think? +2016-08-14 21:57:30<@dilfridge> it's a bit like "waiting for a complicated solution to be deployed while most breakage would be removed by just dropping stuff", right? +2016-08-14 21:57:47<@WilliamH> dilfridge: I think so... +2016-08-14 21:57:50<@K_F> dilfridge: dropping? +2016-08-14 21:57:52<@ulm> same for changelogs +2016-08-14 21:57:57<@K_F> well, for changelogs, yes +2016-08-14 21:57:58<@dilfridge> dropping changelogs +2016-08-14 21:58:02<@K_F> but not for broken manifests +2016-08-14 21:58:03<@WilliamH> changelogs are supposed to be dropped. +2016-08-14 21:58:14<@WilliamH> We made that decision before the migration. +2016-08-14 21:58:33<@K_F> although if the issue with manifests is historical, maybe touching the full repo would remove all the old issues, and the git time skew requirement removes further issues? +2016-08-14 21:58:33<@ulm> I mean, if I read "pending having a good historical conversion of CVS->Git" then that sounds like it will never happen +2016-08-14 21:58:59<@dilfridge> the git skew requirement is a pain if you work with the laptop +2016-08-14 21:59:01<@K_F> (touching full repo for manifests anyways) +2016-08-14 21:59:08<@K_F> dilfridge: works fine for me +2016-08-14 21:59:55<@K_F> granted I do rather forceful ntp synch from time to time getting back from hibernation, and don't see much issue with that, anything that requires accurate cron etc is running on stable architecture +2016-08-14 22:00:03<@WilliamH> dilfridge: can you explain more about that? I'm thinking that all you have to do is use npt? +2016-08-14 22:00:17<@WilliamH> mtp * +2016-08-14 22:00:26<@dilfridge> 1) I prefer my machine without open ports, since it ends up on all sorts of networks +2016-08-14 22:00:48<@dilfridge> 2) I can't do automated ntpdate, since at a random point in time it's not clear if the laptop has a network +2016-08-14 22:01:24<@dilfridge> well I probably could if I just ignore the errors :/ +2016-08-14 22:01:25<@K_F> dilfridge: well, I do it in script while bringing up VPN, at which point I'm sure I have a network and have logged into it etc +2016-08-14 22:01:57<@dilfridge> and then you push your previous commits and poof .... +2016-08-14 22:02:21<@dilfridge> (or not?) +2016-08-14 22:02:26 * dilfridge confuserated +2016-08-14 22:02:31<@dilfridge> anyway +2016-08-14 22:02:35<@K_F> works fine, but I bring up VPN for things early in process anyways +2016-08-14 22:02:36<@dilfridge> this is not so important for now +2016-08-14 22:02:48<@K_F> but I don't see us comming up with a resolution for any of these bugs today +2016-08-14 22:03:05<@K_F> and it is being worked on as I've seen, so don't believe council action is merited at this point +2016-08-14 22:03:19<@K_F> but it is annoying +2016-08-14 22:03:24<@K_F> if it is user breaking +2016-08-14 22:04:04<@K_F> so, anyone have anything to add, or should be move on to open floor? +2016-08-14 22:05:20<@jlec> let's move on +2016-08-14 22:05:30<@K_F> 4) Open floor +2016-08-14 22:05:44<@K_F> any member of the community want to add something to the discussion or bring up any issues for debate? +2016-08-14 22:06:07<@dilfridge> do we want to talk about the maintainer-needed additions to the tree today, or do we put it on the agenda for next time? +2016-08-14 22:06:24<@K_F> point of procedure, nothing will be decided in open floor, if something requires a vote it should be brought up during call for agenda items for a proper council preparation +2016-08-14 22:06:31<@dilfridge> ok +2016-08-14 22:06:50<@K_F> but we can have an informal discussion on it if no other member has anything to bring up at this time +2016-08-14 22:07:14<@K_F> (member of the community, not restricted to council) +2016-08-14 22:07:34<@WilliamH> I don't know what the additions were, but it has never been cool to drop a package directly in with maintainer-needed status. +2016-08-14 22:07:43<@K_F> WilliamH: ++ +2016-08-14 22:07:51<@dilfridge> WilliamH++ +2016-08-14 22:08:19<@jlec> There is a typical candidate for this behaviour +2016-08-14 22:08:19<@K_F> dilfridge: that specific commit you're thinking of was reverted, right? +2016-08-14 22:08:28<@dilfridge> yes, by me +2016-08-14 22:08:28<@rich0> Agree. I think that is basically existing policy. +2016-08-14 22:09:46<@blueness> i’m a bit confused, can you guys give me context, what pkg was dropped directly to maintainer-needed and what is the correct procedure? +2016-08-14 22:09:59<@K_F> blueness: not dropped to, new package added +2016-08-14 22:10:11<@blueness> oh added directly to maintainer-needed! +2016-08-14 22:10:15<@blueness> yeah that’s just wierd +2016-08-14 22:10:18<@WilliamH> blueness: right, a new package was added to the tree, but with no maintainer. +2016-08-14 22:10:49<@blueness> why would anyone add a package with no maintainer, that’s like adding lint on purpose +2016-08-14 22:11:04<@WilliamH> blueness: when something new is added, someone, or a project, is supposed to sign up to maintain it. +2016-08-14 22:11:25<@WilliamH> blueness: hang on I'll look for the commit hash +2016-08-14 22:11:26<@blueness> WilliamH: of course, i’m just wonder why this isn’t common sense +2016-08-14 22:11:35<@WilliamH> blueness: who knows... +2016-08-14 22:11:40<@blueness> i mean there might be some reason i don’t know +2016-08-14 22:13:13<@ulm> common sense is also to announce it in the ML if maintainership is dropped +2016-08-14 22:13:32<@WilliamH> blueness: the hash is 2d5acbfd +2016-08-14 22:13:34<@K_F> well, I think we agree that it is bad practice to add it, and if someone wants/needs a package in tree they should be willing to maintain it +2016-08-14 22:13:47<@ulm> by extension it would follow that adding a package directly as m-n should be announced too :/ +2016-08-14 22:13:51<@ulm> which is absurd +2016-08-14 22:13:51<@blueness> WilliamH: yeah i know what that’s all about now +2016-08-14 22:14:17<@blueness> K_F: we can ask for it to be made a repoman check +2016-08-14 22:14:24<@blueness> no initial commit with m-n +2016-08-14 22:14:43<@blueness> we could open a bug right now against portage +2016-08-14 22:14:46<@K_F> blueness: yes, we already discussed that a bit earlier, but as it is in line with current policy I don't think we need a council vote on it +2016-08-14 22:14:53<@K_F> we can jusdt open a bug requesting it to repoman +2016-08-14 22:14:57<@dilfridge> yes, such a repoman addon is good +2016-08-14 22:15:00<@WilliamH> Isn't there already a bug? +2016-08-14 22:15:14< kensington> bug #590972 +2016-08-14 22:15:16< willikins> kensington: https://bugs.gentoo.org/590972 "repoman should prevent people from adding a new package with a metadata.xml pointing to maintained-needed directly"; Portage Development, Repoman; CONF; pacho:dev-portage +2016-08-14 22:15:25<@K_F> kensington: thanks +2016-08-14 22:15:29<@dilfridge> (if people object because of overlays, the check could always only run for repository gentoo) +2016-08-14 22:15:37<@K_F> dilfridge: yup +2016-08-14 22:15:40<@WilliamH> Also, this should only apply if the repo name is gentoo +2016-08-14 22:16:04<@WilliamH> Actually don't we have a way to do repo-based checks already? +2016-08-14 22:16:10<@WilliamH> or was that not implemented? +2016-08-14 22:16:23<@dilfridge> no clue, that info got lost somewhere +2016-08-14 22:16:26<@blueness> i’m opening a bug now +2016-08-14 22:16:36<@blueness> oh never mind +2016-08-14 22:16:54<@jlec> WilliamH: I think this something coming with the new repoman way of creating checks +2016-08-14 22:17:10<@K_F> blueness: it is a bug, dol-sen requests a nod from council on it, which I believe we can give without a formal vote if we agree it doesn't change existing interprentation of policies +2016-08-14 22:17:10<@WilliamH> blueness: ? +2016-08-14 22:17:15< [Arfrever]> Infra-side check at time of 'git push' would be more effective. +2016-08-14 22:17:47<@K_F> it was also noted that that specific commit was not commited using repoman anyways +2016-08-14 22:17:54<@WilliamH> [Arfrever]: that comes after you run repoman. +2016-08-14 22:18:08<@dilfridge> K_F: yes... a bit sad but irrelevant... +2016-08-14 22:18:49<@blueness> WilliamH: i was going to open a bug against repoman but realized there was one already open +2016-08-14 22:18:51<@K_F> adding too much complexity to the git checks sounds a bit suboptimal, should use distributed resources for a bunch of these +2016-08-14 22:19:06<@K_F> and it was pointed out that e.g virtuals can have reasons for this +2016-08-14 22:19:21<@K_F> so will require a bit of granularity +2016-08-14 22:19:23<@ulm> repoman is much preferrable to a git check IMHO +2016-08-14 22:20:13<@K_F> I'll give a nod on the bug from council at least, to say that implementing it in repoman is OK +2016-08-14 22:20:15< [Arfrever]> An evil committer could simply not use repoman for committing or locally change his version of repoman to disable this check in metadata.xml. +2016-08-14 22:20:39<@K_F> [Arfrever]: yes, but that is a separate issue and we have channels of handling that +2016-08-14 22:20:51 * WilliamH agrees with K_F +2016-08-14 22:20:53<@dilfridge> Evil committers get handled eventually. +2016-08-14 22:20:55<@ulm> evil committers can do much worse things than omitting a maintainer entry +2016-08-14 22:21:18<@WilliamH> evil committers are a separate issue. +2016-08-14 22:21:21<@K_F> evil commits would get around a git check anyways, but using a two-step process +2016-08-14 22:21:38<@K_F> first add, then drop, as long as we allow dropping in general +2016-08-14 22:22:33<@K_F> ok, if there is nothing more to discuss on that matter. Anyone else wants something brought up? +2016-08-14 22:23:59<@K_F> lets give the question a minute or two, if nothing comes up we'll close the meeting +2016-08-14 22:24:06<@ulm> K_F: thanks for chairing :) +2016-08-14 22:24:27<@WilliamH> Thanks folks. :-) +2016-08-14 22:24:37<@dilfridge> Thanks everyone! +2016-08-14 22:25:34<@K_F> ok, seems others are fine +2016-08-14 22:25:35<@jlec> thanks +2016-08-14 22:25:37 * K_F bangs gavel +2016-08-14 22:25:57<@WilliamH> So can I stable openrc-0.21.3 on amd64 myself then? +2016-08-14 22:26:12<@rich0> WilliamH: yes, as long as you've tested it on a stable system +2016-08-14 22:26:36<@WilliamH> rich0: I run mostly stable. +2016-08-14 22:27:20<@jlec> Could someone have a look into app-misc/vit? +2016-08-14 22:27:20<@WilliamH> K_F: good luck with the stabilization task force... come back with something... :-) +2016-08-14 22:27:29<@K_F> WilliamH: will do :) +2016-08-14 22:27:29<@jlec> Looks like straight to m-n +2016-08-14 22:28:52<@K_F> jlec: I'd open a bug report to maintainer adding it requesting adding maintainer +2016-08-14 22:29:28<@K_F> s/maintainer/developer/ +2016-08-14 22:29:44<@K_F> bug 591112 +2016-08-14 22:29:47< willikins> K_F: https://bugs.gentoo.org/591112 "app-misc/vit: package added with no maintainer"; Gentoo Linux, Current packages; CONF; mgorny:qa +2016-08-14 22:30:05<@K_F> so that is already being handled by qa +2016-08-14 22:30:20<@WilliamH> Is that a gui? +2016-08-14 22:30:43<@K_F> WilliamH: seems to be a console frontend to taskwarrior +2016-08-14 22:31:09<@WilliamH> oh ok nvm, I don't know what taskwarrior is. +2016-08-14 22:31:59<@K_F> WilliamH: http://taskwarrior.org/ +2016-08-14 22:32:34<@K_F> WilliamH: TODO/Task manager diff --git a/meeting-logs/20160814.txt.asc b/meeting-logs/20160814.txt.asc new file mode 100644 index 0000000..0d0b7a5 --- /dev/null +++ b/meeting-logs/20160814.txt.asc @@ -0,0 +1,10 @@ +-----BEGIN PGP SIGNATURE----- + +iQEcBAABCgAGBQJXvfeVAAoJECULev7WN52Fx+kH/0Mh/kyCMBsZULekT8O8k6y0 +Y+AW+95UXw2KMl+MGn5nlKltHY/RK14i/sl0LjpTCgyIiKzGCJ5cEZjudtJv0WQ8 +SqGN1RdyAzFXIt3PO0/9uRQRn/u4gVtCW1YdiDUsDtFk/qsUP3nOuLHAqDJZ55jv +O3oIp9T9iykAkS5sizZUXTC/W5L7GuWuhQnp2PMOiLIWT3cCLZs4sNJ8exBVFNZu +ij+/myi9k0vu1BHVMdDXdARx9uTuzCqUWz3/Uu2yxBUA5iELHwlYo+8C4Oo5iT8J +fZKh1e0spvWg5Z0hPyKHJfR4zv/eRMhsWBbDJQIybgKVc3urff2CzWRBasBWvvY= +=zQl6 +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20160911-summary.txt b/meeting-logs/20160911-summary.txt new file mode 100644 index 0000000..67bdeeb --- /dev/null +++ b/meeting-logs/20160911-summary.txt @@ -0,0 +1,52 @@ +Summary of Gentoo council meeting 11 September 2016 + +Agenda +====== + +1) Roll call +2) RFC: Eclasses and EAPI[0] +3) Bugs with council participation +4) Open floor + +0) +https://archives.gentoo.org/gentoo-dev/message/87e630b9da724c5c59060608aba596a9 + + +Roll call +========= +Present: dilfridge, jlec, k_f, rich0, ulm, williamh +Absent: blueness + + +RFC: Eclasses and EAPI +====================== + +k_f asked the council to discuss the requirement of a definition of supported +EAPIs in eclasses. The general consensus was that this not having a proper +check only created minor issues so far and the council leaves the +responsibility with the respective eclass maintainers and QA for a general +solution. + +ulm mentioned his idea of splitting eclass in eclass libs and eclass, where +the eclass-libs contain the EAPI independent code in low level functions, where as +the actual eclasses themselves are EAPI dependent. This would be a very stable +and efficient architecture, but only in some niches eclasses are converting to +this e.g. perl. + +Nothing has been decided on this matter by the council in this meeting. + + +Bugs with council participation +=============================== + +571490: dilfridge follows this up +590972: Up to PM maintainers +Various games.eclass related bugs: Decision have been made, up to community to + implement +565566: Action form Infra missing, council will ping Infra for update + + +Open floor +========== + +-- diff --git a/meeting-logs/20160911-summary.txt.asc b/meeting-logs/20160911-summary.txt.asc new file mode 100644 index 0000000..13a5ae3 --- /dev/null +++ b/meeting-logs/20160911-summary.txt.asc @@ -0,0 +1,19 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG/MacGPG2 v2.0 + +iQJ8BAABCgBmBQJYhJ+cXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF +OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiJn8P/1yLk6BOcWMB0IP/rZllV/Ou +BSNobky4P6i+mq0O5CXbOSpecRdM5Y40/H1d1O8TxwHG2kYflakAwywIKDi7CEP2 +Df6O3tbVKgp8q8MABfkX4NeBHCgOpbXFr2n9A3D/Xzl8Il5zS9XTpvFSKbehXG6E +jkMJjdNdDc9Sqpnn6lzBsSupeJxDaePpVocQiGOuXdIiP0ER3bwanQ4dn6EOSp61 +8dUjwD2dC//ZjrMK5x5sGibS5kNeWHgq0rEafJFelCEcfypjh0dCS0FA0KI/5wV4 +eGZiOWS5NZYrWcTYGycsP3jf+ORlOm/NP+LAgSE4tlRj3qgnRviRTaOeOxDWGcni +fcCTo992GLkYP2tTXAOMfdhE9zRmPxuRwPSMSF4C/2K6cdMO6/W7NyZ4hxNxz19T +NVRydyAR3WBHjUVSB1SJMKWbc/eB3hCqmGiVPPiS3BJh2gtfMhQJvXmCeJ/g1Jah +d43Ywf4O972+ES72NqmViqnfQ6mUp7f1Q7fsXM+5aQf11G1fmZzS1RR6lNXx5K78 +acz9RBiyKsHhxiGWpYiCwkbpfEdl9eQ4soVUjhdKbSoO3plq9LXKe4KaqeVWOzjb +0v9doVlVGyEtGbu76baqaF5AG22/1VHgLUIiZ+q0GRDbDosVDCKeMCi1l8yc65hm +n3/TUpwsOdhGcvk0r8dk +=mTiT +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20160911.txt b/meeting-logs/20160911.txt new file mode 100644 index 0000000..5ff45d5 --- /dev/null +++ b/meeting-logs/20160911.txt @@ -0,0 +1,369 @@ +[21:01:08] <willikins> K_F: (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh +[21:01:11] <K_F> roll call +[21:01:11] <crankyrubian> (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh +[21:01:12] * K_F here +[21:01:17] <jlec> blueness dilfridge jlec K_F rich0 ulm WilliamH ping +[21:01:26] * rich0 here +[21:01:26] * WilliamH here +[21:01:30] * jlec here +[21:02:04] <jlec> dilfridge there? +[21:02:17] <K_F> whose bot is crankyrubian ? +[21:02:19] <jlec> Anybody proxying blueness ? +[21:02:37] <jlec> no idea? +[21:02:44] *** K_F sets mode: +q crankyrubian!*@* +[21:02:48] <rich0> My guess is not, since his absence was last-minute +[21:03:12] <jlec> WilliamH ping +[21:03:17] * WilliamH is here +[21:03:26] <dilfridge> here +[21:03:28] <jlec> ulm said he will be late +[21:03:50] * ulm here +[21:03:51] <dilfridge> dont know of anyone proxying blueness +[21:04:10] <WilliamH> dilfridge: I think blueness' issue was last minute. +[21:04:23] <jlec> 2) RFC: Eclasses and EAPI[0] +[21:04:34] <jlec> https://archives.gentoo.org/gentoo-dev/message/87e630b9da724c5c59060608aba596a9 +[21:04:54] <WilliamH> I don't think there's anything for us to do there; it is a qa issue. +[21:04:54] <jlec> K_F: you brought this up. +[21:05:02] <jlec> Can you go ahead here? +[21:05:06] <K_F> jlec: sure +[21:05:24] <K_F> jlec: I believe most of the discussion has taken place on the ML thread already, but the tl;dr is: +[21:06:34] <K_F> eclass maintainer is in a better situation to consider whether the eclass is appropriate for an EAPI bump. Explicit definition improves compatibility and removes uncertainty amongst developers not that familiar with the eclasses to consider whether it has been upgraded, which might fail in subtle (or not so much), ways +[21:07:16] <WilliamH> K_F: right. see line 29 of systemd.eclass as an example +[21:07:47] <K_F> now, the negative comments I've seen is mostly using specific functions before porting the full eclass +[21:07:52] <rich0> FWIW, I think it is a great idea +[21:08:04] <ulm> I don't think that there should be any EAPI conditionals for eclasses in the package manager +[21:08:15] * WilliamH agrees with ulm +[21:08:25] <K_F> ulm: indeed, the proposal is for in-eclass test for EAPI +[21:08:45] <WilliamH> K_F: a number of eclasses already do it. +[21:08:48] <ulm> and befaore we would do that, we would have to disentangle eclasses and eclass libraries +[21:09:03] <ulm> the latter being largely independent of EAPI +[21:09:13] <K_F> ulm: can you elaborate a bit on that? +[21:09:14] <dilfridge> it works perfectly fine by testing inside the eclass +[21:09:37] <K_F> ulm: are you talking the in-eclass case, or possible PMS change now +[21:09:45] <ulm> K_F: some eclasses just provide utility functions, these are the one I call eclass libs +[21:09:51] <ulm> e.g. versionator.eclass +[21:10:01] <dilfridge> I suppose ulm means something like perl-modules.eclass (with phase functions) and perl-functions.eclass (which provides utility functions) +[21:10:04] <K_F> ulm: I don't see why they shouldn't be treated the same in EAPI case question +[21:10:15] <jlec> me neither +[21:10:19] <K_F> ulm: although adding support for new EAPI in those cases should likely be easier +[21:10:20] <WilliamH> same here. +[21:10:30] <dilfridge> it's true that the utilities are easier to port and test, but the basic problem is the same +[21:10:32] <jlec> I think explicit stating compatibility is a good thing +[21:11:03] <jlec> Same as blocking multiple sourcing. But that's another story +[21:11:08] <ulm> when there's nothing EAPI dependent then there's no need for a conditional :) +[21:11:17] *** Joins: rich0_ (~quassel@gentoo/developer/rich0) +[21:11:17] *** ChanServ sets mode: +o rich0_ +[21:11:23] <WilliamH> ulm: that's true too. +[21:11:30] <jlec> The question is, is this something we need to enforce or should we rather suggest QA come up with something first? +[21:11:39] <dilfridge> ulm: do you know that a future eapi won't change that? +[21:11:47] *** stanley is now known as sam_c +[21:12:03] <ulm> dilfridge: like using something other than bash? +[21:12:07] <K_F> jlec: I'm not aware of an explicit policy on it at the time being +[21:12:21] <WilliamH> dilfridge: no, but we don't know that it will either. +[21:12:26] <dilfridge> heh, not that extreme, but... +[21:12:30] <K_F> jlec: but you're proposing we ask qa to come up with one? +[21:12:42] *** Quits: rich0 (~quassel@gentoo/developer/rich0) (Ping timeout: 244 seconds) +[21:12:47] <dilfridge> https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/systemd.eclass#n29 +[21:13:01] *** rich0_ is now known as rich0 +[21:13:06] <rich0> sorry, freenode server went down I think +[21:13:07] <dilfridge> ^ we can always just recommend that this block goes everywhere if there's not something similar already +[21:13:26] <dilfridge> if the eclass is trivial, the block is trivial to extend +[21:13:27] <K_F> dilfridge: yup, that is what is proposed +[21:13:52] <jlec> K_F: In the end it is a qa thing. They should come up with a way of enforcing it or not. We can ultimately vote on that +[21:14:11] <K_F> jlec: ah, re enforcement, yes, I agree, that is qa +[21:14:12] <WilliamH> Again though, I'm not sure it is necessary if the eclass doesn't contain anything that is eapi dependent. +[21:14:13] <jlec> dilfridge: makes sense. +[21:14:26] * WilliamH thinks it should be left to the maintainers +[21:14:36] <jlec> WilliamH: you don't know if that changes for newer eclasses. +[21:14:38] * ulm agrees with WilliamH +[21:14:39] <jlec> eh +[21:14:41] <jlec> EAPI +[21:14:41] <WilliamH> They will know best whether their eclasses contain eapi dependent code. +[21:14:53] <K_F> WilliamH: a consistent policy helps other developers +[21:14:56] <jlec> EAPI also means bash versions eg +[21:15:12] <jlec> there you might come into strange problems +[21:15:18] <K_F> WilliamH: and you don't really know if something breaks down the road in the environment (such as bash version backwards incompatibility) +[21:15:36] <ulm> jlec: if you argue along these lines then you cannot guarantee that even the EAPI test will work +[21:15:41] <jlec> Better explicitly state compatibility instead of waiting if it might break +[21:15:49] <ulm> because sourcing of the eclass may already fail +[21:16:05] * WilliamH agrees with ulm, leave it to maintainers. +[21:16:07] <jlec> yeah sure +[21:16:24] <jlec> so we should better encode the EAPI in the extension +[21:16:25] *** sam_c is now known as cmpct +[21:16:30] <jlec> :D +[21:16:31] <dilfridge> so let's not try to solve all eclass problems and world peace in one go +[21:16:36] <rich0> HOw will they know if anything is EAPI-dependent? +[21:16:40] <rich0> Since future EAPIs aren't written +[21:16:52] <K_F> WilliamH: the issue is we're leaving it to the wrong maintainers, now package maintainers needs to review it and consider it, instead of eclass maintainers having to mark it explicitly +[21:16:54] * WilliamH sigh +[21:16:55] *** Quits: cmpct (~stanley@unaffiliated/stanley) (Changing host) +[21:16:55] *** Joins: cmpct (~stanley@unaffiliated/cmpct) +[21:16:58] * jlec agrees with rich0 here +[21:17:01] <rich0> I'm in favor of requiring all eclasses die by default +[21:17:22] * WilliamH is against it +[21:17:31] <jlec> Should we vote on something here today? +[21:17:38] <WilliamH> no +[21:17:44] <dilfridge> I suppose we want to vote at most on a "recommendation", right? +[21:17:47] *** cmpct is now known as sam_c +[21:17:48] <K_F> jlec: it depends on whether we feel the topic is sufficiently discussed +[21:17:52] <dilfridge> Not on a "requirement"? +[21:17:54] <jlec> yes recommandation +[21:18:02] <dilfridge> then it really doesnt matter +[21:18:08] <K_F> dilfridge: that might make it more difficult for qa to have a policy +[21:18:13] <dilfridge> because in the end it's down to qa and maintainer +[21:18:18] <rich0> If PMS every breaks sourcing compatibility then that would have to be built into PMS anyway. That's an old discussion +[21:18:25] <dilfridge> well qa can always set policies if they want +[21:18:42] <dilfridge> it's not as if any qa policy has to be decided by the council beforehand +[21:18:53] <jlec> Did we saw significant breakage because of this? If not, I think QA should officially approach us for the vote if they see need to enforce it. +[21:19:15] * WilliamH agrees, I haven't seen any major breakage over this +[21:19:17] <rich0> Ultimately it is up to package maintainers to determine if the eclass they use works with the EAPI they use. +[21:19:27] <rich0> How many maintainers actually read the eclass source to check? +[21:19:30] <rich0> They just assume it works. +[21:19:32] <K_F> jlec: most recently get_libdir for EAPI 6, but the issue is it stops gating forward upgrades that might put restrictions on what changes can be done in EAPIs +[21:19:34] <rich0> As they should. +[21:19:47] <K_F> rich0: exactly +[21:19:48] <rich0> The issue is subtle breakage, not failure to ever build. +[21:20:11] <rich0> Thats why you always version ABIs. +[21:20:23] * WilliamH isn't interested in any requirements at the council level for this. +[21:20:40] <ulm> I'm against fixing things that aren't broken +[21:20:46] <K_F> it is broken +[21:20:50] <rich0> I'm not necessarily looking for a decision here. In any case, QA has my endorsement if they want to make this happen. +[21:21:04] <jlec> mine too +[21:21:13] <K_F> and we're putting unnecessary responsibility on package maintainers to need to review every eclass they try to use +[21:21:22] <jlec> !proj qa +[21:21:23] <willikins> jlec: (qa@gentoo.org) creffett, mgorny, mrueg, patrick, pinkbyte, tommy, ulm, williamh, zerochaos, zlogene +[21:21:25] <K_F> and understand the ramifications +[21:21:32] <jlec> Please give this a thought +[21:22:14] <jlec> We mostly leave it to you and will continue the discussion in case you officially approach us +[21:22:30] <WilliamH> K_F: So what about the defacto requirements to use eclasses for certain things? +[21:22:40] <K_F> WilliamH: such as? +[21:22:56] <ulm> the problem with EAPI 6 was rather that it took considerable time until the major eclasses gained support +[21:23:05] <ulm> but not major breakage +[21:23:37] <K_F> ulm: that depends on the changes that are being done, though +[21:23:49] <rich0> Probably because breakage was obvious enough to be noticed by maintainers +[21:24:04] <rich0> It isn't major breakage that is the issue, but intermittent / minor stuff +[21:24:10] * WilliamH is not going to support a blanket requirement for eclasses. +[21:25:06] <jlec> Any more need for discussion now? +[21:25:06] <WilliamH> Unless maintainers have the option of moving away from eclasses when they lag behind with adding the new eapi +[21:25:32] <K_F> WilliamH: there is no requirement to use eclasses per se, but I fail to see what issue you're trying to address +[21:25:38] <rich0> If an eclass actually works with a more recent eapi they can just update the test. +[21:25:48] <K_F> the ultimate goal is a stable, productive end-user environment +[21:25:51] <rich0> If it doesn't work, then they shouldn't be using it, test or not. +[21:26:16] <rich0> Just right now we blame individual package maintainers for not doing code review on every eclass they use. +[21:27:49] <ulm> that EAPI test block is the de-facto standard in any case +[21:27:54] <ulm> which doesn't mean that we must add it to all eclasses, even if they're shell function libraries effectively +[21:28:14] <WilliamH> K_F: No there's not, but you would get dinged for example if you wrote your own python ebuild without the eclasses. +[21:28:16] <K_F> ulm: it being a de-facto standard should only be an argument to make it de jure +[21:28:46] <ulm> K_F: yeah, where it makes sense +[21:28:48] <WilliamH> If I rewrote the pybugz ebuild to not respect the python eclasses I would probably get called out by qa. +[21:29:46] <WilliamH> Or if I wrote a gnome-based ebuild that did not use their eclasses... +[21:29:57] <K_F> ulm: if only functionality, shouldn't updating the catch block be trivial so it is a moot issue ? +[21:30:24] <K_F> i.e it won't keep updates back in practice, just requires the eclass maintainer to state that it will work for new EAPI anyways +[21:31:03] <WilliamH> Actually there's a problem with that eapi test in systemd thinking about it. +[21:31:22] <WilliamH> line 29 should just say case "$EAPI" in +[21:31:32] <WilliamH> or maybe even +[21:31:35] <WilliamH> case $EAPI in +[21:31:50] <WilliamH> but that's a side note to this discussion I guess. +[21:32:12] <ulm> hm? ${EAPI:-0} is the standard expression there +[21:32:25] <ulm> because "0" and "" are equivalent +[21:32:27] <WilliamH> ulm: eapi could be a string. +[21:32:46] <WilliamH> ulm: EAPI=my-cool-eapi +[21:32:47] <K_F> WilliamH: ? +[21:32:49] <jlec> No need for the :-0 +[21:32:57] <jlec> because "" would match * +[21:32:59] <ulm> WilliamH: yes, but why would that be a problem +[21:33:15] <WilliamH> EAPI=my-cool-eapi +[21:33:23] <WilliamH> EAPI=more-cool-stuff +[21:33:35] <WilliamH> would both be m in that expression +[21:34:03] <ulm> `${PARAMETER:-WORD}' If PARAMETER is unset or null, the expansion of WORD is substituted. Otherwise, the value of PARAMETER is substituted. +[21:34:21] <WilliamH> ah ok... nvm +[21:34:21] <K_F> WilliamH: its a default assignment +[21:34:40] <jlec> Are we good here? +[21:34:52] <WilliamH> yes, I guess, I don't support a hard requirement though. +[21:35:11] <jlec> 3) Bugs with council participation[1] +[21:35:11] <jlec> 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=3253044&query_format=advanced +[21:35:17] <rich0> I think we're all on record :) +[21:35:35] <K_F> jlec: you'll have to write the summary for it, so up to you I guess. +[21:36:24] <jlec> K_F: "There were discussion, but no agreement. Generally no requirement for actions." +[21:36:26] <jlec> :) +[21:36:46] <WilliamH> jlec: lgtm +[21:36:52] <K_F> we don't know if there is agreement without a vote +[21:36:57] <jlec> dilfridge: summaries? +[21:37:06] <dilfridge> yeah I know... +[21:37:16] <jlec> K_F: the tendency was 50:50 +[21:37:19] <dilfridge> one is still missing I think +[21:37:51] <K_F> bug 571490 +[21:37:54] <willikins> K_F: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Documentation, Project-specific documentation; CONF; mgorny:council +[21:38:09] <jlec> Any actions to take on the games team bugs? I cannot remember what we decided last time. +[21:38:44] <ulm> kill games.eclass with fire, IIRC +[21:38:53] <rich0> Yup, anybody who wants to can do it. +[21:39:04] <rich0> Just need somebody who cares enough to do it. :) +[21:39:10] <WilliamH> Yes, and it is being worked on iirc +[21:39:10] <jlec> Okay, so it is up to the community +[21:39:14] <jlec> bug 590972 +[21:39:16] <willikins> jlec: https://bugs.gentoo.org/590972 "repoman should prevent people from adding a new package with a metadata.xml pointing to maintained-needed directly"; Portage Development, Repoman; CONF; pacho:dev-portage +[21:39:36] <jlec> Done from our side, up to the PM maintainers +[21:39:41] <WilliamH> Right. +[21:39:42] <jlec> agreed? +[21:39:48] <ulm> yes +[21:39:48] <K_F> jlec: yeah, done from our side +[21:40:08] <dilfridge> yes +[21:40:22] <jlec> Where are we with the changelogs? +[21:40:27] <jlec> bug 565566 +[21:40:29] <willikins> jlec: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs +[21:40:30] <WilliamH> Waiting for infra +[21:40:36] <dilfridge> well, waiting for infra +[21:40:44] <dilfridge> infra is waiting for something not entirely related +[21:40:53] <WilliamH> Right. +[21:41:00] <jlec> Should we take actions here? +[21:41:05] <jlec> Or just ping them again? +[21:41:33] <WilliamH> The only action we can take is tell them that what they are waiting for is unrelated and ask them to remove the changelogs. +[21:41:39] <dilfridge> well we could ask them to just drop the changelogs, while keeping working on the separate repo for them +[21:41:56] <ulm> the two actions we decided on in the April meeting can be taken immediately +[21:41:59] * WilliamH thinks we should +[21:42:11] <ulm> and the separate rsync module can be provided later +[21:42:29] <K_F> ulm: agreed +[21:42:32] <dilfridge> ++ +[21:42:33] <jlec> Okay, I will add something to the bug +[21:42:45] <jlec> 4) Open floor +[21:42:46] <ulm> whenever where will be the perfect cvs-git conversion (TM) +[21:42:47] <dilfridge> should we reinforce it with a vote? +[21:42:56] * WilliamH thinks so +[21:43:13] <ulm> +1 +[21:43:13] <jlec> Would that change something? +[21:43:23] <K_F> dilfridge: as in council requesting infra to remove changelogs specificially +[21:43:23] <dilfridge> it would reinforce our viewpoint +[21:43:24] <jlec> at least we reacted +[21:43:46] <jlec> Let me quickly read the points ulm referred to +[21:43:53] <ulm> https://bugs.gentoo.org/show_bug.cgi?id=565566#c10 +[21:44:07] * WilliamH reads +[21:44:34] <K_F> dilfridge: as a procedural point, any issue that should be voted on should likely be part of the regular agenda +[21:44:45] <dilfridge> council requests infra to drop changelogs from rsync and not wait for a good cvs-to-git conversion first +[21:44:52] <dilfridge> it is on the regular agenda +[21:45:24] <ulm> dilfridge: or alternatively, change their ordering to newest first +[21:45:50] <ulm> but yes, it will be more likely dropping them +[21:46:02] <dilfridge> wfm, but I fear even if that works, we will end up dropping them due to file size at some poing +[21:46:08] <jlec> I would rather go for, +[21:46:08] <dilfridge> pint +[21:46:12] <dilfridge> point +[21:46:41] <WilliamH> We said we were going to kill changelogs in a meeting long before the conversion, so they should be dropped. +[21:46:44] * dilfridge hopes this helps infra to get the manifest issues under control +[21:47:15] <K_F> dilfridge: I don't see how it would be related to that +[21:47:37] <WilliamH> K_F: it is a bug assigned to us, so it is part of the agenda that way. +[21:47:47] <jlec> The council request infra to respect the decision made in meeting 20160410 and either drop the ChangeLogs or fix the ordering without any further delays. +[21:48:07] <WilliamH> jlec: wait a sec, there is another meeting where we said just drop them. +[21:48:19] <WilliamH> jlec: an older meeting +[21:48:27] <WilliamH> jlec: it was unanimous back then. +[21:48:42] <dilfridge> K_F: it should simplify the git-to-rsync conversion +[21:48:50] <ulm> WilliamH: we wanted to drop them in rsync +[21:49:00] <jlec> Then take that one. I think back referring and explicitly asking for action is better +[21:49:09] <WilliamH> wait a sec let me find it. +[21:49:20] <ulm> WilliamH: that doesn't prevent anyone from providing generated ChangeLogs elsewhere +[21:49:24] <K_F> dilfridge: yes, but the issues we've been having have been related to other issues as far as I'm aware, mostly related to developer time and use of mtime on staging area +[21:49:29] <K_F> dilfridge: not a bottleneck issue per se +[21:49:53] <WilliamH> ulm: no, it doesn't that is the separate project infra wants to do. +[21:50:37] <jlec> There are summaries missing for meetings +[21:50:45] <jlec> June and July +[21:50:53] <ulm> WilliamH: 20141014 meeting +[21:51:05] <jlec> ulm your meetings +[21:51:05] <ulm> "do we need to continue to create new ChangeLog entries once we're operating in git?" +[21:51:08] <dilfridge> sigh... so far noone really managed to explain to me what the real problem is (since git usually does not do any mtime fiddling, so rsync should figure out which files changed just fine...) +[21:51:09] <ulm> No: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh +[21:51:16] <jlec> and blueness +[21:51:38] <K_F> dilfridge: not if you don't do checksum verification of files but simple method +[21:51:48] <K_F> dilfridge: that for large scale rollouts makes sense +[21:52:15] <K_F> due to resource considerations +[21:52:16] <dilfridge> K_F: that makes no sense +[21:52:29] <dilfridge> even without checksums, file changed -> newer mtime -> transfer +[21:52:32] <rich0> I switched to git syncing ages ago... +[21:52:48] <rich0> It seems silly that we refer people to use rsync and then have it break randomly though... +[21:53:07] <prometheanfire> git won't scale to all our users though (to my knowlege) +[21:53:15] <dilfridge> git afaik does not touch mtime. so file changed -> newer mtime somewhere when git working tree is modified -> rsync finds modified file +[21:53:15] <jlec> Let's focus on the ChangeLog vote please +[21:53:17] <K_F> dilfridge: not if it changes to a mtime in the past +[21:53:20] <rich0> prometheanfire: just mirror it +[21:53:29] <rich0> And I'm sure github or whatever can handle our user base. +[21:53:52] <dilfridge> K_F: git does not touch mtime. the kernel does when git modifies the file. and then it depends on the clock of the infra box, not on commit etc +[21:53:54] <prometheanfire> rich0: is git signing verification done? +[21:53:55] <K_F> rich0: you have issues with OpenPGP verification if switching user base to git as well +[21:54:07] <prometheanfire> that's why I'm still on webrsync +[21:54:18] <rich0> I'm not sure what verification git does by default. +[21:54:19] <K_F> as it will need to match individual developer signatures and not release engineering keys that is signing it in staging area +[21:54:31] <prometheanfire> K_F: ++ +[21:54:32] <K_F> which causes issues for revocation and developer retirement +[21:54:43] <rich0> Beyond the, ugh, sha1s +[21:54:44] <dilfridge> K_F: so that process should be completely independent of commit times and signature times. why it is is a big mystery. +[21:55:00] <jlec> hello +[21:55:04] <jlec> ChangeLogs +[21:55:08] <dilfridge> :) +[21:55:15] * dilfridge says drop'em +[21:55:23] <jlec> What do we like to vote on? +[21:55:25] * dilfridge gets a drink +[21:55:32] * prometheanfire wants to drop them +[21:55:35] * WilliamH says drop'em +[21:55:40] <prometheanfire> iirc, infra side they've just been a pain +[21:55:44] <ulm> yes, drop them +[21:55:52] <prometheanfire> but I don't get a vote :D +[21:55:54] <rich0> I think I'm already on record back when dberkholz was still on council :) +[21:56:10] <WilliamH> Drop the changelogs from rsync. +[21:56:50] <jlec> The council requests infra to respect multiple votes to drop ChangeLogs and act without any further delay. +[21:56:58] <jlec> Does that work? +[21:57:01] <K_F> no +[21:57:16] <K_F> the requests have given the ability to drop,not been a requirement to drop +[21:57:34] <leio> They provide actual user value that you can't get easily (like emerge --changelog easily if it weren't broken) without using git, and we don't advertise git as the thing to use for that in any way (yet); I don't get a vote either. +[21:57:49] <K_F> the vote we have from 20160410 is that "If ChangeLog files are provided, they must be in the order of +[21:57:52] <K_F> newest entries first" +[21:58:19] <jlec> K_F: Please suggest something to vote on. +[21:58:51] <K_F> jlec: I don't like voting on things not in the scheduled agenda as a matter of principe :) +[21:58:57] <ulm> jlec: I think your wording from above (19:47) was just fine +[21:59:09] <WilliamH> repaste that again please? +[21:59:14] <WilliamH> re-paste * +[21:59:28] <K_F> but yeah, the former one should be ok +[21:59:32] <jlec> The council request infra to respect the decision made in meeting 20160410 and either drop the ChangeLogs or fix the ordering without any further delays. +[21:59:45] <rich0> I suggest we talk to them before we toss edicts at them. +[21:59:51] <K_F> but I'm not sure if that requires a vote to begin with +[21:59:59] <K_F> as it is referring to a vote on subject already had +[22:00:15] <dilfridge> The council asks infra to respect the decision made in meeting 20160410 and either drop the ChangeLogs or fix the ordering +[22:00:16] <rich0> Why not just start a dicussion, email/etc? +[22:00:21] <K_F> so yeah, that sounds like starting a discussion +[22:00:38] <ulm> rich0: well, there was no reply to my pinging them on the bug +[22:00:38] <rich0> In general we try not to dictate that people work on things. +[22:00:50] * WilliamH agrees with rich0 +[22:00:59] <rich0> Do we really think voting on it will change anything, besides ticking people off? +[22:00:59] <dilfridge> how much work is dropping them? +[22:01:02] <WilliamH> I think the problem is, there has been no status or update in a long time. +[22:01:09] <rich0> Well, dock their pay then! +[22:01:17] <dilfridge> hrhr +[22:01:28] <ulm> *sigh* +[22:01:31] <WilliamH> dilfridge: heh, that's part of the problem, we don't know. +[22:02:03] <rich0> In any case, I think we're all aligned on what the preferred solution is, and that we need to see what can be done to move it along. +[22:02:18] <prometheanfire> well, I wasn't aware we needed to do anything (infra) +[22:02:18] <WilliamH> I don't want to wait another 10 years for it to be fixed. :p +[22:02:21] <rich0> I don't think we need more resolutions. Does somebody want to volunteer to contact them? +[22:02:36] <dilfridge> You just volunteered. :P +[22:02:43] <leio> Having them in wrong order is more value than not having them (can still tail them, plus there were portage patches to figure out --changelog in that order, maybe even included), except for those that don't want the rsync traffic for them (for which a separate changelog rsync "overlay" has been mentioned as a future possibility) +[22:02:47] <WilliamH> I think we should also try to figure out why we can't move everyone to git syncing. +[22:03:06] <dilfridge> leio: the other related problem is that file sizes are now exploding +[22:03:07] <rich0> Yeah, I just volunteered for the last take the lead task. :) +[22:03:08] <prometheanfire> imho, use git if you want changelogs +[22:03:17] <rich0> I think that satisfies my obligation for a while. :) +[22:03:20] <K_F> WilliamH: I provided some rationale for that above for OpenPGP signatures +[22:03:20] <leio> that's a separate problem with an easy technical solution. +[22:03:22] <jlec> good, so let's reschedule until next meeting and wait what comes out of the ping +[22:03:34] <dilfridge> rich0: point taken, and I feel with you. +[22:03:43] <leio> (per-year ChangeLogs; dropping some years old at some point if needed) +[22:04:01] <jlec> rich0++ +[22:04:30] <prometheanfire> so, are people ok if we (infra) start working on removing changelogs from rsync/git? +[22:04:39] <prometheanfire> is that the ask? +[22:04:45] <K_F> prometheanfire: yes, that is clear in 20160410 summary +[22:04:47] <dilfridge> I think from council, yes +[22:04:53] <ulm> +1 +[22:04:54] <prometheanfire> k +[22:05:06] <jlec> So now +[22:05:07] <jlec> 4) Open floor +[22:05:14] <prometheanfire> I'll bug robbat2 or myself to work on it +[22:05:22] <K_F> prometheanfire: https://bugs.gentoo.org/show_bug.cgi?id=565566#c10 (1st vote) +[22:05:24] <jlec> Community, anything you like to bring forward? +[22:07:47] <jlec> If there is nothing, I will close the meeting for today +[22:07:55] <jlec> Thanks for participating. +[22:08:27] <ulm> jlec: thank you for chairing +[22:08:46] <jlec> I am sorry for being so pushy. :) diff --git a/meeting-logs/20160911.txt.asc b/meeting-logs/20160911.txt.asc new file mode 100644 index 0000000..9126fe5 --- /dev/null +++ b/meeting-logs/20160911.txt.asc @@ -0,0 +1,19 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG/MacGPG2 v2.0 + +iQJ8BAABCgBmBQJYhJ+lXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF +OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi/DAQAITFgwWRfQ88Bp745UiUTwae +QmjgB+6tse1t40JFf6sjtnl83zj5T8MrC5ZJCQDoufM1a2VjomWXwgL6Ox4Pm/Rd +oMMXfjOUgVXgJLRTkYdzd0MOTlwZ389gScZNDfPADaGyoG4u18GfCF/qHKwy29VK +x9RF0hCu8w1qZ6ibwpojrIfvBFO8pJwP6BidxuWDUW0lRWTooZ84HczSXGDGrLjI +2CH92AlML1CvAt+dM02C+h8CGTn4dJHyLFbGLhxmegWS4k6FJOUQlfz182Nfmv8z +IVeccsd5PH8bMCdZ9l3jtrRA7vMDxjczGIIIyvcq6piOnwU6swmYfMbXVoaDmBlL +0gZ4KBSGLypb2zbhRKSUVqjel8rrb8MDnMSHAGlRyIkz1LELRaQE8MOIN1YBbzMu +6V2Uv8VFwkRX+y7hdiFnDr3OmgEWwF2PFVjMj0oNYBXatD/WllF5Rj+vFpRL3ct1 +My+objugEnrVIh56leA3AyP72lKfrQOAOXyavES1NLfcS47RL8VOA/KCeDiJYCMD +FPXMgQfb5WGtl2LnAuweRzlmOFCaTXMfTihephwi3FagxC1Cv31rKB+KJh4tbIDg +Y2KuOJkEEKcToSFGJiKJaWHKmoB+YnnvGCDmWKo3FLicn3oh7kf+MhsboyJpbQwM +dJOs8JuKHV4jQxAS4m12 +=n12b +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20161009-summary.txt b/meeting-logs/20161009-summary.txt new file mode 100644 index 0000000..f2993cb --- /dev/null +++ b/meeting-logs/20161009-summary.txt @@ -0,0 +1,34 @@ +Summary of Gentoo council meeting 11 September 2016 + +Agenda +====== + +1) Roll call +3) Bugs with council participation +4) Open floor + + +Roll call +========= +Present: dilfridge, jlec, k_f, rich0, ulm, williamh, blueness + + +Bugs with council participation +=============================== + +565566: ulm followed this up with robbat2. robbat2 is working on the historical git +conversion, but no ETA for the fix yet. council invites Infra to give some more +insights at the next meeting. + + +Open floor +========== + +WilliamH wanted the council discuss the availability of the graveyard overlay +through layman. The overlay contains packages dropped out from the main +gentoo repository due to lastriting. WilliamH wanted to know whether placing +potentially widely used, but by upstream deprecated, versions of apps, +e.g. grub:0, should live there. There was a general concern about the additional +amount of insecure and broken ebuilds to the user with this approach and the +council suggested to better lastrite those version with longer lead times, +rather then pointing users to the overlay. diff --git a/meeting-logs/20161009-summary.txt.asc b/meeting-logs/20161009-summary.txt.asc new file mode 100644 index 0000000..7423900 --- /dev/null +++ b/meeting-logs/20161009-summary.txt.asc @@ -0,0 +1,19 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG/MacGPG2 v2.0 + +iQJ8BAABCgBmBQJYhKVkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF +OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmihI4QAI/fCPDhydNQNaABLVkVRwfW +Y7mADs2eNn9cf/Z/szDkc1jiMb/01k+jK4cxp3J6UfkHol5EYAp8HcVmPylNHLqN +wdlR0eEyRkkKfmhaQy8yd/poZ2Wg26grr6RZPQ+LWiJQv/Pol/yFVYQqRxHveJ9c +Yvg/Ha7y43ewS16b7rF1yLlcEHD4Q6ADO0tPCT+fz75JE38zrvtRhwyEBYxOPTo2 +wsoM8/JOgqnPQahFhQ2zBExvoHSB/vULDQr+FK78fKR9nyJhX6e+/UtZ4K4Xn0Ta +D0C4QjKwK8BMyQTzEGwS2EtuHlnieV3YKhSMHXWavPBLkyT6L2e+NEGIuXiB7MTi +SxU326QBRLPViBhd/gDc+MeaUk72gv3d3LL6nZux4Vbid+O+J/gVIA9mROMrBrAE +wjFhhVtPnu4YWGEhdPhfNh8gUu4q1tJxtEut2BwYJNCIKIUHlKn860wJwtPt3rkK +esdaaIPEsbZ0OzC3SPRmLJGgx9AxGd2j1QkZLGNkK7N3/FjRZ5qcyL9o7mHmTABL +ujxC8WcBQg/+xxH1lNf2Z7hUBumc/5esvwk8v6AgQHIrdsehxkXdzOtrrwUR+IBI +GcLKdf9uzEATwutoM+faiQaiDV3C4Sh3dFae+juk3P93sikwjuso045Qc1QofKSM +tL1EeEF74JmiiQqNTF3n +=E4N9 +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20161009.txt b/meeting-logs/20161009.txt new file mode 100644 index 0000000..4d11386 --- /dev/null +++ b/meeting-logs/20161009.txt @@ -0,0 +1,194 @@ +[21:00:23] <jlec> !proj council +[21:00:23] <willikins> (council@gentoo.org) blueness, dilfridge, jlec, k_f, rich0, ulm, williamh +[21:00:33] * rich0 here +[21:00:35] <jlec> Shall we wait for K_F +[21:00:36] <jlec> ? +[21:00:43] <blueness> meeting in 10 mins +[21:01:07] <rich0> I suggest we proceed but wait at the end or if anything exciting comes up. We can probably grind through some of the boring stuff first. +[21:01:41] *** Joins: ulm_ (~ulm@gentoo/developer/ulm) +[21:01:41] *** ChanServ sets mode: +o ulm_ +[21:02:05] * blueness here +[21:02:06] <blueness> agreed +[21:02:07] <blueness> so who’s here? just me, rich0 and jlec ? +[21:02:13] * WilliamH is here +[21:02:20] * ulm_ here +[21:02:32] * dilfridge here +[21:02:51] * jlec here +[21:03:13] * rich0 here +[21:03:20] <jlec> Only K_F is missing +[21:03:38] <jlec> 2) Bugs with council participation[1] +[21:03:40] <ulm_> he's still on his way back from Prague, I guess +[21:04:02] <jlec> or did I miss something? +[21:04:11] <NeddySeagoon> his flight is delayed +[21:04:14] <jlec> Nobody replied to the call for topics, correct? +[21:04:33] <jlec> 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=3253044&query_format=advanced +[21:05:22] <blueness> jlec: i didn’t see anything +[21:05:44] <jlec> bug 565566 +[21:05:46] <willikins> jlec: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs +[21:05:52] <jlec> That's the only interesting one +[21:06:07] <jlec> Any progress? If not, what actions should we take +[21:06:17] <ulm_> I shortly talked to robbat2 yesterday +[21:06:40] <ulm_> IIUC he's working on the historical git conversion +[21:06:57] <WilliamH> I saw some conversation about another issue wrt the changelogs recently, but I'm not sure what the deal was? +[21:07:10] <K_F> sorry about delay, online now +[21:07:19] <jlec> hi K_F +[21:07:23] <jlec> we just started +[21:07:29] <jlec> ulm: ETA? +[21:07:29] <WilliamH> K_F: the only topic is open bugs. +[21:07:41] <K_F> i added missing summary one earlier +[21:07:52] <K_F> and did a crossreference/see also on one +[21:07:56] <ulm_> jlec: I don't know +[21:08:22] <jlec> So do we need to do something? +[21:08:32] <K_F> seems changelogs are causing some pf the issues for manifest generation +[21:09:49] <jlec> What do you think, again a suggestion to infra or more this time? +[21:09:52] <blueness> i think we need infra’s input on this +[21:10:09] * WilliamH is looking through meeting logs +[21:10:27] <rich0> Do we want to send them an email, or ask them to show up to the next meeting (or likely both?). +[21:10:40] <ulm_> +1 +[21:10:47] <K_F> rich0: makes sense if the issue isnt resolved by then +[21:10:52] <jlec> good idea, either having resolved this issue or tell us what they are planing. +[21:11:04] <jlec> okay, I will send them a mial +[21:11:16] <rich0> K_F: well, we can always invite ask them to show up, and tell them that if it is resolved by then they don't have to. +[21:11:24] <K_F> yup +[21:11:34] <rich0> It just feels like this is a pretty serious issue for rsync users, and it is dragging. +[21:11:59] <dilfridge> it just hit >5 x11 packages right now +[21:12:04] <jlec> it is and it takes to long time +[21:12:16] <dilfridge> there's a thread about it on the gentoo-user mailing list +[21:12:58] <jlec> SO do we agree inviting them is enoigh for now? +[21:13:29] <rich0> I'd start an email discussion in the meantime. No sense idling until the next meeting. +[21:13:39] <K_F> imho we should be more proactive +[21:13:59] <rich0> And we can always trade messages here or in #-infra +[21:14:02] <K_F> work on it between meetings +[21:14:23] <blueness> jlec: yes +[21:14:30] <K_F> rich0++ +[21:15:01] <dilfridge> so maybe we should arrange a time when some of us discuss this with the infra people? +[21:15:17] <K_F> or email +[21:15:21] <dilfridge> like, in real-time instead of via delayed responses +[21:15:32] <blueness> email, infra is very loosely organized +[21:15:40] <blueness> i’m with infra, but i don’t know anything about this system +[21:15:44] <blueness> i just do the blogs +[21:16:21] <jlec> okay, I will send a mail and let's see how it goes. +[21:16:47] <jlec> Or ulm do you like ot go ahead, as you already contacted robbat2 +[21:16:49] <jlec> ? +[21:17:16] <rich0> Suggest email to kick it off. We can always tell them to feel free to ping us here, but it will be scattered relatime chat with various groups of us, which I think is fine to keep it moving. +[21:17:25] <rich0> I think we're mostly aligned on direction anyway. +[21:17:32] <jlec> All other bugs have same status as last month. Anybody likes to discuss one of them? +[21:17:53] <ulm_> jlec: no, I'm fine with you writing the e-mail +[21:18:13] <jlec> good +[21:18:16] <jlec> next +[21:18:18] <jlec> 3) Open floor +[21:18:28] <jlec> Community, anything you like ot bring forward? +[21:18:48] <WilliamH> Ok, I have a general question, not something to vote on, I'm more looking for opinions. +[21:19:01] <WilliamH> The graveyard overlay is now in layman. +[21:19:25] <WilliamH> It was originally supposed to be a place where things can go when they are lastrited. +[21:19:50] <WilliamH> Is it reasonable to have shorter lastrites periods if the package is going to the overlay? +[21:20:04] <ulm_> WilliamH: why is it in layman, in the first place? +[21:20:12] <K_F> not really +[21:20:17] <dilfridge> no +[21:20:28] <WilliamH> ulm_: I put it there, so people can install packages from there if they want them. it is not officially supported. +[21:20:29] <dilfridge> also, if it is in layman, who is the responsible contact? +[21:20:31] <rich0> WilliamH: I don't think we should be in a rush to lastrite unless it is holding up something critical. +[21:20:34] <ulm_> there must be many packages e.g. with security issues +[21:20:38] <rich0> 30 days isn't that long as it is. +[21:21:14] <WilliamH> should it not be in layman? I can remove it if that's the case. +[21:21:15] <ulm_> and I agree that this shouldn't influence the last-rites workflow +[21:21:49] <WilliamH> rich0: ok, 30 days is reasonable. +[21:21:52] <jlec> I have a bad feeling with the overlay being in layman +[21:22:11] <WilliamH> jlec: how so? +[21:22:17] <jlec> packages get list rited because they have unfixed security problems or are broken +[21:22:26] <jlec> otherwise they don't get lastrited +[21:22:36] <jlec> We shouldn't officially make them available +[21:22:38] <Soap__> jlec: grub:0 is borderline broken +[21:22:40] <blueness> jlec: can’t overlays be marked as unstable? +[21:22:55] <WilliamH> blueness: they can be marked unofficial. +[21:23:06] <K_F> blueness: iirc there isnt an official support of overlays, all are experimental by default +[21:23:28] <WilliamH> blueness: K_F is correct. +[21:23:51] <ulm_> at least the overlay is labelled as "experimental" and "unofficial" +[21:24:17] <K_F> i'm fine with it being in layman +[21:24:22] <WilliamH> I wasn't going to bring up grub:0, but that is myspecific example, yes. +[21:24:24] <blueness> maybe we should add another catagory +[21:24:25] <blueness> mark an overlay as “dangerous" +[21:24:26] <blueness> do we have a GLEP that governs overlays? +[21:24:38] <K_F> its just convenience, no statement of support +[21:24:56] <kensington> an overlay certainly can be marked as official +[21:25:12] <WilliamH> blueness: k_f is correct. +[21:26:42] <ulm_> kensington: there are two predicates, quality and status +[21:26:54] <ulm_> status can be official or unofficial +[21:27:36] <ulm_> and for quality I find "core", "experimental", and "testing" +[21:27:49] <ulm_> not sure what the difference between the last two is +[21:28:22] <K_F> ulm_: i see semantic differences there, testing being higher expectatiom +[21:28:26] <veremitz> you might think 'testing' would work .. whereas experimental might not .. +[21:28:29] <dilfridge> we probably need another one "b0rken" +[21:28:42] <dilfridge> or "insecure" +[21:28:43] <WilliamH> The README in the overlay makes it pretty clear what is going on, but I may remove the comment about proxy-maint. +[21:29:40] * Soap__ git mv's 'dev-perl' to b0rken +[21:29:56] <WilliamH> The reason I activated the overlay is for the grub:0 users primarily. +[21:29:58] <dilfridge> heh +[21:30:19] <WilliamH> I want to put grub:0 in there. +[21:30:28] <WilliamH> rather than lastrite and forget about it. +[21:30:40] <WilliamH> So people can still get at it if they want and we can move on. +[21:30:54] <ulm_> WilliamH: the problem is that selecting that overlay will make tons of other crap visible to users +[21:30:58] <Soap__> also, last-riting applies to packages, not SLOTs, right? +[21:31:18] <kensington> Soap__: last-rite is a process, one can apply it to anything +[21:31:31] <WilliamH> Soap__: Sure, but go and talk to the reactionaries in Gentoo. +[21:31:40] <Soap__> kensington: oh, I thought it formally only applied to a CAT/PN +[21:31:41] <ulm_> Soap__: yeah, but for example we did last rites for Emacs slots in the past +[21:31:46] <WilliamH> Soap__: I would just remove it, but that would bring down some wrath. +[21:31:48] <NP-Completeass> Is it worth putting a */*::graveyard in package.mask in the overlay? that way users have to unmask anything they want from there? +[21:32:07] <K_F> ulm_: isnt that more an issue of overlay being in full visibility automatically when added, even for stable? I always mask them mulyself and selectively unmask it +[21:32:12] <kensington> Soap__: right, there's no requirement to last-rite a slot, but one can if they wish +[21:32:26] <rich0> imo the main use case for that overlay is people who haven't figured out git +[21:32:40] <rich0> Granted, finding removed stuff in git is a pita. +[21:32:42] <Soap__> kensington: given the gravity of the package, I sure do does apply here :) +[21:32:49] <ulm_> K_F: right, it might be an issue of bad default setting +[21:32:56] <Soap__> it* +[21:33:15] <WilliamH> rich0: you''re right, that's the main use case for it. +[21:33:39] *** NP-Completeass is now known as NP-Hardass +[21:33:55] <kensington> NP-Hardass: depends, I would think packages should only go in there for a reason, rather than adding every random crap +[21:33:57] <WilliamH> rich0: "git log sys-boot/grub" +[21:34:16] <WilliamH> rich0: shows you everything that happened to everything in that path. +[21:34:17] <rich0> WilliamH: does that work if sys-boot/grub isn't in the tree? +[21:34:31] <rich0> Does it work for a path that doesn't current exist? +[21:34:52] <veremitz> afaik no.. +[21:34:55] <WilliamH> rich0: I'm not sure. +[21:34:55] <ulm_> rich0: git log -- sys-boot/grub +[21:35:20] <ulm_> with the -- it will show removed files/dirs too +[21:35:21] <NP-Hardass> kensington: sure, but given the unsupported nature of the overlay, making it default manual intervention required would help sell this point +[21:35:22] <rich0> Well, that's a dealbreaker right there... :) +[21:35:30] <WilliamH> rich0: In this example I'm not talking about nuking sys-boot/grub +[21:35:57] <veremitz> WilliamH: that would be severely unpopular :P +[21:36:00] <Soap__> NP-Hardass: agreed, thats how it should be +[21:36:27] <WilliamH> veremitz: heh I'm just wanting to nuke grub:0 +[21:36:52] <NeddySeagoon> Do we want to teach users to get things out of git or maintain an overlay? +[21:37:13] <NP-Hardass> NeddySeagoon: ideally, both. +[21:37:21] <K_F> users needing to be thought that likely should stick to the supported software in main tree to begin with +[21:37:22] <veremitz> -_- +[21:37:36] <K_F> maintaining an overlay is more advanced use ahead of contributions and becoming a dev +[21:37:38] <WilliamH> NP-Hardass: the most efficient way would be to write up a wiki page on how to pull things out of git. +[21:37:41] <NP-Hardass> NeddySeagoon: Though, getting things from git, I did a writeup on using git as an equiv to the CVS attic on the dev ML a while back +[21:37:46] <NP-Hardass> WilliamH: ^^ +[21:38:40] <WilliamH> K_F: good point. +[21:38:50] <NeddySeagoon> NP-Hardass: I'll see if I can find that. I would find it useful anyway. Thatnk you +[21:39:13] <NP-Hardass> NeddySeagoon: np. As WilliamH said, would probably be useful to put it on the wiki +[21:39:37] <NeddySeagoon> NP-Hardass: maybe I'll do that if I can make it work +[21:40:23] <WilliamH> wrt grub:0, I wanted to apply lastrites because just removing it would be very unpopular. +[21:40:30] <WilliamH> Soap__: ^^ +[21:40:34] <jlec> WilliamH are you good? +[21:40:37] <veremitz> 90-day last-rites?! +[21:40:43] <Soap__> WilliamH: I am well aware ;) +[21:41:02] <WilliamH> veremitz: imo 30 or 60 is reasonable... +[21:41:04] <NP-Hardass> NeddySeagoon: https://archives.gentoo.org/gentoo-dev/message/305c431c84c39bc74b1077f0b395ce91 +[21:41:17] <NeddySeagoon> NP-Hardass: Thank you +[21:41:19] <WilliamH> jlec: Yes, I'm basically good. +[21:41:30] <jlec> fine +[21:41:37] <WilliamH> another informal question after the meeting closes. +[21:41:43] <WilliamH> so go ahead with the meeting. +[21:41:54] <jlec> So ig there is nothng else, Iwould like to close +[21:42:05] <jlec> anyone? +[21:42:49] <NP-Hardass> WilliamH: what are the conditions for which something enters graveyard? +[21:43:11] <K_F> just a PSA. the talks from miniconf in prague should be online now +[21:43:23] <K_F> so might be interesting for those that didnt participate +[21:43:35] <WilliamH> NP-Hardass: let's let the meeting go on, I'll answer after. +[21:43:40] <NP-Hardass> Sure +[21:43:47] <veremitz> K_F: is there a central location for that jazz? +[21:43:54] * jlec closes the meeting diff --git a/meeting-logs/20161009.txt.asc b/meeting-logs/20161009.txt.asc new file mode 100644 index 0000000..bd20d4f --- /dev/null +++ b/meeting-logs/20161009.txt.asc @@ -0,0 +1,19 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG/MacGPG2 v2.0 + +iQJ8BAABCgBmBQJYhKFzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF +OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiPkAP/RN1MtSrovmdDVFIA8vWJRY0 +gWiW3j8FCDwG8oPjagosM67IkDqzukR8TebWARXljhv0deAZd4FH8aq5SlvgK6ij +3JKHY+xamhcenSkRMFGtskRang24DJUQNzv8uQuQhWeKWvXAnzr+MPQmruIOM3G+ +kVRulleo2FIGplHCuEHjg4ufxfk43/jSkLw2fS3cV+2lEqFm11e02Ey0kW8JMbva +K5796lUIFwcNenICZjVbHONmREYzbNPrVPYB+MAzaadX6T7AA0fBMzy5aKhbdY3U +/LKevZ4l6gdB2wrimBz6490Jfb3g6kxlVCZRpokob7xAEEo8qKeiSeMvvvrxkh3u +PgljIkAm1VNZptQQaAcYa5GFBnu8khNStepxeEcuIJz8rpzFpA9sXgMXsZmuCC2O +roQnaFdNDo5jvAOoxnhV8yPKNCBSAIxZIqt5/dbMv4M0diTQiL9Pq7BBFBSH1M0g +4B+1GGuodtO8lYVqsene1vOiyAGH+isV4qlOspJ22AyjFPG+yUAT34Dk4xaPPIzg +N3M1JRz54VVyUxAyNc/ajWxf69v5VEcNyU6FGPjzy72gZO9cnPDHEADJ7nS9MvbR +2PBP7GIIzrgj0Rz+NxeucFGT+cloyxwHVP4tmfbB9g+gFvZk71VgTP2rZJ2mQCku +Vd6g0QY7yn/o0OeuDs4X +=UKL0 +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20161113-summary.txt b/meeting-logs/20161113-summary.txt new file mode 100644 index 0000000..4457197 --- /dev/null +++ b/meeting-logs/20161113-summary.txt @@ -0,0 +1,77 @@ +Summary of Gentoo council meeting 13 November 2016 + +Agenda +====== +1. Roll call +2. Stabilisation workflow [1] +3. Status of contributors (nominate Foundation liaison) [2] +4. Copyright matters [3] +5. Open bugs with council involvement +6. Open floor + + +Roll call +========= +Present: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + +Stabilisation workflow +====================== +Discussion in the stabilisation working group is in progress, see +the status report sent to the gentoo-project mailing list by K_F [4]. +An update to GLEP 40 and a change of the bugzilla workflow are likely +to be proposed. No council action to be taken, for the time being. + +Status of contributors +====================== +Prometheanfire suggested to start preliminary work on a reorganisation +of Gentoo, including preparation of GLEP and bylaw proposals. In the +discussion that followed it was asked if there is any problem that +needs solving. The option of associating with an umbrella organisation +(like SPI) was mentioned. No motion was voted upon, and the topic was +tabled for a later meeting. + +Copyright matters +================= +There is agreement that copyright issues are a task for the +foundation, therefore the council will not take any action. + +Open bugs with council involvement +================================== +- Bug 571490 "Missing summary for 20151025 council meeting", + bug 596678 "Missing log and summary for council meeting 2016-09-11": + dilfridge, blueness, and jlec are asked to complete the summaries + for the 2015-10-25, 2016-06-12, and 2016-09-11 meetings. + +- Bug 566498 "games.eclass: use of games group needs to be removed wrt + 20151011 Council meeting", + bug 574080 "games.eclass: Path customization needs to be removed wrt + 20151213 Council meeting", + bug 574082 "[Tracker] games.eclass deprecation", + bug 574952 "Extremely uncooperative behavior from games team": + Currently no council action required, therefore the council can be + removed from CC of all four bugs. + +- Bug 579460 "please make repoman ignore a missing "# $Id$" header line": + Implemented in repoman-2.3.0, but not yet in stable. Once this is + done, CVS headers can be removed as per 2014-10-14 council decision. + +- Bug 565566 "New ChangeLogs are in chronological order": + Action: K_F will ask infra for a status update. + Note added in proof: According to robbat2, ChangeLogs in the main + tree will be discontinued after 2016-11-15, as announced in [5]. + Ordering of entries will be reversed thereafter. + +Open floor +========== +- Dropping of stable keywords for additional architectures: + This should be proposed as a regular agenda item for a later + meeting, or alternatively be discussed in the stable working group. + +- FOSDEM 2017 stand acceptance is to be announced tomorrow. + + +[1] https://archives.gentoo.org/gentoo-project/message/1ccf2b07b96f4b164e6f69fb5d2d6cc7 +[2] https://archives.gentoo.org/gentoo-project/message/4a88db38253494c6612a29117b2b19c8 +[3] https://archives.gentoo.org/gentoo-project/message/60481da5b44b778ca5c4405da28f61c7 +[4] https://archives.gentoo.org/gentoo-project/message/70b28773ada15c2f4d1bcf1428ffa6a9 +[5] https://archives.gentoo.org/gentoo-dev-announce/message/651feb859ae9669dfeaa19547fa698dc diff --git a/meeting-logs/20161113-summary.txt.asc b/meeting-logs/20161113-summary.txt.asc new file mode 100644 index 0000000..d0f91ce --- /dev/null +++ b/meeting-logs/20161113-summary.txt.asc @@ -0,0 +1,13 @@ +-----BEGIN PGP SIGNATURE----- + +iQGcBAABCAAGBQJYLjHuAAoJEJQzkH1pP7W4MRAL/3p288AOwvPQlI3upfkPTVAx +ZnBY2z/wrCJvGHnSIsl2YxVRqPetkFad7Fh6yo0pPd6okXwH1wYtEvCZqPlMH8js +Fx/Brf6Uz+zJ2PCQRAxX0Lyx9betaNqUwWkwtgGAn9rLCjA8BSlmYrYkf9ca1zo7 +PxTH6+zDbZ29v1HOpo+KiTvvHP3GBva732ATmn+/xMKEXOJ9FXQvYaqo6v4ZigkW +8yCyMauA5B8/dbUL5SLk4YncnQwBf+ghDvfO0rp5UXJHQEuOsxt2jmP1PTnwgyMx +4MP4cQSIeG60Q5lFGF38Nt1njYcRM1wsle9aMWs9eM30P6HsEZ82uy+uHshq34+c +Ds941GL6Re70AdIC70/fENQ8wozXG2O2XvddZDRq0Etp0TJ6tTcBd+ZQ8hxQylSX +4J2UagZY+A2e+KGx/LyrW6aAt0hSPY19hoyo4eDK44eAaZHnQhlf5UlDX3u4cen4 +p8D3yJ4fDh8E0M7YGJ1MaZCMasrMbGdr6HACyp0OTw== +=yyKq +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20161113.txt b/meeting-logs/20161113.txt new file mode 100644 index 0000000..b320fa5 --- /dev/null +++ b/meeting-logs/20161113.txt @@ -0,0 +1,478 @@ +<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 :) diff --git a/meeting-logs/20161113.txt.asc b/meeting-logs/20161113.txt.asc new file mode 100644 index 0000000..84f0593 --- /dev/null +++ b/meeting-logs/20161113.txt.asc @@ -0,0 +1,13 @@ +-----BEGIN PGP SIGNATURE----- + +iQGcBAABCAAGBQJYKMmwAAoJEJQzkH1pP7W4J9UL/j5QMKAkA0kZjjS/y6Pg1VZU +88GqrDRijVjdSbhN55vPNq3dYozKXZuq/27JUq5Vp3pawJ/QmEspstHX6AteM7zv +2ZWNbI7MRX6NVWAXp8km0HXQreNaF7wqrtQ6PTuoPgam4WC2QcUoAz9pcFAEMXmX +lpvv3vuuHlxukL/2FJJ1LYHG09YPS+9AJ6InPbyJvdBQfOhEQytWsOvd3W86+YrG +RYwABOOU8v2Bhn7N7aDpfcYBE2AqDmXI8nJbFczGtD9mC8oFyYwAKwQgicWF3/uV +zZtF6tLjsW4CC7BLJVRMIIGtyXZEeTg3OuXrfJAa1wAsQG7Kj975lWBI3Y6jlHxV +XpqKPWSZEieb7UlvTnCqDpy0XAKqi/1O9DjtPqnarXi5Y1kkxAOu61FmXrdyjXmP +II7ELU9kuWxMJhMQpS0LwBlwq57rTEFTP1bzospR5ewQDt91hgr1P5py0DfvbT8M +OpH6/uflQ6l4HJOPa9zLJ1rz7vu4AOFq/0atxymBMA== +=2uJ8 +-----END PGP SIGNATURE----- diff --git a/meeting-logs/20161211-summary.txt b/meeting-logs/20161211-summary.txt new file mode 100644 index 0000000..4e92d5f --- /dev/null +++ b/meeting-logs/20161211-summary.txt @@ -0,0 +1,76 @@ +Summary of Gentoo council meeting 11 December 2016 + +Agenda +====== + +1) Roll call +2) Dropping of IA-64/SPARC Stable support +3) Gentoo-council mailing list, -project list moderation (also, purpose of -project) +4) Open floor + + +Roll call +========= +Present: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + + +Dropping of IA-64/SPARC Stable support +====================================== + +The general discussion was around the distinction between security +support and stable support, and the general sense was that stable +support should probably be tabled and addressed by the stable working +group. It was believed that addressing security support for these archs +would address the original concern. + +"The council defers to the security team, but is supportive of dropping +security support for sparc if it is unable to generally meet the +security team timelines." + +yes: blueness, dilfridge, jlec, k_f, rich0, ulm, williamh + + +Gentoo-council mailing list, -project list moderation (also, purpose of -project) +================================================================================= + +"The council would like the community to consider mailing list +discipline when posting to the various MLs of the Gentoo community. This +includes, but is not limited to, thread discipline and a consideration +of whether a new post adds value to the discussion at hand when posting +in order to ensure a good signal to noise ratio." + +"Messages should be inline quotation and cropped to the relevant +quotation needed for context in order to improve readability" + +yes: blueness, dilfridge, jlec, k_f, rich0, ulm abstain: williamh + +It was noted that sometimes top-posting can be appropriate, and these +aren't completely hard rules. + + + +Open floor +========== + +prometheanfire brought up whether it would be beneficial to have +Council/Trustee members attend each other's meetings to provide more +immediate feedback on questions. The sense was that this could be +useful, but probably should be based on specific agenda topics/etc and +requested in advance vs being a general practice. + +prometheanfire brought up his proposal for having a single governing +board at: +https://docs.google.com/document/d/10xzPUREMzZllT7dLs85JjMvlymEY9wWzYPRCnTZIsfI/edit?usp=sharing +He is looking for comments from both Council and Trustees. It was +suggested that this be taken to the lists, but there was general +interest in participation. + +rich0 mentioned that he would be working on a comrel glep, but he'll +take the details to the lists/etc as time was running long. Anybody who +is interested can participate, and prometheanfire and neddyseagoon both +registered interest. + +dilgridge brought up Software in the Public Interest and asked the +Trustees to take another look at them. It was suggested that this might +be worked into the single board proposal in some way since it is a +metastructure change. diff --git a/meeting-logs/20161211.txt b/meeting-logs/20161211.txt new file mode 100644 index 0000000..253cc97 --- /dev/null +++ b/meeting-logs/20161211.txt @@ -0,0 +1,563 @@ +[14:00:36] <rich0> Ok, time to start. +[14:00:55] <rich0> Roll call: dilfridge, blueness_, jlec, K_F, ulm, WilliamH +[14:00:58] -*- rich0 is here +[14:01:00] -*- dilfridge here +[14:01:01] -*- blueness_ here +[14:01:05] -*- jlec here +[14:01:14] -*- K_F here +[14:01:31] -*- WilliamH here +[14:01:40] -*- ulm here +[14:01:45] <rich0> Excellent! +[14:01:48] <prometheanfire> here +[14:01:49] <rich0> Agenda is at: https://archives.gentoo.org/gentoo-project/message/44e9968f87afff0006ccc2d9a39a64ee +[14:02:11] <rich0> Ok, first topic is Dropping of IA-64/SPARC Stable support +[14:02:16] <rich0> https://archives.gentoo.org/gentoo-project/message/139ba32bbecd46c5bad53dbd22138f24 +[14:02:42] <dilfridge> did anone from these arch teams respond there? +[14:02:46] <rich0> Anybody want to offer any comments? +[14:02:49] <dilfridge> !proj ia64 +[14:02:50] <willikins> dilfridge: (ia64@gentoo.org) ago, hattya, jmorgan, vapier, zlogene +[14:02:55] <dilfridge> !proj sparc +[14:02:55] <willikins> dilfridge: (sparc@gentoo.org) ago, jer, jmorgan, pacho, vapier, xmw, zlogene +[14:02:59] <K_F> dilfridge: I haven't seen any official response from arch teams on the issue +[14:03:08] <K_F> I can offer some insight from Security Project perspective +[14:03:08] <rich0> ago did reply to both, but not really "officially" per se +[14:03:13] <rich0> K_F: please +[14:03:59] <K_F> keeping the list of stable arches and security supported arches in sync is a benefit, and it eases communication as well as workflow (in particular with regards to cleanup) +[14:04:17] <K_F> but it isn't strictly needed, and has been deviated from in the past +[14:04:34] <K_F> the end result is a larger number of bugs waiting for cleanup, but we can release GLSAs quicker as there isn't support for it +[14:04:58] <rich0> can or can't? +[14:05:02] <K_F> can +[14:05:09] <K_F> but the bug stays open afterwards for cleanup +[14:05:31] <rich0> So, you're suggesting sending out the notice, but not removing the affected package. +[14:05:32] <blueness_> K_F: i’m okay with dropping sparc and ia64 to ~arch for security reasons but not ppc/ppc64, let me explain why +[14:05:46] <K_F> rich0: yes, that is current practice +[14:05:46] <dilfridge> could you explain what happens to a sec-stabilization bug, if the supported arches are all stable but other stable arches still wait for stabilization? +[14:05:49] <blueness_> (or ai’ll wait) +[14:06:04] <rich0> dilfridge: first +[14:06:11] <rich0> blueness_: second :) (yours is longer) +[14:06:21] <K_F> rich0: but if security supported, GLSA needs to wait for stabilization from the teams.. if not security supported it becomes a matter of waiting for cleanup only +[14:06:50] <K_F> dilfridge: GLSA goes out one the security stabilizated packages are done.. bug remains open in [cleanup] state until it is gone +[14:06:59] <K_F> which will , on expectational basis, take longer time +[14:07:08] <K_F> but at least it doesn't stop GLSA release +[14:07:21] <dilfridge> ok +[14:07:23] <rich0> Ok, blueness_? +[14:07:46] <blueness_> the problem with dropping from stable to dev is building stages +[14:07:52] <K_F> I should also point out that IA64 is not a security supported arch per policies today, but is so by convention +[14:07:58] <blueness_> so i don’t build ia64 or sparc stages, but ppc/ppc64 i do +[14:08:08] <K_F> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html , Here is the list of currently supported architectures: alpha, amd64, hppa, pcc, ppc64, sparc, x86. +[14:08:15] <K_F> so the real question is sparc +[14:08:20] <K_F> from that point of view +[14:08:22] <blueness_> so i don’t care too much if not @system packages fall behind, even for security reasons +[14:09:12] <rich0> blueness_: this came up before a while back I believe. The goal is to have a core of stable keyworded packages for reliable stage generation, and as a springboard? +[14:09:43] <K_F> blueness_: I dont believe anyone has proposed ppc/ppc64 being dropped at this stage? +[14:09:55] <WilliamH> No, they haven't. +[14:10:09] <dilfridge> No +[14:10:25] <jlec> we should keep them stable if possible +[14:10:29] <rich0> So, here is my thought: I think it is important that what we call security supported be in fact security supported. +[14:10:32] <blueness_> i’d rather non-@system packages be dropped to ~arch than the whole profile be dropped to ~arch just to take care of some security issue in some marginal package +[14:10:34] <blueness_> rich0: correct +[14:10:35] <blueness_> K_F: yes reread aaron’s email +[14:10:35] <blueness_> point 4 https://archives.gentoo.org/gentoo-project/message/139ba32bbecd46c5bad53dbd22138f24 +[14:10:40] <dilfridge> (but it's not really looking nice either, see http://www.akhuettel.de/gentoo-bugs/ ... I dont have any plots for ia64 and sparc though.) +[14:11:00] <K_F> blueness_: right, thats not up for today :) +[14:11:27] <rich0> So, if an arch generally can't keep up with security bugs, they should lose security support status (so that users are informed of the reality of their situation). +[14:11:36] <blueness_> K_F: i’d like to think of an alternative if it gets there, like dropping individual packages to ~arch +[14:11:41] <rich0> That is of course different from stable support. +[14:11:55] <blueness_> rich0: that works too +[14:12:13] <rich0> blueness_: that is the whole business that k_f / kensington team is trying to deal with, it is painful to fix all those keywords +[14:12:30] <blueness_> rich0: yeah, i was supposed to help out too but real life +[14:12:33] <WilliamH> blueness_: that could happen right now. Arch teams could just put a note on a bug that they don't want x package stable on their arches. +[14:12:36] <blueness_> but i’m very keen on what we do there +[14:12:48] <rich0> I think we have already given the go-ahead to drop stable keywords individually/etc after so many days, but the reality is that nobody wants to deal with it +[14:13:18] <WilliamH> rich0: we've only given the go-ahead on certain arches, not globally. +[14:13:31] <rich0> Anybody remember which ones offhand? +[14:13:36] <WilliamH> rich0: but, yes, no one wants to do it. +[14:13:40] <rich0> (or at least ia64/sparc?) +[14:13:59] <kensington> according to qa, it can be done for any arch +[14:13:59] <kensington> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs +[14:14:00] <WilliamH> rich0: we get yelled at if we break the deptree, which I thought was up to the arches to fix if we drop them. +[14:14:14] <K_F> for the particular request, unless someone else wants to drop it .. from security perspective I propose we just phrase a "if security want to drop stable support for lagging arches such as sparc, they can do so on their own decision" kind of thing +[14:14:40] <rich0> I'm getting a sense that most here support dropping security support for the archs, but stable support needs more care? +[14:14:41] <K_F> then I can bring that up in security team for a vote +[14:14:58] <K_F> rich0: stable support needs more care, but we can handle that in wg-stable +[14:15:10] <WilliamH> kensington: the issue is, say openrc, if I yank an older version because some arches haven't stabled newer ones, it breaks their stages +[14:15:16] <rich0> My sense is that dropping security support only addresses the original concern? +[14:15:32] <K_F> rich0: it does +[14:15:43] <WilliamH> kensington: am I allowed to break their stages because they can't keep up? +[14:15:55] <K_F> WilliamH: no +[14:16:05] <kensington> WilliamH: certainly this rule doesn't work for every type of package +[14:16:08] <rich0> K_F: do you suggest that we take action, or do you think the security team can deal with this? +[14:16:29] <K_F> rich0: I'd like a note that council does not oppose sparc losing stable support +[14:16:30] <WilliamH> kensington: so why can't they prioritize stabilizing those packages? +[14:16:37] <K_F> rich0: ehrm, security support +[14:16:41] <K_F> now I'm confusing myself.. +[14:16:48] <rich0> How about ia64? +[14:16:48] <K_F> as it has historically been used on servers etc +[14:16:53] <WilliamH> kensington: I think if an arch can't stabilize @system packages they shouldn't have a stable profile +[14:16:57] <K_F> ia64 isn't formally security supported +[14:17:02] <rich0> ok +[14:17:06] <K_F> but fine by me to add it in for cause +[14:17:40] <rich0> I'm fine with that, and if the arch team wants to be considered security supported they have to keep up. IMO it is just "false advertising" to call it supported if bugs stay open forever. Users should at least know what they're getting into. +[14:17:47] <dilfridge> K_F: "stable support" or "security support"? +[14:17:50] <rich0> And changing back to security supported in the future is easy. +[14:17:54] <K_F> dilfridge: security support +[14:18:54] <rich0> So, how about this wording: "The council defers to the security team until next month, but is supportive of dropping security support for sparc if it is unable to generally meet the security team timelines." +[14:19:07] <rich0> Any tweaks? +[14:19:17] <K_F> I'm not sure there needs to be a timeline? +[14:19:27] <K_F> s/until next month// +[14:19:44] <rich0> I'm fine either way, we could just note that if it is still an issue we may revisit it. +[14:20:19] <rich0> "The council defers to the security team, but is supportive of dropping security support for sparc if it is unable to generally meet the security team timelines." +[14:20:28] <dilfridge> ++ +[14:20:29] <K_F> lgtm +[14:20:31] <blueness_> lgtm +[14:20:33] <rich0> ok, vote: +[14:20:34] -*- rich0 yes +[14:20:37] -*- K_F aye +[14:20:37] -*- blueness_ yes +[14:20:37] -*- WilliamH yes +[14:20:41] -*- dilfridge yes +[14:20:43] -*- ulm yes +[14:21:07] <rich0> jlec: ? +[14:21:08] -*- jlec yes +[14:21:13] <rich0> ok, passed 7-0 +[14:21:23] <rich0> Anything else on that one? +[14:21:34] <K_F> not from me +[14:21:38] <rich0> Next topic: Gentoo-council mailing list, -project list moderation (also, purpose of -project) +[14:22:31] <dilfridge> well, that kinda fixed itself +[14:22:53] <ulm> I don't think that it's fixed +[14:22:56] <K_F> well, the specific issue did, but a generic discussion can be in order still +[14:22:58] <rich0> ulm: you raised the topic. Do you want to say anything? +[14:23:13] <ulm> council items are drowned in the noise in -project +[14:23:35] <ulm> therefore the suggestion to revive the dedicated mailing list +[14:24:10] <rich0> So, my sense is that most of the stuff on -project was council-relevant (to the extent that it was on-topic at all), but it was noisy as far as how the discussions went +[14:24:10] <prometheanfire> a council specific list might be good, can be moderated +[14:24:37] <ulm> the second reason is that part of council topics are of a technical nature +[14:24:52] <ulm> therefore not really appropriate for -project +[14:24:57] <WilliamH> The noise level on -prooject was so high for a while that it became a huge timesink. +[14:25:03] <WilliamH> -project * +[14:25:27] <rich0> IMO the issues on -project are a bit orthogonal to where we discuss council topics. +[14:25:51] <rich0> If -project is broken (if), then that should be fixed, rather than just trying to hide from the list. +[14:26:06] <K_F> rich0: I believe I agree with that sentiment +[14:26:18] <rich0> I think the technical vs non-technical issue is potentially valid. +[14:26:25] <ulm> rich0: there may be high traffic even without the list being broken +[14:26:28] <rich0> But, I'm not sure I like the idea entirely. +[14:26:34] <dilfridge> the problem with -project is, it's hard to define "on-topic" there +[14:26:43] <WilliamH> -project is supposed to be non-technical right? +[14:26:47] <dilfridge> right +[14:26:49] <jlec> I think we should try to fit in the council items in -project and for technical in -dev. +[14:26:49] <rich0> dilfridge: indeed, that was also a topic Shentino brought up :) +[14:26:53] <WilliamH> -dev is technical ... +[14:27:02] <K_F> I believe a valid conern is also archiving reasons, having a specific list makes it easier to find decisions and discussions etc +[14:27:15] <rich0> So, how would it work if we did it? +[14:27:15] <K_F> irrespective of technical vs non-technical concern +[14:27:16] <jlec> rich0: you are right, if there is a problem we should fix that. +[14:27:29] <rich0> Have people repeat their key points or reference them in -council once a topic goes before council? +[14:27:35] <K_F> on the other hand, having contributions from a broader contributor base to discussions is a concern, will a specific list have that participation? +[14:27:58] <rich0> I think the reality is that most issues are goign to start on -dev or -project before becoming council items in general. +[14:28:01] <jlec> rich0: that would work, or we just use the wiki +[14:28:06] <K_F> and are devs actively avoiding -project due to volume, so that last point is moot? +[14:28:22] <rich0> so, if we do something with the wiki, where does a -council list fit into it? +[14:28:26] <Shentino> That is why I wanted it "officially" clarified as to the purpose of g-project ML +[14:28:52] <jlec> rich0: no -council. discussion on the existing lsits and summary in wiki +[14:28:53] <WilliamH> Shentino: the purpos of -project is non-technical discussions about Gentoo. +[14:28:59] <WilliamH> purpose * +[14:29:00] <jlec> like you suggested for -council +[14:29:05] <rich0> So, if devs are avoiding -project because the topics don't interest them that is one thing. If it is purely volume/noise then I think that is a different matter. +[14:29:30] <jlec> the noise is the problem, not the volume +[14:29:33] <rich0> WilliamH: non-technical stuff about the distro, but not foundation matters (for which we have -nfp). +[14:29:39] <rich0> And of course we have tons of dedicated project lists. +[14:29:51] <WilliamH> rich0: Right. +[14:29:52] <rich0> -project is basically a place to talk about Gentoo topics that don't fit elsewhere, IMO +[14:30:08] <dilfridge> rich0: that definition is not helpful +[14:30:20] <dilfridge> because then nothing is offtopic +[14:30:27] <ulm> rich0: yeah, and it is sort of strange that council topics would be discussed there +[14:30:28] <robbat2> perhaps changing the official description would also help; it's presently "For the discussion of non-technical matters in Gentoo +[14:30:42] <ulm> especially if many projects have their dedicated lists +[14:30:49] <dilfridge> hmm +[14:30:49] <ulm> and the foundation has -nfp +[14:31:10] <rich0> Well, the original purpose of -project was to get that stuff off of -dev +[14:31:19] <rich0> And make -dev much more purely technical. In that it was mostly a success. +[14:32:10] <dilfridge> would moving the council agenda/topic stuff to -dev help? then we can say "it's technical, or it's a council issue", which is somehow delineated +[14:32:18] <K_F> of course, agenda would still go to dev-announce, so devs are notified +[14:32:20] <rich0> So, if we made a -council list and it was moderated, what would be the rules/etc? +[14:32:36] <prometheanfire> dilfridge: I think crossposting it would be wise +[14:32:47] <rich0> Maybe only discussion of proposed agenda items, or business being brought before the council? +[14:32:51] <K_F> rich0: imho @gentoo.org should go through directly anyways +[14:33:03] <ulm> yes, no moderation for @gentoo.org please +[14:33:05] <rich0> K_F: sure, but that is more about how it is moderated/etc +[14:33:06] <K_F> so moderation would be for external contributors, I'd say the requirement is that it is on-topic +[14:33:19] <rich0> Hence the need to define the topic +[14:33:38] <jlec> perhaps we should introduce -gentoo-rant and come back to saome sane -project & -dev +[14:33:42] <rich0> (I'm brining up -council first because i think it is simpler to define than -project, and whether we go with it affects teh latter) +[14:33:44] <K_F> well, for council that is likely easy enough.. either a direct response to call for agenda, or on-topic discussion for it +[14:34:03] <robbat2> for questions of new list moderation; the key question I have from the infra perspective: who are the moderators? (infra is not taking on that role) +[14:34:10] <rich0> So, in general I'm not really a fan of solving noise problems by defining a /dev/null list and having all the noise go there +[14:34:18] <dilfridge> right +[14:34:20] <K_F> robbat2: could solve that by council being moderators +[14:34:27] <dilfridge> we can't talk about moderation without having moderators +[14:34:48] <dilfridge> only for -council. for -project that's a nutjob. +[14:34:51] <floppym> Heh, that sounds like an excellent use of council members time. +[14:34:54] <K_F> yes, for -council +[14:35:29] <rich0> Here is the thing, to the extent that stuff going before council does get moderated, people are going to tend to just post it elsewhere, resulting in noise. +[14:35:40] <mpagano> gentoo-complaints +[14:35:44] <rich0> Because their goal is to get heard, and obviously the topic is of some importance if somebody brought it up to council. +[14:35:57] <K_F> rich0: that is a concern, indeed +[14:36:15] <rich0> I don't really have an issue with moderation if the goal is to let everybody say any particular thing once and then cut down on repitition or last-word-itis. +[14:36:35] <prometheanfire> a mechanism for to tell someone that they need to distil their topic to be consumable would be helful +[14:36:38] <WilliamH> Yes, if -council was moderated, we would have to be quick on either approving messages or not. +[14:36:43] <K_F> another point is, as long as the topics are semi on-topic, people can ignore threads or set up discard rules in sieve etc +[14:36:57] <ulm> the old -council list wasn't moderated and it worked well enough +[14:37:02] <K_F> do we really need a top-level moderation of things that people can decide on themselves and MUAs should support? +[14:37:09] <rich0> Thread discipline would be another benefit of moderation. +[14:37:14] <ulm> so I wonder if we need moderation at all +[14:37:27] <WilliamH> Yeah, I'm not a big fan of moderation I don't think. +[14:37:45] <jlec> I don't think moderation is good. Same as I don't think bans are good. Communities need to be self healing +[14:37:49] <rich0> So, here is the thing, 4 months ago, were any of us considering this a problem that needed a solution? +[14:37:57] <jlec> Although that is easier said than done +[14:38:01] <K_F> can't speak for others, but not me +[14:38:06] <prometheanfire> I'd rather not have moderation +[14:38:09] <rich0> It seems like an overly involved solution to a specific problem. +[14:38:13] <dilfridge> no, 4 months ago not +[14:38:28] <rich0> But the technical vs non-technical concern would have been just as valid back then. +[14:38:46] <K_F> rich0: to the extent that council is only involved in technical matters +[14:38:47] <rich0> And my sense is that it wasn't such a big deal except for the fact that every topic was getting derailed. +[14:38:50] <ulm> rich0: I never liked the join of -council with -project +[14:39:01] <prometheanfire> perhaps be quicker on timeouts? +[14:39:09] <prometheanfire> that'd be a question for dilfridge +[14:39:10] <rich0> K_F: i've never considered the council to be only involved in technical matter +[14:39:21] <K_F> rich0: which is an argument for -project being OK +[14:39:27] <rich0> IMO thread discipline is probably the biggest recent issue. +[14:39:38] <K_F> I agree, thread dicipline, and posting dicipline in general +[14:39:43] <rich0> If we want to have a thread about why <xyz> isn't well-supproted then fine. +[14:39:45] <K_F> to reduce overall volume of messages to useful +[14:39:46] <WilliamH> rich0: Yes, I agree. +[14:40:01] <rich0> However, every time any issue comes up, mention that if we only fixed this then <xyz> would be more supproted gets tiresome. +[14:40:08] <K_F> "if you're not contributing anything useful to the discussion, please consider not posting the message" +[14:40:34] <WilliamH> K_F: heh +[14:40:45] <dilfridge> well, 1) as I said, it's hard to draw a line on -project... 2) nobody wants to become the "big censor", so waiting until everyone else is annoyed becomes a strategy +[14:40:53] <K_F> "gentoo-project should be a discussion forum for topics relating to Gentoo. Consider the signal to noise ration when you wonder whether you should post something or not" +[14:41:20] <rich0> Gotta ration that signal, wouldn't want too much of it. :) +[14:41:40] <WilliamH> K_F: sure, but the most recent noise supposedly was Gentoo related... +[14:41:46] <dilfridge> You forgot about the IRS, and the Illuminati. +[14:42:02] <rich0> well, that was ok since it was on -dev :) +[14:42:03] <K_F> WilliamH: I'm not sure how many of the posts in question contributed to the discussion... +[14:42:04] <WilliamH> dilfridge: lol +[14:42:38] <WilliamH> K_F: sure, but the poster sure thought they did, lol. +[14:43:02] <rich0> I really don't think this is a long-term problem, and I'm concerned the cure is worse than the disease. +[14:43:16] <rich0> If it is long-term then I don't think just reviving a list is the fix anyway. +[14:43:21] <K_F> in any case, in general I don't want council to be a separate entity away from the community. a separate ML might make sense for archiving purposes and lookups, but otoh we have meeting logs and agendas that solves most of it +[14:43:41] <rich0> IMO the summaries/agendas already solve that problem. +[14:43:45] <WilliamH> Wasn't there supposed to be a decisions document also? +[14:43:45] <ulm> K_F: it is not "away from the community" +[14:43:53] <prometheanfire> seperating the discussion from the official requests may still be helpful +[14:43:57] <ulm> it is just a means to categorise the traffic +[14:44:09] <WilliamH> prometheanfire: Yeah, that's true too. +[14:44:30] <rich0> prometheanfire: that could be accomplished via thread discipline. Get people used to posting the topic on the agenda thread, and then starting a discussion thread for it +[14:44:31] <WilliamH> That would mean that calls for agenda items etc would go on council and g-d-a +[14:44:47] <prometheanfire> rich0: good luck :P +[14:44:56] <dilfridge> I think that the -project troubles have been very specific, and that there is a simple way to make them disappear, just that of course there's a downside of that (for someone) as well. +[14:45:06] <rich0> Yeah, I will admit that making sure I got all the agenda topics was painful due to that thread going crazy. +[14:45:28] <K_F> rich0: that is only an issue if the threads aren't OK +[14:45:37] <K_F> and the agenda threads weren't overly bad +[14:45:58] <rich0> Again, I'd rather work on thread discipline because that is something that benefits everybody everywhere. +[14:46:06] <rich0> And it seems like the "light handed" solution. +[14:46:06] <K_F> yup +[14:46:09] <blueness_> okay i wasn’t certain about this issue but from the above discussion, i think a -council list for council business open to the community is the say to go, not moderated +[14:46:29] <blueness_> s/say/way +[14:46:42] <rich0> Any other thoughts? I'm thinking maybe a quick poll for support for a new list vs keeping the same ones, and then we can worry about wording? +[14:46:54] <blueness_> yeah, let’s do that +[14:47:12] <rich0> Ok, please post whether you prefer a -council vs just sticking with -dev/-project? +[14:47:17] -*- rich0 -project/dev +[14:47:28] -*- blueness_ -council +[14:47:38] -*- ulm -council, obviously +[14:47:48] -*- jlec -project/dev +[14:48:08] -*- K_F -project/dev +[14:48:29] <rich0> dilfridge, WilliamH ? +[14:48:42] -*- dilfridge project/dev +[14:49:06] -*- WilliamH -council mostly because of the volume on -project +[14:49:25] <rich0> Ok, that is a majority for keeping things as they are. Do we need to actually vote on something specific? +[14:49:46] <rich0> I can record the general preference in the summary either way. +[14:49:49] <K_F> we could vote on an announcement for thread and posting dicipline +[14:49:52] <ulm> so then in future please explicitly cc me for the stuff on -project +[14:49:53] <WilliamH> The problem is, how do we get thread discipline to work? +[14:50:10] <ulm> because other wise I may miss something important +[14:50:14] <WilliamH> When you reply to a message, changing the subject alone doesn't start a new thread. +[14:50:18] <rich0> Well, if we can't I don't mind revisiting the problem, but that is going to be an issue anywhere. +[14:50:23] <ulm> *otherwise +[14:51:08] <WilliamH> People do a lot of this on threads: +[14:51:13] <WilliamH> re: foo was bar +[14:51:20] <WilliamH> but that doesn't break the thread +[14:51:31] <rich0> How about something like "The council would prefer to encourage the community to improve thread discipline and avoidance of repetition on the current lists before changing how we discuss agenda topics. This will be the topic of a list post." +[14:52:05] <rich0> WilliamH: suggest that MUA-101 be a topic we bring up, but that is like getting people to bottom-post. All you can do is keep pointing it out. +[14:52:08] <ulm> rich0: that's mostly a no-op because the problematic won't care about it +[14:52:29] <rich0> ulm: well, I'm all for specific solutions to specific problems. +[14:52:33] -*- WilliamH also hates the reply-to munging we do but that's a separate topic I guess +[14:53:04] -*- rich0 nominates WilliamH for the email etiquette indoctrination working group +[14:53:10] <WilliamH> heh +[14:53:13] <prometheanfire> https://www.wikiwand.com/en/Posting_style#/Bottom-posting :P +[14:53:37] <rich0> In any case, do we want to vote on the proposal I put out there, or tweak it? +[14:53:42] <K_F> bottom posting is one thing, but people need to trim their quotes for sure +[14:53:45] <rich0> I get that it isn't the solution everybody wants. +[14:54:11] <K_F> rich0: so to get it straight, that implies a discussion topic on email etiquette on -project, right? +[14:54:12] -*- rich0 nominates K_F for vice-chair of the email working group +[14:54:22] <rich0> Apparently. +[14:54:41] <dilfridge> ok so we want to solve the off-topic posting problem by bikeshedding +[14:54:42] <K_F> rich0: https://blog.sumptuouscapital.com/2016/01/email-are-you-writing-emails-in-a-proper-etiquette/ < I've tried and failed :| +[14:55:14] -*- WilliamH isn't happy with that solution +[14:55:23] <WilliamH> we end up with endless bikesheds already +[14:55:26] <rich0> So, here's my thought, unless we actually impose moderation then the noise problem doesn't go away just because we create a new list to put the noise on. +[14:55:52] <K_F> but we can make a statement on how we want it +[14:55:55] <rich0> All the threads on -project will just move to -council, since their purpose was to get attention/etc. +[14:56:15] <ulm> rich0: where they would be clearly off-topic however +[14:56:27] <WilliamH> K_F: sure, but what can we really put behind that statement -- when people disregard it? +[14:56:32] <rich0> People aren't dumb. If you tell them to go post on some list nobody reads, they won't fall for it. +[14:56:33] <ulm> giving us some handle for measures against them +[14:56:48] <K_F> WilliamH: if bad enough, could ban it if it goes against the stated description +[14:57:00] <dilfridge> so how do we define the topic of -project ? +[14:57:09] <K_F> dilfridge: I believe it comes back to that +[14:57:10] <rich0> The thing is, that much of the stuff on -project was relevant to council decisiosn (not necessarily ones in the very next meeting, but certainly longer-term). +[14:57:23] <jlec> How do peers like debian and so handle this? +[14:57:25] <rich0> I don't care for HOW the posts were done, but I can't say that the topics themselves weren't relevant. +[14:57:32] <jlec> I assume they have the same problems. +[14:57:33] <K_F> rich0: I'd tend to agree +[14:57:57] <rich0> Now, if we want to have -council as a focused list for only topics in the very next council meeting, that might be a value-add. +[14:58:12] <rich0> Ie, no discussing topics that aren't on a call for agenda items. +[14:58:24] <WilliamH> The way -project is defined we can't say that the noise was off-topic. +[14:58:31] <rich0> And then longer-term stuff stays on -dev or -project. +[14:59:22] <WilliamH> Maybe it wasn't off-topic, but imo there was a major behavioural issue involved. +[14:59:23] <rich0> Honestly, though, I don't see council members being able to avoid these general topics, since the topics themselves are important, even if we don't all agree with every opinion presented. +[14:59:40] <rich0> WilliamH: sure, and you don't solve people problems with list topics +[14:59:55] <WilliamH> rich0: No, you don't, I agree there. +[15:00:42] <rich0> So, where do we go from here? I could get behind a -council if the intent is to have a place for more razor-focus on specific action items for the next meeting, but I do have concerns that it could be perceived as isolationist. Personally I'd still participate on -project. +[15:01:12] <rich0> If we just maintain the status quo, then do we just drop this for a month and move on? I'm not sensing excitement over any alternatives besides noop. +[15:01:32] <rich0> And those of us who care can tilt at the email-101 windmills regardless. +[15:01:39] <WilliamH> Well, here's a question. +[15:01:47] <prometheanfire> I suggest a 'teaching' thread on -project and see how that goes +[15:02:18] <WilliamH> Would it have been a CoC violation for someone to post a message to the poster saying something about how he should stop doing what he was doing because he was just wasting everyone's time? +[15:03:00] <WilliamH> I've thought about doing things like that a couple of times, but I'm not sure whether it is cool. +[15:03:08] <rich0> I don't think that it would be a CoC violation to point out that topics have been repeatedly raised, or that new threads are being started needlessly, or so on. That isn't suppressing discussion, just trying to channel it, and I don't think you have to be on comrel to do that. +[15:03:26] <rich0> I'd focus on channelling vs scolding. +[15:03:55] <rich0> If I replied to an agenda thread instead of starting a new one I wouldn't be offended if somebody pointed it out. +[15:04:36] <rich0> Ok, we're over an hour and I'd like to either do something or table this. +[15:05:03] <rich0> Does anybody propose any specific action at this time on behalf of council, or are we content to just start pushing for some thread discipline individually and see how that plays out? +[15:05:09] -*- K_F isn't overly concerned about the time aspect as long as the discussion is fruitful +[15:05:25] <K_F> rich0: I'd prefer a council announcement/statement to the effect myself +[15:05:35] -*- WilliamH is ok with trying to push for thread discipline for now +[15:05:37] <rich0> K_F: care to offer a proposal? +[15:05:47] <K_F> give me a min to try to write up something +[15:05:48] <blueness_> rich0: maybe we can just gently remind people to keep on topic without an official email from the council +[15:06:09] <blueness_> like jlec’s self-healing community +[15:06:29] <rich0> I'm also fine with tabling this and agreeing on a council email or whatever offline and sending it out when ready. +[15:07:05] <K_F> "The council would like the community to consider mailing list dicipline when posting to the various MLs of the Gentoo community. This includes, but is not limited to, thread dicipline and a consideration of whether a new post adds value to the discussion at hand when posting in order to ensure a good signal to noise ratio." +[15:07:35] <K_F> addendum.. +[15:07:59] <WilliamH> s/dicipline/discipline/ +[15:08:01] <Soap__> K_F: will that change anything? +[15:08:06] <K_F> "Messages should be inline quotation and cropped to the relevant quotation needed for context in order to improve readability" +[15:08:16] <ulm> also stay on topic, no html, no top posting, +[15:08:32] <ulm> and avoid messages longer than 200 words :) +[15:08:33] <rich0> :) +[15:08:43] <rich0> or at least 200 pages +[15:08:46] <K_F> ulm: not another twitter please :p +[15:09:07] <rich0> K_F: is that it? +[15:09:09] <WilliamH> ulm: lol +[15:09:22] <K_F> some posters might have 200 words of very relevant data, and in particualar references and background material if provided in proper endnotes +[15:09:41] <dilfridge> when above lenght provide a tl;dr at the top +[15:09:41] <rich0> So far we have: "The council would like the community to consider mailing list dicipline when posting to the various MLs of the Gentoo community. This includes, but is not limited to, thread dicipline and a consideration of whether a new post adds value to the discussion at hand when posting in order to ensure a good signal to noise ratio." +[15:09:48] <rich0> "Messages should be inline quotation and cropped to the relevant quotation needed for context in order to improve readability" +[15:09:49] <ulm> K_F: yeah, that wasn't entirely serious :) +[15:09:54] <WilliamH> Yeah, I don't think we can put a length limit on messages, but I know what you are getting at ulm. +[15:10:05] <rich0> Keep in mind we're not writing a glep here. +[15:11:19] <rich0> Ok, if nothing else then let's vote on his proposal: +[15:11:22] -*- rich0 yes +[15:11:26] -*- K_F aye +[15:11:32] -*- blueness_ yes +[15:11:57] -*- jlec yes +[15:11:59] -*- ulm yes +[15:12:11] -*- WilliamH abstains +[15:12:33] <rich0> dilfridge: ? +[15:12:37] <WilliamH> Sometimes there are reasons for top-posting. +[15:12:48] <dwfreed> for the guy an hour late to the meeting, my I ask what you've just voted for? +[15:13:05] <rich0> "The council would like the community to consider mailing list dicipline when posting to the various MLs of the Gentoo community. This includes, but is not limited to, thread dicipline and a consideration of whether a new post adds value to the discussion at hand when posting in order to ensure a good signal to noise ratio." +[15:13:05] <rich0> +[15:13:05] <rich0> "Messages should be inline quotation and cropped to the relevant quotation needed for context in order to improve readability" +[15:13:08] <rich0> dwfreed: ^ +[15:13:37] <WilliamH> basically a statement to post on the mls +[15:13:39] -*- rich0 notes that this is intended as a general appeal, and not some kind of no-matter-what rule +[15:13:40] <K_F> editorial changes for spelling errors allows by the person posting it to the list +[15:13:43] -*- dilfridge yes +[15:13:51] <rich0> ok, passes 6-0 +[15:13:55] <K_F> s/allows/allowed/ +[15:14:31] <rich0> Anything else on this topic? Do we want to maybe take the purpose of -project back to the list and bikeshed it there? +[15:14:50] <dwfreed> just as long as it's clear that we're not going to beat people over the head over that last sentence +[15:14:53] <K_F> rich0: should add WilliamH's dicipline -> discipline to it +[15:15:04] <rich0> K_F: will do, we don't need to vote on spelling +[15:15:10] <K_F> agreed +[15:15:43] <K_F> if there are reasons for top-posting (e.g forwarding of mail), no worries, it is an encouragement +[15:16:18] <dwfreed> top posting is the default for most mail clients (Outlook, Gmail web, etc) and people are new or lazy +[15:16:35] <rich0> Ok, then that brings us to open floor +[15:16:48] <prometheanfire> I have two things +[15:16:54] <rich0> go ahead +[15:17:23] <ulm> dwfreed: muas having a stupid default isn't an excuse +[15:17:23] <prometheanfire> First one is short, I'd suggest possibly having council report to foundation at their meeting and visa versa, just to keep everyone in sync +[15:17:35] <prometheanfire> I just thought of it, so have nothing to report this meeting :P +[15:17:46] <WilliamH> Sounds reasonable to me. +[15:17:48] <K_F> prometheanfire: the meeting logs are open to everyone +[15:17:54] <K_F> logs and summaries +[15:18:07] <prometheanfire> true, but having a proxy from each body is useful +[15:18:19] <K_F> prometheanfire: can you elaborate? +[15:18:32] <K_F> what is the goal? +[15:18:53] <prometheanfire> This is mainly for if there are any questions during the meeting +[15:19:18] <prometheanfire> a member of the body the question is proposed to is around and may be able to answer, rather then stalling the conversation at that point +[15:19:30] <K_F> prometheanfire: the meeting schedule is public, the agenda is public +[15:19:41] <K_F> prometheanfire: I'd consider it a foundation responsibility to have a member present if they consider it relevant +[15:19:58] <prometheanfire> that discounts things that are unscheduled +[15:19:58] <K_F> (as robbat2 was here for infra comments on moderation today) +[15:20:01] <rich0> So, I think both points are valid +[15:20:08] <rich0> There is value in having cross-participation +[15:20:25] <rich0> But, it might make more sense to look at the topics and have people attend to address, vs just having people always around just in case. +[15:20:54] <rich0> And of course list discussion is always better than live discussion when possible +[15:21:11] <K_F> this also goes to why I have a personal policy of not voting for issues not on agenda +[15:21:27] <K_F> it can be discussed during open floor, but no decision should be made, exactly to give pre-warning +[15:21:43] <K_F> and proper discussion ahead of time +[15:21:50] <prometheanfire> rich0: true, like I said before the meeting, I only just thought about it. but the person from the 'other' project would serve as an info source mainly +[15:22:16] <prometheanfire> not required, but encouraged +[15:22:36] -*- WilliamH could go with that -- don't require it but encourage it. +[15:22:47] <rich0> How about this, maybe both bodies should consider their agenda topics in general and reach out to the other if they think having somebody around for a specific topic would be useful? +[15:22:54] -*- K_F fails to see an issue to discuss here +[15:23:07] <prometheanfire> rich0: of course, I'd hope that's already done +[15:23:09] <rich0> But, sure, nothing wrong with more cross-participation +[15:23:24] <prometheanfire> I don't have anything more on this item +[15:23:27] <rich0> Ok, what was your other topic? +[15:23:31] <K_F> by all means, I just believe it is the responsibility of the other party as long as the agenda is public +[15:23:48] <dilfridge> so, how about sending the trustees agenda also out to the (nfp) mailing list, and making summaries of the meeting logs? +[15:23:58] <K_F> dilfridge: that'd be useful +[15:24:20] <prometheanfire> dilfridge: iirc we do have logs, though the may be behind atm +[15:24:31] <prometheanfire> dilfridge: I'll bring that up next week +[15:24:36] <dilfridge> yeah, logs sure... +[15:24:46] <robbat2> we do have logs, and a list of motions passed/rejected +[15:24:47] <K_F> summaries are the useful parts +[15:25:00] <prometheanfire> K_F: indeed +[15:25:11] <dilfridge> that thing which veremitz always reminds me that I still have to do +[15:25:16] <K_F> and agenda on mail ahead of meetings +[15:25:46] <prometheanfire> https://wiki.gentoo.org/wiki/Foundation:Meetings/2016/12 +[15:26:06] <prometheanfire> we maintain our agenda there +[15:26:13] <prometheanfire> but we should send it out anyway +[15:26:41] <K_F> " Date of Next Meeting - Jan 15 2016 19:00 UTC" ? +[15:27:01] <dwfreed> scroll down +[15:27:17] <K_F> looks better :) +[15:27:18] <dwfreed> actual meeting time is exactly 7 days from this meeting +[15:27:32] <dwfreed> I was confused at first too +[15:27:33] <robbat2> "Sunday 18th Decenber 2016 19:00 UTC on irc.freenode.net #gentoo-trustees +[15:27:34] <prometheanfire> anyway, I added that to the agenda +[15:27:39] <dwfreed> mgith want to swap those +[15:27:48] <dwfreed> and I can't type +[15:28:23] <prometheanfire> so, next? +[15:28:38] <rich0> sure, next? +[15:28:53] <prometheanfire> https://docs.google.com/document/d/10xzPUREMzZllT7dLs85JjMvlymEY9wWzYPRCnTZIsfI/edit?usp=sharing +[15:29:18] <prometheanfire> that links to a short (on purose) doc about the possibility of merging trustees and council +[15:29:32] <prometheanfire> going into reasons why and the like +[15:29:40] <prometheanfire> I mainly am asking for comments +[15:30:51] <rich0> So, I've mentioned that I'm generally in favor of an approach like this. I guess the question is what are the next steps. We're obviously not going to sort it out now. +[15:31:22] <prometheanfire> rich0: next steps are just comments from each body about the proposal +[15:31:25] <rich0> Part of me wonders if this should go into some kind of GLEP, discussed on the lists, etc. +[15:31:32] <prometheanfire> so we can get it more solidified +[15:31:45] <prometheanfire> I'm moving slowly on this on purpose +[15:31:51] <K_F> rich0: yes, that is a metastructure change, so should be a GLEP voted on by all developers +[15:31:51] <rich0> good idea, imo +[15:32:17] <K_F> it is for sure not something for open floor to solve, but should be heavily discussed on the MLs +[15:32:18] <prometheanfire> ya, it'd need to be ratified by both bodies +[15:32:35] <rich0> Are you looking for comments /now/ or just the general path forward of getting it out on the lists and discussed? +[15:32:44] <WilliamH> Wouldn't it have to be a full dev vote since it is basically a change to glep 39? +[15:32:50] <K_F> WilliamH: yes +[15:32:54] <prometheanfire> I'd like comments from councilors and trustees (will bring it up next week), then I may edit to address the comments +[15:32:56] <dilfridge> WilliamH: yes, most likely +[15:33:00] <prometheanfire> once edited I'd send it to the lists +[15:33:12] <NeddySeagoon> WilliamH: Its also a change to the Foundation +[15:33:14] <rich0> I suggest that those who are interested work on making this a more complete proposal. +[15:33:27] <rich0> Then once we have some sense of where we want to go, then we talk about the details of getting there. +[15:33:32] <WilliamH> prometheanfire: What about your bi-law that says trustees can't be on the council? +[15:33:42] <rich0> There are GLEPs, votes, election of the board, fixing the bylaws, etc. +[15:33:44] <prometheanfire> WilliamH: many changes would be needed +[15:33:50] <K_F> WilliamH: that part is actually solved if merging +[15:34:02] <prometheanfire> WilliamH: last paragraph says this isn't a complete proposal +[15:34:03] <rich0> First agree on where we're going. Getting there is a bit of a pita, but really just a lot of small details. +[15:34:05] <jlec> prometheanfire: please have this discussed on the ml. I am all for simplification, but the problem section needs some more precision +[15:34:26] <prometheanfire> rich0: exactly +[15:34:37] <K_F> once a proposal for GLEP exists, the council can have a vote on whether or not to recommend it to the wider community ahead of an all developer vote +[15:34:41] <prometheanfire> if any of you want edit rights send a request +[15:34:45] <WilliamH> prometheanfire: can you email me a .txt version? Google docs doesn't work that well for me. +[15:34:46] <K_F> ahead of that it'd be unprofessional to comment officially +[15:34:51] <dilfridge> so the main objections I've heard so far are 1) some devs dont want to be automatically part of a legal organization, 2) some people may not be able to join the board because of "real work" +[15:35:03] <prometheanfire> WilliamH: k +[15:35:11] <K_F> but can of course participate in the discussion on an individual basis +[15:35:25] <WilliamH> prometheanfire: I'll keep the link and play around with google docs to try to figure it out. +[15:35:44] <NeddySeagoon> dilfridge: Thats why Foundtion is op in, not opt out +[15:35:49] <K_F> dilfridge: I'm not sure about the US law on it, but at least here, automatical signup would be an issue for something like that +[15:36:20] <rich0> Imo, the mandatory part is simple, just keep it like it is today. Any dev can get a vote at any time if they wish, but are not required to do so ever. +[15:36:21] <dwfreed> here's a big question: as one of the few people not immediately entitled to foundation membership, and unable to vote for council at all, how would that work moving forward? assuming I get membership next week at the foundation meeting, would I be able to vote for the members of this new Board? After the formation of the Board, would other community contributors who are not developers be able to +[15:36:23] <K_F> participation in a foundation would require active acceptance +[15:36:27] <dwfreed> request membership (as Foundation does now) and thus voting power? +[15:36:43] <NeddySeagoon> K_F: here, it depends on individuals contract of emplayment +[15:37:14] <rich0> just the main difference is that if you don't ask for the right to vote, you don't vote for the board, and the current council goes away. +[15:37:25] <rich0> Essentially trustees/council get combined. +[15:37:33] <K_F> dwfreed: my $0.02 is that it would require re-alignment so that only devs are entitled to vote +[15:37:45] <prometheanfire> dwfreed: previous itterations of this proposal suggested that voting power be tied to devship (previously staff) +[15:37:48] <ulm> K_F: +1 +[15:37:53] <prometheanfire> K_F: yep +[15:37:59] <NeddySeagoon> rich0: I see it as more both go away and are replaced by a new body +[15:38:04] <rich0> And I'm all for dev-ship for things like moderators, docs, etc. +[15:38:13] <K_F> i.e either not accepting non-dev members or two voting classes to foundation +[15:38:14] <rich0> NeddySeagoon: sure +[15:38:14] <prometheanfire> rich0: ditto +[15:38:27] <K_F> the latter being a bylaw change +[15:38:28] <dilfridge> K_F++ +[15:38:36] <rich0> ok, we're getting into the weeds a bit +[15:38:54] <rich0> IMO there really is no issue with making it happen. First we need to explain how it would all work and make sure we WANT it to happen. +[15:39:12] <NeddySeagoon> rich0: yes +[15:39:15] <K_F> well, from personal situation, I likely couldn't participate in a board +[15:39:16] <prometheanfire> so, now that I brought that up, I requests specific comments on the suggested goal (what we want to do) +[15:39:18] <rich0> Once people agree on what to do, actually doing it is rarely the issue. +[15:39:28] <prometheanfire> not how to get there, as rich0 said, that gets into the weeds +[15:39:29] <K_F> as that is restricted in my employment contract.. +[15:39:31] <rich0> ok, so, let's start getting this out there +[15:40:01] <K_F> (strictly speaking, it requires pre-approval) +[15:40:03] <rich0> K_F: I think that is a very legitimate concern, and probably worth a little thread. Would we give up too much with having a single board, or is there another solution? +[15:40:06] <prometheanfire> I'll do the same at next weeks trustees meeting +[15:40:17] <rich0> Ok, anything else on this? +[15:40:28] <NeddySeagoon> K_F: I had to get my employers permission in 2008 +[15:40:34] <dwfreed> K_F: with Foundation's current bylaws, there is one class of membership; the only distinction is in admission requirements for that class (which really it isn't a distinction, just devship is considered automatically qualifying for the significant contributions to gentoo requirement) +[15:40:45] <K_F> dwfreed: yes, that would likely change +[15:41:21] <prometheanfire> after next week I update the proposal and send it out for general comments/concerns, using that data I'll make a specific proposal, once we have a specific proposal the next step would be plan of action then implimentation +[15:41:48] <prometheanfire> so, I'm done :P +[15:41:54] <rich0> Ok, any other topics? +[15:42:20] <dilfridge> yes +[15:42:25] <rich0> I'll just mention that I might work on a comrel GLEP, and if anybody is interested they're welcome to pile on. +[15:42:25] <prometheanfire> two hours of meeting :P +[15:42:28] <rich0> No details now. +[15:42:34] <dilfridge> not so much for us but for prometheanfire and the next trustee thingy, +[15:42:44] <prometheanfire> rich0: possibly +[15:42:49] <K_F> rich0: yeah, I need to finish up something on security GLEP as well +[15:42:50] <dilfridge> please also discuss whether going the SPI way would be useful +[15:42:50] <prometheanfire> rich0: ping me with more info +[15:42:56] <NeddySeagoon> rich0: yes please +[15:42:56] <rich0> ok +[15:43:15] <prometheanfire> dwfreed: sure +[15:43:22] <prometheanfire> dilfridge: sure +[15:43:29] <prometheanfire> dwfreed: misping, again +[15:43:36] <dwfreed> I figured :) +[15:43:42] <rich0> SPI is probably worth another look now that debian/arch have gone that way, and maybe some of our previous concerns are addressed. That might also fit into the combined board changes/etc. +[15:43:58] <K_F> rich0: indeed +[15:44:21] <rich0> That it, dilfridge? +[15:44:21] <NeddySeagoon> rich0: indeed +[15:44:24] <dilfridge> yep +[15:44:32] <rich0> Ok, any other other topics? +[15:44:54] <prometheanfire> dilfridge: added to the adgenda +[15:44:58] <dilfridge> thanks +[15:45:13] -*- rich0 bangs the gavel +[15:45:21] <K_F> rich0: thanks for chairing +[15:45:22] <rich0> Ok, thanks all. I'll post the log and write up the summary. +[15:45:29] <jlec> thanks guys +[15:45:32] <K_F> rich0: as a matter of procedure, will you post the mail to -project? +[15:45:51] <rich0> K_F: oh for the etiqutette thing? Sure +[15:46:05] <K_F> yes, good +[15:46:07] <rich0> I'll post to -dev-announce diff --git a/meeting-logs/20161211.txt.asc b/meeting-logs/20161211.txt.asc new file mode 100644 index 0000000..bb9dda7 --- /dev/null +++ b/meeting-logs/20161211.txt.asc @@ -0,0 +1,16 @@ +-----BEGIN PGP SIGNATURE----- + +iQIcBAABCAAGBQJYTb8VAAoJEPnrMGeMBPQU7SYP/0YVbqU5u+BtrsPMviVuGD8d +C38s0JfGjKOjNN+EZjRpFxJO89XfpjTk6SYw960Xp6DIrTBBZrtdGyWUGQgBpKsU +zgt4gguuGxH+XaPUUyv7Wj1iA3/gyYW4fd3xzakhOKOAKKpuA55c+0pGbCRVwLam +AJDnEY/QbaM8kr8mWzkzLKjNmwGiHl31YhSdEstsIOcQUBNUBcAj7thlxgYwLYXs +MyKPonzh7g64W7kyQ5Iqu1JXKBHWShnY0z2D+6WTtDpgfxKPFH8oW7AVE3pqg5SO +WjxgObz3RsEjS59tCUrn6f+Ygn8Iucn080FguJ9MT7X2l5ojnnlAmocHbSSQgx3K +sUOyw/Nw8MgvmiRG1/+ouj658BPjoOx0FVWFx1Q/lQOfUmcgV2CtFd7Kb5xYPA6Y +gXCKROsnFHqBhzrhy1QTLl1h4vB3rmxhw6bUSRx+ez5unEXNsTFTfAscTXvnWQ29 +UZ8mOJ00HgYdBFgdC/rDusixah/0IwI+XorpBeNO3pUHV41CfhIoLiZOZTeWWbhM +xyAKBFqkc4Eeztde3aGKnKVEEiAaHivUlgimLaxEsetg3VSij3gmwLK/zS8fVLP6 +xzO8cVjBD44nNRsnGoQrsIlLUk/qjVMnmQ5c09+Hddc+sHSYdJIYzwBtli4zPwxo +nZoom/GzCKezbGrG8zB8 +=v5W6 +-----END PGP SIGNATURE----- |