|author||Ulrich Müller <email@example.com>||2016-11-13 21:15:51 +0100|
|committer||Ulrich Müller <firstname.lastname@example.org>||2016-11-13 21:15:51 +0100|
|parent||Summary for 20160710 meeting. (diff)|
Log for 20161113 meeting.
Diffstat (limited to 'meeting-logs')
2 files changed, 491 insertions, 0 deletions
diff --git a/meeting-logs/20161113.txt b/meeting-logs/20161113.txt
new file mode 100644
@@ -0,0 +1,478 @@
+<ulm> roll call
+* K_F here
+* blueness_ here
+* dilfridge 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
+<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> Stabilisation workflow
+<ulm> K_F: can you report on the status? [20:06]
+<K_F> I sent a written report on the list at
+<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
+<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
+<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
+<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
+<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> 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
+<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
+<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
+<jlec> me too
+<ulm> 3. Status of contributors (nominate Foundation liaison)
+<ulm> do we have any further information on this?
+<ulm> from trustees?
+* WilliamH isn't quite sure what that's about either [20:20]
+<NeddySeagoon> prometheanfire: your on
+<ulm> prometheanfire: can you summarise what this is about?
+<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.
+<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
+<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]
+<prometheanfire> dilfridge: yes?
+<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."
+<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
+<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
+<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.
+<prometheanfire> ulm: of course, like I said, didn't expect a vote at this
+<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 ?
+<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
+<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
+<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
+<ulm> everyone o.k. with tabling it? [20:40]
+<jlec> me too
+<ulm> ok, let's move on then
+<ulm> 4. Copyright matters
+<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.
+<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?
+<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
+<prometheanfire> ah, ok
+<ulm> 5. Open bugs with council involvement [20:44]
+<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
+<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?
+<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> blueness_: 1025 is mine [20:47]
+<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
+<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;
+<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;
+<WilliamH> again, that's waiting for infra?
+<ulm> anyone from infra here who can report on status?
+<jlec> There is progress isn't it?
+<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
+<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
+<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> 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 |
+<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
@@ -0,0 +1,13 @@
+-----BEGIN PGP SIGNATURE-----
+-----END PGP SIGNATURE-----