path: root/meeting-logs/20200209.txt

13:00 <@WilliamH> Ok folks, let's get started...
13:00 <@WilliamH> the agenda: https://archives.gentoo.org/gentoo-project/message/c822dd1ae331e33bb2cefe4fd83b9741
13:00  * gyakovlev here
13:01  * ulm here
13:01 <@WilliamH> roll call:
13:01  * slyfox here
13:01  * dilfridge here
13:01  * bonsaikitten here
13:01  * WilliamH here
13:01  * Whissi here
13:02 <@WilliamH> next point: licensing ebuilds as gpl2+
13:02 <@WilliamH> there were 3 questions submitted for votes:
13:02 <@WilliamH> Let's address the first one.
13:03 <@dilfridge> ok so, fundamental question, do we consider the "+" as desirable?
13:03 <@WilliamH> Can developers individually decide to license their ebuilds as gpl2+ if they meet the licensing requirements?
13:03 <@ulm> dilfridge: I do, but I'm still a but sceptical if it will work in practice
13:03 <@dilfridge> (in our context)
13:04 <@bonsaikitten> imo not desirable: I don't understand gpl3, I can't predict what gpl4 will be, so I don't like agreeing to terms I don't understand
13:04 <@ulm> OTOH, the decision would be easy to revert, going from GPL-2+ to GPL-2 is trivial
13:04 <@gyakovlev> dilfridge: I think it's not, I personally dislike + clause in any license
13:04 <@dilfridge> not once someone has committed gpl3+
13:04 <@slyfox> https://gentoo.org/get-started/philosophy/social-contract.html says "We will release our contributions to Gentoo as free software, metadata or documentation, under the GNU General Public License version 2 (or later, at our discretion) or the Creative Commons - Attribution / Share Alike version 2 (or later, at our discretion)."
13:04 <@ulm> dilfridge: we won't allow GPL-3+
13:05 <@dilfridge> ulm: that allows for a big mess
13:05 <@dilfridge> becaus,
13:05 <@dilfridge> imagine someone starts up an overlay, and uses tree ebuilds as basis, but bumps all to gpl3+
13:05 <@dilfridge> then we can't merge back anymore
13:05 <@bonsaikitten> dilfridge: is that a valid action?
13:06 <@bonsaikitten> ... so much confusion, I'd prefer just not doing that
13:06 <@gyakovlev> ^
13:06 <@ulm> dilfridge: same as if someone would add an overlay with all ebuilds written from scratch and licensed under CDDL
13:06 <@ulm> so not really anything new
13:07 <@dilfridge> bonsaikitten: if I edit something, I have copyright on my contributions, and if I decide gpl3+ on my contributions, the combination of the previous part and my contributions will also be gpl3+
13:07 <@dilfridge> "written from scratch" is the difference
13:07 <@WilliamH> ulm: hrm I don't know about the cddl example because ebuilds are source.
13:07 <@bonsaikitten> dilfridge: but the existing bits aren't, so it's not, and I'm getting a headache
13:08 <@ulm> linux seems to get along well with their mixed license model
13:09 <@ulm> but yeah, chances that we would get the whole tree relicensed to + are slim
13:09 <@ulm> and it's not clear with what our ebuilds need to be license-compatible
13:09 <@WilliamH> dilfridge: But, your example of an ebuild coming from an overlay that is gpl3+  is a possible concern.
13:10 <@WilliamH> ulm: is linux mixed license? I thought it was gpl2 only
13:10 <@gyakovlev> some parts are dual-licensed, like most of DRM (graphical) stack is GPL-2/MIT
13:10 <@WilliamH> I always heard Linus doesn't like gpl3
13:10 <@slyfox> it has a lot of dual GPL/BSD code and other flavours
13:10 <@ulm> there are files under GPL-2+
13:11 <@slyfox> you can frep for SPDX tags
13:11 <@WilliamH> Oh ok, I didn't know about the dual licensing.
13:12 <@ulm> see LICENSES/other/ in the kernel tree
13:12 <@gyakovlev> but do we really want more licensing variations? what's the benefit here?
13:13 <@gyakovlev> I'm not sarcastic, can someone explain in simple terms?
13:13 <@WilliamH> gyakovlev: I'm not sure of the benefit either, but I don't really have a strong opinion either way.
13:13 <@WilliamH> This all started because we have an eclass that is gpl 2+
13:14 <@ulm> the only benefit I can see is improved compatibility between GPL-3 and CC-BY-SA-4.0
13:14 <@ulm> but it's one-way only
13:15 <@ulm> so you cannot take GPL licensed examples and include them e.g. in the devmanual
13:15 <@WilliamH> Are we ready to vote?
13:15 <@ulm> I am
13:15 <@WilliamH> ok I'll hang out a minute I didn't see your msg ulm until after I asked.
13:15 <@WilliamH> ok.
13:16 <@WilliamH> Let's vote. can developers license their ebuilds under gpl2+?
13:16  * slyfox yes
13:17 <@Whissi> WAIT. You dropped 'individually', not?
13:17 <@WilliamH> Whissi: same thing, the word individually is sort of redundant
13:17 <@ulm> we should vote on the exact wording of a.
13:17 <@WilliamH> ok
13:17 <@WilliamH> one sec.
13:17 <@ulm> "provided that they fulfill relicensing requirements" is also important
13:18 <@WilliamH> a. Can developers individually decide to license their ebuilds as GPL-2+
13:18 <@WilliamH> rather than 'GPL-2 only' (provided that they fulfill relicensing
13:18 <@WilliamH> requirements)?
13:18 <@WilliamH> vote:
13:18  * slyfox yes
13:19  * dilfridge no
13:19  * gyakovlev no
13:19  * bonsaikitten no
13:19  * Whissi no
13:19  * ulm yes
13:19  * WilliamH abstain
13:19 <@WilliamH> the motion doesn't carry.
13:20 <@WilliamH> The next question:
13:20 <@ulm> hm, what do we do about that one existing eclass that is under GPL-2+
13:20 <@ulm> ?
13:20 <@ulm> can it stay unchanged?
13:20 <@gyakovlev> contact author and ask for re-license?
13:21 <@WilliamH> agreed
13:21 <@WilliamH> gyakovlev++
13:21 <@slyfox> which ebuild is that by the way? does it have many users?
13:21 <@ulm> ant-tasks.eclass
13:21 <@slyfox> s/ebuild/eclass/
13:21 <@gyakovlev> it should be easy to go back like ulm said.
13:21 <@WilliamH> Do we need to vote on the other two points or are they by default no?
13:21 <@WilliamH> I'll post the first one:
13:22 <@WilliamH> b. Should developers be encouraged to use GPL-2+ for new ebuilds
13:22 <@WilliamH> (whenever possible)?
13:22 <@dilfridge> well that's kind of an obvious no now
13:22 <@WilliamH> vote:
13:22 <@WilliamH> yes.
13:22 <@WilliamH> I agree.
13:22 <@ulm> we could only produce a contratiction if we would on it
13:22 <@WilliamH> the next one is as well:
13:22 <@ulm> *contradiction
13:22 <@WilliamH> I'll post it here for the record:
13:23 <@WilliamH> c. Should we start collecting permissions from contributors to relicense
13:23 <@WilliamH> their GPL-2 work as GPL-2+?  This will be helpful both to 1. and 2.
13:23 <@WilliamH> another no.
13:23 <@slyfox> *nod*
13:24 <@WilliamH> moving on.
13:24 <@WilliamH> open bugs with council participation.
13:24 <@WilliamH> bug 662982
13:24 <+willikins> WilliamH: https://bugs.gentoo.org/662982 "[TRACKER] New default locations for the Gentoo repository, distfiles, and binary packages"; Gentoo Linux, Current packages; CONF; zmedico:dev-portage
13:24 <@WilliamH> Are the snapshots fixed?
13:25 <@gyakovlev> they are, but last time there was something left to be done for delta users.
13:25 <@ulm> that would be bug 574752
13:25 <+willikins> ulm: https://bugs.gentoo.org/574752 "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs
13:26 <@ulm> wait, the name of the top-level dir includes the date now?
13:26 <@Whissi> No.
13:27 <@Whissi> toplevel was changed from portage to gentoo
13:27 <@gyakovlev> yes, it hinders delta computation
13:27 <@ulm> Whissi: https://bugs.gentoo.org/574752#c4 ?
13:27 <@gyakovlev> date was added
13:27 < veremitz> date is indeed addeed/included
13:27 <@ulm> which breaks delta
13:27 < veremitz> iirc robbat2 was doing testing with deltas?
13:28 < veremitz> new algo?
13:28 <@ulm> why must the tld name include the date?
13:28 < veremitz> ¯\_(ツ)_/¯
13:28 <@ulm> seems it has worked before without it?
13:28 <@Whissi> Sorry, I don't see timestamp in tarball
13:28 <@Whissi> https://mirror.netcologne.de/gentoo/snapshots/portage-20191224.tar.bz2
13:29 < veremitz> Whissi: top level folder
13:29 <@gyakovlev> robbat2 mentioned that xz compression on deltas makes them almost like the old ones, but I don't remember clearly.
13:29 <@Whissi> There's just one single portage folder
13:29 <@Whissi> of course I picked the old portage one
13:29 <@Whissi> :[
13:29 < veremitz> gentoo-YYYYMMDD iirc :p
13:29 < veremitz> not even THHMMSSZ :P
13:29 <@gyakovlev> Whissi: gentoo-20191224/metadata/md5-cache/dev-db/postgis-9999
13:30 <@gyakovlev> looking into new one
13:30 <@Whissi> yeah, gentoo-latest.tar.xz has it :/
13:30 <@slyfox> i suggest leaving it to the bug owners to sort the details out
13:30 <@WilliamH> So the question still holds, why does it need the date in the name of the folder?
13:30 <@WilliamH> But yeah we aren't going to fix it here.
13:31 <@dilfridge> who came up with it?
13:31 <@ulm> mgorny, it seems
13:31 <@ulm> rationale, "to match tarball name"
13:32 <@dilfridge> awesoem
13:32 <@WilliamH> not a good  rationale
13:32 <@Whissi> Well, the version I tested in January worked and didn't have that changes.
13:32 <@Whissi> So nice that this was changed "lately"
13:32 <@WilliamH> mgorny: ^^
13:32 <@WilliamH> please fix the folder to just be gentoo
13:32 <+mgorny> WilliamH: so a better solution is when tarballs extract to random unpredictable directories and when you want to compare two snapshots, they just happen to overwrite one another?
13:33 < veremitz> mgorny: wasn't a problem with portage-YYYYMMDD ?
13:33 <@Whissi> mgorny: No, user is supposed to use -x.
13:33 < veremitz> or was it?
13:33 <@WilliamH> If you really want to compare move the old snapshot to anothe name
13:33 <@WilliamH> another :p
13:33 <@Whissi> If you extract tarball you should notice that. We don't need to hold hands all the time.
13:33 <+mgorny> WilliamH: yes, because gentoo is special and users should use custom hacks to workaround it
13:34 <@dilfridge> you break it you fix it :P
13:34 <@Whissi> It's same like stage tarballs. From the beginning we are using -C ... are you going to propose adding a top folder in case someone wants to extract somewhere and compare...?
13:35 < veremitz> fwiw .. the tar --transform option is really useful ;)
13:35 <@slyfox> i suggest to move on
13:36 <+mgorny> Whissi: so it all boils down to 'someone was stupid back in the day so we must not ever fix it'
13:36 <+mgorny> we have new tarballs, it's an opportunity to fix it
13:36 < veremitz> also https://gitweb.gentoo.org/infra/mastermirror-scripts.git/tree/snapshots-create.sh#n317 WRT deltas.
13:36 <+mgorny> if you want the old way, you have to come with a better argument than 'oh no, it broke my workflow'
13:37 <@dilfridge> well, it *did* break something
13:37 <+mgorny> or the more precise gentoo argument 'my eyes don't like it, so it must be changed to fit my preferences'
13:37 <@WilliamH> mgorny: the same thing could be said about your argument.
13:37 <@Whissi> mgorny: But if you introduce such a 'late fix' which is causing 'regressions'... we can't fix world in one step. So let's do the new tarball first if we don't come up will a solution which addresses everything and find a solution for that problem later.
13:37 <@ulm> can we move on please? I think we don't want to micro-manage things at that level
13:38 <@Whissi> *with
13:38 <@slyfox> +1
13:38 <+mgorny> Whissi: so you're asking to revert stuff, break portage AGAIN...
13:38 < veremitz> and emaint sync!
13:38 <@Whissi> mgorny: Let's talk about this later. We will have 4 more weeks until this will come up again ;)
13:38 <@WilliamH> ok
13:38 <@WilliamH> moving on.
13:39 <@WilliamH> bug 700364
13:39 <+willikins> WilliamH: https://bugs.gentoo.org/700364 "License council summaries under CC-BY-SA-4.0"; Gentoo Council, unspecified; IN_P; ulm:council
13:40 <@ulm> proposed README file is here: https://700364.bugs.gentoo.org/attachment.cgi?id=613112
13:40 <@ulm> also sent to council@g.o on 2020-01-20 (same text, except for two typo fixes)
13:40 <@ulm> do you want to vote on it, or can I simply commit it?
13:40 <@dilfridge> do it
13:41 <@WilliamH> go for it.
13:41 <@Whissi> +1 for the fixed README :)
13:41 <@slyfox> no need to vote
13:41 <@ulm> ok :)
13:41 <@gyakovlev> vote yes by no voting =)
13:41 <@WilliamH> moving on....
13:41 <@ulm> apart from that, should I reassign the bug to myself?
13:41 <@WilliamH> heh
13:41 <@ulm> still waiting for 4 approvals, which can tak a long time
13:42 <@ulm> *take
13:42  * WilliamH is indifferent about that
13:43 <@WilliamH> If it is assigned to council it will come up in the meetings...
13:43 <@ulm> exactly, I can leave it alone for now, but then it will show up again
13:44 <@Whissi> ulm: You also sent private mails, didn't you? Any bounces or can we expect that former council member at least received the mail?
13:44 <@WilliamH> What does everyone else think?
13:44 <@ulm> Whissi: no bounces, but no answer either
13:44 <@Whissi> OK :/
13:44 <@dilfridge> did vapier reply?
13:44 <@ulm> I've sent private e-mail twice
13:45 <@ulm> dilfridge: https://bugs.gentoo.org/700364#c35 :)
13:45 <@dilfridge> oh wow, that's like a flying pink elephant
13:46 <@WilliamH> He replied so I guess he is ok with it.
13:47 <@ulm> well, I suggest to leave the bug alone, and reassign next month if it's still open then
13:47 <@WilliamH> ok fwm
13:47 <@Whissi> Mh. Wasn't the CC list used as indiciator who still needs to ack? Only calchan left... who are the 4 missing?
13:47 <@slyfox> sounds good. worth adding explicit comment to the bug?
13:47 <@WilliamH> slyfox++
13:48 <@ulm> Whissi: calchan, dberkholz, scarabeus, tanderson/gentoofan23
13:48 <@ulm> slyfox: will do, when I reassign
13:49 <@slyfox> thank you!
13:49 <@WilliamH> ok, moving on...
13:49 <@WilliamH> open floor
13:49  * WilliamH listens
13:49  * veremitz falls over some saucepans.
13:50 < veremitz> oops, sorry.
13:51  * WilliamH bangs the gavel
13:51 <@WilliamH> meeting closed