diff options
Diffstat (limited to 'meeting-logs/20161113.txt')
| -rw-r--r-- | meeting-logs/20161113.txt | 478 |
1 files changed, 478 insertions, 0 deletions
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 :) |