1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
|
<dilfridge> gyakovlev: can you wgetpaste the agenda somewhere?
<gyakovlev> sure
<gyakovlev> !proj council
<willikins> (council@gentoo.org) dilfridge, gyakovlev, patrick, slyfox, ulm, whissi, williamh
<gyakovlev> agenda for todays meeting http://dpaste.com/1EQ2N9C
<gyakovlev> let's start with a 1) roll-call
* gyakovlev here
* slyfox here
* Whissi here
* dilfridge here
* ulm here
<dilfridge> (though with 5sec lag)
* Whissi pings DrEeevil
<gyakovlev> DrEeevil: ping
<gyakovlev> let's wait 3 minutes
<slyfox> *nod*
<gyakovlev> ok let's go on
<gyakovlev> 2. Does EAPI 4 ban apply to revision bumps as a result of dependency changes?
<gyakovlev> there was a discussion on project ML with no final conclusion, what do you guys think?
<ulm> mailing list thread is here: https://archives.gentoo.org/gentoo-project/message/f8aff1e7398a3c55babee153bb0d1e82
<dilfridge> "apply common sense"?
<slyfox> https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf#n28 does not day it's banned :)
<ulm> it doesn't make much of a practical difference
<slyfox> eapis-banned = 0 1 2 3
<slyfox> eapis-deprecated = 4 5
<ulm> because e.g. repoman sees only that eapi 4 is deprecated
<dilfridge> 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
<slyfox> why QA was not able to decide on their own?
<ulm> my suggestion would be to do nothing for eapi 4, and rethink the procedure when we ban eapi 5
<Whissi> +1
<ulm> for example, ban it only when the last ebuild is gone, i.e. when it is noted in layout.conf
<gyakovlev> ok what's the conclusion here? is it even votable or we just defer to QA?
<ulm> for eapi 4, there are not many ebuilds left, so whatever we decide, it will have little impact
<ulm> 353 ebuilds, to be precise ;)
<ulm> and it's not like they're about to be revbumped
* WilliamH here
<gyakovlev> WilliamH: we are discussing if "Does EAPI 4 ban apply to revision bumps as a result of dependency changes"
<gyakovlev> ok let's vote but defer implementation to QA, and we'll revisit for EAPI=5
<gyakovlev> 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
<gyakovlev> motion passed, 5 no votes(no ban for simle revbumps), 1 yes (ban applies), 1 missing.
<gyakovlev> let's move on
<gyakovlev> 3. open bugs with council participation
<gyakovlev> bug #662982
<willikins> gyakovlev: https://bugs.gentoo.org/662982 "[TRACKER
<DrEeevil> oh sorry, I got distracted
* DrEeevil is delayed and mostly present
<slyfox> Looks like bug #574752 is on infra@ and there is some progress
<willikins> slyfox: https://bugs.gentoo.org/574752 "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs
<Whissi> There was progress in last 30 days?
<gyakovlev> yeah delta snapshot bug closed
<Whissi> Cool. Missed that.
<gyakovlev> no activity within last 30 days in above bug, I'll ping them after the meeting.
<gyakovlev> moving on
<gyakovlev> bug #700364
<willikins> gyakovlev: https://bugs.gentoo.org/700364 "License council summaries under CC-BY-SA-4.0"; Gentoo Council, unspecified; IN_P; ulm:council
<ulm> nothing actionable for the council
<gyakovlev> i think it was supposed to be reassigned to ulm?
<gyakovlev> or I am confusing with other bug?
<ulm> yes, I can reassign to myself
<ulm> I think I suggested that last month already :)
<gyakovlev> yeah, ok please reassign and moving on.
<gyakovlev> 4. Open Floor
<ulm> done
<gyakovlev> thanks
<gyakovlev> let's wait for couple of minutes for open floor discussion.
<gyakovlev> ok looks like nothing for us here.
* gyakovlev bangs the gong.
<gyakovlev> meeting closed.
|
GitWeb
