gyakovlev: can you wgetpaste the agenda somewhere? sure !proj council (council@gentoo.org) dilfridge, gyakovlev, patrick, slyfox, ulm, whissi, williamh agenda for todays meeting http://dpaste.com/1EQ2N9C let's start with a 1) roll-call * gyakovlev here * slyfox here * Whissi here * dilfridge here * ulm here (though with 5sec lag) * Whissi pings DrEeevil DrEeevil: ping let's wait 3 minutes *nod* ok let's go on 2. Does EAPI 4 ban apply to revision bumps as a result of dependency changes? there was a discussion on project ML with no final conclusion, what do you guys think? mailing list thread is here: https://archives.gentoo.org/gentoo-project/message/f8aff1e7398a3c55babee153bb0d1e82 "apply common sense"? https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf#n28 does not day it's banned :) it doesn't make much of a practical difference eapis-banned = 0 1 2 3 eapis-deprecated = 4 5 because e.g. repoman sees only that eapi 4 is deprecated of course we want people to upgrade EAPI, but if a non-maintainer needs to e.g. fix a dependence due to a pkgmove, it would be rather stupid to require it why QA was not able to decide on their own? my suggestion would be to do nothing for eapi 4, and rethink the procedure when we ban eapi 5 +1 for example, ban it only when the last ebuild is gone, i.e. when it is noted in layout.conf ok what's the conclusion here? is it even votable or we just defer to QA? for eapi 4, there are not many ebuilds left, so whatever we decide, it will have little impact 353 ebuilds, to be precise ;) and it's not like they're about to be revbumped * WilliamH here WilliamH: we are discussing if "Does EAPI 4 ban apply to revision bumps as a result of dependency changes" ok let's vote but defer implementation to QA, and we'll revisit for EAPI=5 please vote "Does EAPI 4 ban apply to revision bumps as a result of dependency changes?" reverse logic here, no means ban does not apply and motion passes. * slyfox no * gyakovlev no * Whissi no * dilfridge no * WilliamH no * ulm yes motion passed, 5 no votes(no ban for simle revbumps), 1 yes (ban applies), 1 missing. let's move on 3. open bugs with council participation bug #662982 gyakovlev: https://bugs.gentoo.org/662982 "[TRACKER oh sorry, I got distracted * DrEeevil is delayed and mostly present Looks like bug #574752 is on infra@ and there is some progress slyfox: https://bugs.gentoo.org/574752 "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs There was progress in last 30 days? yeah delta snapshot bug closed Cool. Missed that. no activity within last 30 days in above bug, I'll ping them after the meeting. moving on bug #700364 gyakovlev: https://bugs.gentoo.org/700364 "License council summaries under CC-BY-SA-4.0"; Gentoo Council, unspecified; IN_P; ulm:council nothing actionable for the council i think it was supposed to be reassigned to ulm? or I am confusing with other bug? yes, I can reassign to myself I think I suggested that last month already :) yeah, ok please reassign and moving on. 4. Open Floor done thanks let's wait for couple of minutes for open floor discussion. ok looks like nothing for us here. * gyakovlev bangs the gong. meeting closed.