19:00 roll call * K_F here * blueness_ here * dilfridge here here jlec: rich0: WilliamH: [20:01] * jlec here who’s chair? [20:02] let's give them 5 minutes k [20:03] blueness_: ulm Here, sort of does anyone have WilliamH's phone number? anyone got a # of WilliamH or jlec? jlec is here right dilfridge: I am here sending SMS to willian [20:04] you were faster e-mail 27.07.2015 [20:05] * WilliamH is here agenda: https://archives.gentoo.org/gentoo-project/message/d29f0c78f786d3b314d51825f9239a3e Stabilisation workflow https://archives.gentoo.org/gentoo-project/message/1ccf2b07b96f4b164e6f69fb5d2d6cc7 K_F: can you report on the status? [20:06] I sent a written report on the list at https://archives.gentoo.org/gentoo-project/message/70b28773ada15c2f4d1bcf1428ffa6a9 thanks [20:07] 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 any action for the council at the moment? no, I believe it got a case because the submitter wasn't aware of the WG Shentino: you might want to elaborate on your agenda proposal? K_F: can you summary the major time saving mechanism in your report? [20:08] 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 K_F: k 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 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 but currently the discussion is about proper testing procedures etc, and even just documenting current policy [20:10] what about allarches self stabilization? as a trivia, can anyone point to a policy that states self-stabilization is OK today K_F: nothing formal. we could sepearate critical from non-critical packages and do an allarches stabilization on non-critical packages for amd64, some mail from kingtaco from several years ago blueness_: yes, separation of core and leaf, and even libraries and end apps is part of the discussion right now the main thing that keeps up allarches is, it seems not to fit into the arch team workflows [20:11] K_F: i can see that working K_F: ya, nothing formal, but I was told by an AT that I could self stablize my stuff for x86/amd64 libraries are easier to write test suites for, so recommendation might include recommendation for maintainers to ensure proper test suits I think we need to evaluate which arches we maintain stable profiles for also. so usually, even if the allarches flag is set, arches only stabilize their own keyword prometheanfire: it is explicitly prohibited by GLEP 40 and afterwards f.ex. for perl packages I go through the list, check if one arch has stabilized, and stabilize the rest dilfridge: ya, but for a maintainer workflow it may work better "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] K_F: just saying what I was told K_F: it would be nice if we could get repoman to target an arch anyway, seems that work is in progress independently of the report we've also been talking informally about reviving existing procedures so repoman —arche=ppc64 full would show the dep tree on that arch 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 should we table this item until next month? ulm: not even sure if we have a final product by then kensington has done very nice work summing up stabilization procedures [20:13] K_F: thanks for running this :D dilfridge: yes, that is part of this K_F: I think we won't get to vote about any motion today correct so I suggest we just leave it as that for now, but welcome input in #g-wg-stable [20:14] 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 jmbsvicetto: yes, but not backed by any council approved policy K_F: no, but by the arch team itself K_F: backed by their arch team lead, at the time and I think it was confirmed at least once at a later point [20:15] Yes, the arch team lead at the time set that up 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 I am really unsure what I should think about the whole stabilisation thing. Those questions used to be part of the devmanual arch chapter(s) I am running ~arch since years with little problem in the past being an arch tester was seen as a good way to get into gentoo [20:16] And I hardly ever got a serious regression reported as part of the stabilisation process. you learn a lot about packages, build systems, ebuilds mostly minor-minor things btw, I've been hearing and participating in discussions about stabilization policies for at least the last 6 years jlec: but there's always the chance you can get hard breakages running full ~arch. dilfridge: yes, but that only works if there are active arch teams to mentor WilliamH: sure, this is why we need stabilization [20:17] right, so we need contact volunteers But I mean we shouldn't take it to serious It is more important that we see users installing them 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 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] anyhow, I propose we move on, comments welcome in the WG channel anything else for this topic? 2. Stabilisation workflow [20:19] i’m good sorry me too 3. Status of contributors (nominate Foundation liaison) https://archives.gentoo.org/gentoo-project/message/4a88db38253494c6612a29117b2b19c8 do we have any further information on this? from trustees? * WilliamH isn't quite sure what that's about either [20:20] o/ prometheanfire: your on prometheanfire: can you summarise what this is about? ok 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] 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] I'd personally like to see a written up rationale for why such a change would be needed to begin with [20:23] prometheanfire: i never really understood what problem we’re trying to solve here 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 We're trying to solve a non-existing problem here. K_F: +1 K_F: I don't think change is NEEDED, but I do think the status quo could be better [20:24] 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 At least as long as everyone sticks to their responsibilities, things are working fine. +1 [20:25] but generally, I believe it is a good thing to write up GLEPs for special projects, I'm working on the security glep 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 but that will happen independently anyways does anyone want to come forward with a motion for this item? at this point I don't see anything for council though [20:26] 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) I disagree with the statement that the foundation owns gentoo ulm: legally it does [20:27] at least in the US it owns the trademark, and has control over funds 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?! but little else prometheanfire: here's the thing. consider the election manifestos. [20:28] http://dev.gentoo.org/~dabbott/manifest.html dilfridge: yes? https://dev.gentoo.org/~prometheanfire/trustee-manifesto.html ^ dabbott, prometheanfire, trustees 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." https://dev.gentoo.org/~rich0/council-manifesto-2016.txt https://dev.gentoo.org/~dilfridge/Manifest-2016.txt "if applicalbe it can be"* ^ rich0, dilfridge, council so now, my question to you is, who has been given the task to oversee the community? [20:29] K_F: that's all I was looking for help from dilfridge: comrel/pr K_F: fine with me that's not the question, the question is trustees/council I was hoping for rich0's help "asked from council" [20:30] 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." K_F: hold on, discussion still going on Sorry, a bit hard to chat right now, but I'm happy to still generally work with you on ideas [20:31] K_F: I didn't expect any decision about this at this meeting rich0: thanks, that'd be appreciated i’d like to know what the issue is 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] I'm aware this has been brought up in the past, a few times even 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). dilfridge: indeed... 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] dilfridge: it is only abused if we let them though personaly I belive the lines are already clear on responsibility, and as such it doesn't constitute a conflict jmbsvicetto: ya, I'm not sure what to do about that myself, I'm totally open to suggestions though my feeling is that a more concrete outline will be needed before we can move on with this jmbsvicetto: both entitien need to change so we can become one. [20:35] ulm: of course, like I said, didn't expect a vote at this meeting unless any council member would want to volunteer at this time well, there's always the way of Debian, Arch, and LibreOffice SFI ? yes yep dilfridge: yes, umbrella org might be something worth considering NeddySeagoon: ya, one suggestion recently was one joint council/foundation with more officers handling specifics, I liked that [20:36] Thats been discussed in the past too 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 ya, it's been rejected because of the loss of autonomy jmbsvicetto: that's one of the major things, I'm aware prometheanfire: are there any problems with comrel being under the council? anyway, rich0 offered to help out. We won't get further right now [20:37] K_F: shall we vote on your motion still? Soap__: personally, I think it should be under foundation for legal reasons, but like I siad before, ianal ya, I'm happy if rich0 can help as a sounding board ulm: if we are to vote on anything I'd prefer that over any council sanctioning of this process [20:38] we can probably do that without any vote however individuals are of course free to cooperate outside of it sure Why is a motion required? it is not 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 I'd suggest tabling this til next meeting If rich0 is going to work with prometheanfire, that's all that's needed at this point yes table i\t +1 wfm everyone o.k. with tabling it? [20:40] wfm me too ok, let's move on then 4. Copyright matters https://archives.gentoo.org/gentoo-project/message/60481da5b44b778ca5c4405da28f61c7 mgorny: rich0: ^^ wasn't copyright mentioned earlier as being a foundation issue? [20:41] Yes, I think it is a foundation issue. agreed Gentoo technically has copyright assignment. works for me agreed from me too [20:42] so not an issue for the council Agreed. [20:43] anything else, or can we move on? yes is the foundation capable of solving this? was talking about running the various social media included in this issue? mgorny: that's not up to the council to decide prometheanfire: that was a separate thread but not brought to the council. ah, ok 5. Open bugs with council involvement [20:44] 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 mgorny: I feel we could task council with doing something, but I don't know the issue well enough to say mgorny: well rich0 is also officially a foundation officer, so this is just changing the discussion venue but not that much what's happening prometheanfire: various social media should likely go through PR to begin with before council anyway not our task K_F: agreed bug 571490 ulm: https://bugs.gentoo.org/571490 "Missing summary for 20151025 council meeting"; Documentation, Project-specific documentation; CONF; mgorny:council [20:45] bug 596678 ulm: https://bugs.gentoo.org/596678 "Missing log and summary for council meeting 2016-09-11"; Documentation, Project-specific documentation; CONF; k_f:jlec missing summaries well, considering that council somehow sets up the direction for the whole community, i think it's important to decide on copyright here working on it, about half done (the first of the two) rather than some foundation who most developers treat as remote entity that has to exist but otherwise is completely alien jlec: any progress with the September summary mgorny: that's a legal issue; the council has no jurisdiction over it. mgorny: we have moved on Yes, I know. I write the logs ASAP then the 4 games bugs eww [20:46] can we take council out of CC there, and leave it to QA and Comrel? +1 3 for qa, 1 for comrel, that is was i supposed to do 1025? or 612? I dont think these are so problematic, since work to update the ebuilds is ongoing ulm, dilfridge: I believe wizardedit was doing a lot of work on the games issues. yes blueness_: 1025 is mine [20:47] k WilliamH: the question is if council has to stay in CC yes, there is currently nothing more for council to do on the issue, so removal from CC is correct we can take it out I believe QA can handle it, and CC council again if necessary ok, I'll remove council from CC of all four then, and add QA if necessary bug 579460 [20:48] ulm: https://bugs.gentoo.org/579460 "please make repoman ignore a missing "# $Id$" header line"; Portage Development, Repoman; IN_P; dilfridge:dev-portage is that in stable repoman? that is already implmeented in vcs not in stable yet (2.3.0 has it) but nothing more from council required on that either so un-CC there too? [20:49] that'd be my suggestion or do we want to keep track of it so now the question of removing the Id header follows... yeah, maybe we should stay in CC, in order to remove Id later dilfridge: If it is in stable repoman, there's nothing stopping that from happening. oh, I see we already have a decision on removal of CVS headers [20:50] so indeed no council action required yes, we're done so, remove from CC there too [20:51] bug 565566 ulm: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs again, that's waiting for infra? anyone from infra here who can report on status? There is progress isn't it? mgorny? ulm: dunno, i'm just sweeping floors in infra [20:52] we should follow up on email with infra and ask for a status update ya, I do about the same in infra but K_F: action item for you then :) i think someon (robbat2?) is working on splitting/removing changelogs hehe... seems like things are pretty clean there so maybe that'd be handled as part of it ulm: yes, I can write up a short email on it ya, it'd be him K_F: thanks that's all bugs, I believe [20:53] Open floor ok so there were questions whether some more archs could be added to the list of "can drop stable keywords" [20:54] Soap__: ago already relieved the situation Soap__: if anything is to be done there it should be a regular agenda item in any case also, isn't stablewg supposed to handle that? but yes, it also fits nicely into the WG mgorny: do you think the general slowness of ppc/sparc ATs will go away? Soap__: that would be something for discussion in the -dev ML, and possibly agenda item for a later meeting [20:55] Soap__: #gentoo-wg-stable, it fits nicely into our dsicussions there We probably need to drop keywords more. ok, next time round so i heard gentoo is dying Also witout feedback from arches if it doesnt arrive in time. mgorny: it certainly isn't as shining bright as it was in wltjr's times anymore. [20:56] Some arches have support for ancient CPU's, which probably slows down the process K_F: I think wrt wg-stable we should really look at which arches have stable profiles. maybe we should found a WG to restore gentoo to its former glory we need to get wltjr back on! Make Gentoo/Java great again! WilliamH: agreed (it is already in notes) Make Gentoo Great Again! [20:57] blueness_: heh ok, I think it's time for me to bang the gavel since open floor, FOSDEM 2017 stand acceptance is scheduled to be announced tomorrow Well, considering Perl, I guarantee you there’s no problem. I guarantee you. K_F: great I hope we get a stand and that people are ready to fill up the stand slots once we get there. K_F: yarp [20:58] blueness_: you are going to fosdem? right? if we want to recruit new devs, we need to be visible * WilliamH might go to scale any talk about changing of recruiters etc is moot if there isn't anyone to recruit, so for me the line starts at PR.. prometheanfire: nope blueness_: :( any other item for open floor? [20:59] blueness_: we just got a tag line at work "Make IT inspire R&D" :D * ulm bangs the gavel Make Gentoo inspire IT meeting closed thanks ulm 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" ulm: thank you!!! !!!1! [21:00] rich0: you will be next chair i got to go guys tata heh, we kept it to one hour :) for once :)