13:00 <@WilliamH> ok folks, the agenda is here:
13:00 <@WilliamH> https://archives.gentoo.org/gentoo-project/message/bb7e3a5d1656d595845835a6b891de2f
13:00 <@slyfox> i'm around
13:01 <@WilliamH> roll call:
13:01  * WilliamH here
13:01  * K_F here
13:01  * tamiko here
13:01  * dilfridge here
13:01  * slyfox here
13:01 <@tamiko> mgorny: *ping*
13:01 <@dilfridge> mgorny: ulm: yabba... dabba... doooh!
13:02 <@K_F> mgorny was around momentarily ago at least
13:02 <@WilliamH> shall we move on?
13:02 <@K_F> I suggest waiting a few minutes, light agenda today
13:02 <@tamiko> WilliamH: Let's wait 2 minutes.
13:03 <@K_F> sending sms to ulm, to remind of 1800 utc switch
13:03  * dilfridge checks out the latest updates https://www.youtube.com/watch?v=h_iejoEQmcU
13:03 <@mgorny> mgorny: sorry, here
13:05  * ulm here
13:05 <@slyfox> \o/
13:05 <@ulm> K_F: thanks
13:05 <@K_F> ulm: np
13:05 <@WilliamH> ok folks moving on, point 2.
13:05 <@WilliamH> My thought is we sould just support the kernel team's policy.
13:05 <@WilliamH> should *
13:06 <@WilliamH> There's no reason to hold them back on this.
13:06 <@dilfridge> works for me
13:06 <@dilfridge> and the overall rule "you break it you fix it" remains anyway
13:06 <@K_F> well, does the request mean that kernel team is uncertain?=
13:06 <@K_F> at the very least we might want to OK auto-stabilization of point releases in already stable LTSes
13:06 < mpagano> NO
13:06 < mpagano> whhops caps
13:07 < mpagano> K_F: yes, that's the ask
13:07 <@K_F> mpagano: ah, great you're here, maybe you can elaborate a bit on the request
13:07 <@ulm> I would go even further and say that the kernel team can self-stabilise any version they see fit for it
13:07 <@WilliamH> one sec I'm reading again
13:07 < mpagano> the stable-wg group did a great job of defining it: https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf
13:08 < mpagano> ulm: there have been very rare cases where kernel versions have bricked hardware
13:08 < mpagano> my goal is to kick versions that we *know* have exploits
13:08 < mpagano> rather than depend on archs to stabilize. Which is not working
13:08 <@slyfox> i'm fine with kernel team to perform stabilization on their own
13:08  * dilfridge too
13:09 <@slyfox> would be nice if kernel team has minimal mechanism to test a kernel in qemu or similar
13:09 <@K_F> I would prefer if we're more specific
13:09 < mpagano> I'm only asking for what's in that pdf
13:09 <@mgorny> slyfox: we've already established that some arches don't really work in vm-s
13:09 <@WilliamH> ulm: I"m ok with that.
13:09 < mpagano> I depend on arch to stablize X.Y and I auto stable X.Y.Z
13:09 < mpagano> for LTS
13:09 <@K_F> testing kernel on various arches etc is pointeless due to different configuration, and upstream's no userspace breaking policy is well known
13:09 <@dilfridge> well at some point we need to rely on people behaving responsibly
13:09 <@slyfox> mgorny: still testing is better thatn no testing
13:09 <@K_F> but there is a difference in point releases and new branches, and I don't like stabilizing branches not LTS
13:10 <@dilfridge> testing is good, keeping vulnerable versions as latest stable is not good
13:10 <@K_F> and given upstream doesn't tag security related issues, having latest point release should be the default unless there are concerns about its stability
13:10 <@mgorny> i'd dare say that an arch team catching x.y.z+1 being more broken on some arch than x.y.z is not very likely
13:10 <@K_F> so even if we don't mandate it, I'd suggest we phrase a recommendation
13:10 <@mgorny> assuming some sanity is kept, i'm for it
13:11 <@WilliamH> K_F: I think we can trust the kernel team.
13:11 <@K_F> WilliamH: the kernel team is asking what is permitted behavior, so we need to provide proper support in any case
13:11 <@mgorny> possibly include some points of value like when the changelog doesn't indicate possibly likely breaking changes
13:11 <@mgorny> (not that it really should be for the sake of formality)
13:12 < mpagano> the reason this is here is because of the reactions I will get when I auto stablize certain archs
13:12 < mpagano> i need a vote to point those gentlemen too
13:12 <@ulm> nothing will stop the kernel team from asking for arch testing if they think it is necessary in some specific case
13:12 <@K_F> ulm: exactly
13:12 <@WilliamH> ulm++
13:13 <@mgorny> do we need to word some basic prerequisites like kernel team testing on at least one arch?
13:13 <@dilfridge> well, so in the pdf there are three bullet points, I'm pasting them in a sec:
13:13 <@mgorny> waiting some days, stuff like that?
13:13 <@WilliamH> Just a very simple vote:
13:13 <@dilfridge> * Stabilise Long Term Stable (LTS) branches once they  have  been  determined  to  be  so  and  tested downstream
13:13 <@dilfridge> * Have an automatic policy of stabilising new point releases within the LTS
13:13 <@dilfridge> * non-LTS branches should not be stabilise
13:13 < mpagano> the kernel team should never stablize a X.Y.0 release without the hardware to build, install and do a sanity check for a time
13:13 <@WilliamH> The council supports the kernel team auto-stabilizing  any version of the kernel on any arch they see fit.
13:13 <@K_F> mgorny: likely not, it should be build tested for gentoo specific issues (e.g patch not applying etc), but I think we can defer to kernel team for proper behavior
13:14 <@dilfridge> how about we just vote that these three points are council-supported policy?
13:14 < mpagano> dilfridge: please
13:14 <@K_F> dilfridge: wfm, although we likely want to add a note to point 2
13:14 <@mgorny> dilfridge: i think only middle point needs voting
13:14 <@WilliamH> one sec.
13:14  * WilliamH is working on wording
13:14 <@mgorny> 3rd is certainly kernel team decision
13:14 < mpagano> that works
13:15 <@mgorny> 1st looks like normal procedure to me
13:15 <@WilliamH> one sec.
13:15 < mpagano> mgorny: yep
13:16  * dilfridge is waiting for the Bartwickelmaschine (sorry doesnt translate)
13:16 <@K_F> dilfridge: specifically, automated policy is not a requirement to stabilize latest point release in the event kernel team has concern about stability of a given package and it should be build tested (for fetching and patch application) before applied and not fully automated process
13:17 <@tamiko> The three points dilfridge wrote seem sensible and simple enough.
13:17 <@tamiko> mpagano: You're happy with those?
13:17 < mpagano> tamiko: I am. Thanks
13:17 < veremitz> mpagano: tl;dr so the council should sanction that the kernel team can internally stabilise X.Y.Z subversions of a stable kernel series X.Y previously marked as LTS, yes?
13:17 <@tamiko> WilliamH: So what about just voting on them, then?
13:17 <@WilliamH> mpagano: is this the point you want us to vote on supporting?
13:17 <@WilliamH> If the kernel team determines a significant security fix is included for a kernel release of 4.X.Y where 4.X.(Y-1) has already been stabilized per the first bullet, the kernel team can auto stabilize that specific version.
13:17 < mpagano> veremitz: yes
13:17 < veremitz> mpagano: without requiring AT support.
13:18 < mpagano> WilliamH: yes
13:18 < mpagano> veremitz: and yes
13:18 < veremitz> simples.
13:18 <@WilliamH> ok... If the kernel team determines a significant security fix is included for a kernel release of 4.X.Y where 4.X.(Y-1) has already been stabilized per the first bullet, the kernel team can auto stabilize that specific version.
13:18 < veremitz> To avoid arguments :)
13:18 <@mgorny> WilliamH, mpagano: just y-1 or any y2<y1?
13:18 <@WilliamH> vote:
13:18  * WilliamH yes
13:18  * slyfox yes
13:18  * ulm yes
13:18 <@K_F> I'd remove the significant security fix
13:19 <@WilliamH> ah ok... hang on
13:19 <@K_F> upstream is horrible at tagging security fixes, it should just be generic , no predetermined requirement for security vuln detected
13:19 < mpagano> K_F: Agreed
13:19  * dilfridge yes, for any fix
13:19 < mpagano> exactly. And they slip them in
13:19 <@ulm> right, security bugs aren't in any way special for the kernel ;)
13:19  * tamiko yes
13:19 <@mgorny> WilliamH: and make it x.y.z, we're going to have kernel 5.* at some point
13:19  * veremitz reads 'vote carried' ..
13:19 <@mgorny> WilliamH: and not just -1 but any earlier version
13:19 < mpagano> right
13:19 < mpagano> mgorny: yes
13:20  * veremitz returns to coffee-making and hacking.
13:20 <@K_F> veremitz: please refrain from commenting on a non-relevant basis
13:20  * dilfridge switches veremitz back on ignore
13:20 <@WilliamH> K_F: something like:
13:20 <@K_F> we'd really like to avoid putting channel on +m as done historically
13:20 < veremitz> some devs have forgotten how IRC client-side filtering works -sigh-
13:20 <@WilliamH> If kernel version 4.x is already stable using the usual stabilization process, the kernel team can auto-stabilize any 4.s.y version at their discression.
13:21 <@K_F> WilliamH: use x.y.z to make it generic
13:21 <@WilliamH> K_F: ok hang on.
13:21 <@dilfridge> "If kernel version x.y is already stable using the usual stabilization process, the kernel team can auto-stabilize any x.y.z version at their discretion."
13:22 <@tamiko> WilliamH, K_F: I think we all agreed on the principal idea. I have no problem with the summary having a more polished policy statement.
13:22 <@K_F> dilfridge: ++
13:22 < veremit> lulz ban evasion
13:22 <@WilliamH> If kernel version x.y is already stable using the usual stabilization process, the kernel team can auto-stabilize any x.y.z version at their discression.
13:22 < mpagano> this might help or muddy: https://wiki.gentoo.org/wiki/Project:Kernel#Kernel_stabilization
13:22 <@WilliamH> vote:
13:22 -!- veremit was kicked from #gentoo-council by mgorny [Kindergarten is elsewhere!]
13:22  * dilfridge yes
13:22  * WilliamH yes
13:22  * K_F yes
13:22  * ulm yes
13:22  * mgorny yes
13:22  * tamiko yes
13:22  * slyfox yes
13:22 <@dilfridge> that's unanimous
13:23 <@mgorny> wording could still be argued a little but i think everyone's going to get the spirit of it
13:23 < mpagano> thanks. This will make Gentoo a safer better distrobution and certinaly my life easier
13:23 <@ulm> s/discression/discretion/
13:23 <@WilliamH> movingon: oint 3. open bugs with council involvement:
13:23 < mpagano> will not help my spelling
13:23 <@K_F> mgorny: the log should provide context if uncertainties at least
13:23 <@ulm> but that's an editorial change
13:23 <@tamiko> mpagano: :-D
13:23 <@WilliamH> moving on: point 3. open bugs with council involvement: (correcting typos
13:23 <@WilliamH> bug 565566
13:23 < willikins> WilliamH: https://bugs.gentoo.org/565566 "New ChangeLogs are in chronological order"; Gentoo Infrastructure, CVS/SVN/Git; CONF; patrick:infra-bugs
13:24 <@WilliamH> what do we want to do with this bug?
13:24 <@K_F> as I see it really nothing more fore council to do there
13:24 <@K_F> s/fore/for/
13:24 <@slyfox> let's un-CC council
13:24 <@WilliamH> Do we still need to stay on the cc?
13:24 <@K_F> no
13:24  * dilfridge doesnt care
13:24 <@tamiko> Jup. That thing is on every single council meeting for the last year...
13:25 <@tamiko> Let's make that an infra-only bug.
13:25 <@slyfox> i've un-CC-ed council@
13:25  * WilliamH is removing us now
13:26 <@WilliamH> hrm I'll try again in a minute after the meeting...
13:26 <@tamiko> Jup.
13:26 <@WilliamH> point 4, open floor:
13:27  * WilliamH listens
13:27 <@slyfox> i guess the only voice is banned
13:27 <@tamiko> A shame.
13:27 <@WilliamH> heh
13:27 <@mgorny> i guess we can remove the ban now
13:28  * WilliamH bangs the gavel.. meeting closed