path: root/meeting-logs/20181209.txt

[20:59:59] <@leio> !proj council
[20:59:59] <+willikins> (council@gentoo.org) dilfridge, k_f, leio, slyfox, ulm, whissi, williamh
[21:00:04] <@leio> Meeting time
[21:00:19] <@leio> Agenda: https://archives.gentoo.org/gentoo-project/message/44d8f1089b18affa9f82f946f444bbe5
[21:00:22] <@leio> 1. Roll call
[21:00:24] <@dilfridge> you, sir, are surprisingly organized. :)
[21:00:26] -*- K_F here
[21:00:27] -*- dilfridge here
[21:00:28] -*- Whissi is here
[21:00:33] -*- leio here
[21:00:36] -*- WilliamH here
[21:01:08] -*- ulm here
[21:01:33] <@leio> slyfox: ping
[21:02:53] <@dilfridge> "Give me a ping, Vasili. One ping only, please."
[21:03:16] <@leio> Moving on, in the interest of avoiding "slacker marks", slyfox should let us know when here :)
[21:03:26] <@leio> 2. Discussing the addition of an AUTHORS file to the main Gentoo package repository
[21:03:48] <@WilliamH> I answered antarus' question on the thread.
[21:04:01] <@leio> I suppose this is sort of coupled with multiline notices allowed or not in Gentoo package repository
[21:04:40] <@leio> So if we go for a suitable AUTHORS file, we can all happily go to just a "Gentoo Authors" copyright notice?
[21:05:05] <@dilfridge> I'm fine with having an AUTHORS file, if it's *only* used for cases where the git headers do not describe the copyright sufficiently
[21:05:10] <@WilliamH> That's what I was told.
[21:05:24] <@WilliamH> Wrt to removing current copyright notices that are already there,
[21:05:36] <@WilliamH> I wouldn't because of things like http://www.photolaw.net/did-someone-remove-the-copyright-notice-from-your-photograph.html
[21:05:42] <@K_F> dilfridge: I'm not so sure, I'd rather like it to be populated with the full list of Authors from git .. otherwise it seems like credit is given to people making most fuzz
[21:05:57] <@ulm> by the systematic of GLEP 76 the AUTHORS file in rsync should list _all_ copyright holders
[21:06:03] <@WilliamH> K_F: it can be opt-in, there isn't a problem with that afaik
[21:06:17] <@dilfridge> as long as the file says clearly at the beginning that it only lists the exceptions ...
[21:06:35] <@K_F> dilfridge: it will be misunderstood by some in any case, it gives a bad feeling image-wise
[21:06:45] <@ulm> well, then we must update the GLEP again
[21:06:51] <@WilliamH> ulm: there is nothing in glep 76 wrt an AUTHORS file.
[21:07:01] <@ulm> what would be the problem with listing everybody?
[21:07:09] <@ulm> WilliamH: there is
[21:07:15] <@WilliamH> ulm: nothing other than it isn't really necessary.
[21:07:22] <@dilfridge> we're not here to define a dogma, we're here to make a feasible and clean solution
[21:07:23] <@K_F> WilliamH: "Projects using this scheme must track authorship in a VCS, unless they list all authors of copyrightable contributions in an AUTHORS file."
[21:07:26] <@ulm> [...] list all authors of copyrightable contributions in an AUTHORS file
[21:07:34] <+NeddySeagoon> WilliamH: It would be good PR.
[21:07:38] <@K_F> WilliamH: note "all authors"
[21:07:54] <@dilfridge> ulm: technically that doesnt say anything about VCS *and* authors file
[21:08:08] <@leio> well, by that reading we don't have to list "all authors" IFF authorship is tracked in a VCS
[21:08:20] <@dilfridge> precisely
[21:08:35] <@leio> that said, "authorship" is a loaded term here, when here we want to track copyright ownership, sort of
[21:08:45] <@ulm> dilfridge: right, but do we want different meanings of the AUTHORS file in different problems?
[21:08:51] <@ulm> *projects
[21:09:13] <@dilfridge> shrug
[21:09:28] <@dilfridge> gentoo.git is kinda special for us
[21:09:38] -*- leio expected more bikeshed to read on this topic from the ml :)
[21:09:58] -*- dilfridge has a pot of tartan paint standing by
[21:10:03] <@WilliamH> dilfridge: :p
[21:10:52] <@K_F> "The following snowflakes have lawyers making things difficult for the project, and as such is listed in this authors fil"
[21:10:55] <@K_F> +e
[21:11:02] <@WilliamH> K_F: :p
[21:11:18] <@dilfridge> in any case I recommend WilliamH should recuse himself from the vote (if anything this is a conflict of interests :P)
[21:11:49] -*- WilliamH was actually going to ask the council about that before the vote.
[21:11:58] <@Whissi> Can we summarize like "Only allowed copyright in ebuild is "<year> Gentoo Authors". If you don't feel represented by "Gentoo Authors" you can add yourself to the new AUTHORS file."
[21:12:09] <@ulm> WilliamH: so, if we have an AUTHORS file, then you're going to remove all SIE copyright lines from ebuilds?
[21:12:12] <@K_F> dilfridge: normally the recusal goes for discussion of the case (access isn't really an issue since we're doing it in public) ..
[21:12:27] <@K_F> dilfridge: not that I believe it matters much in this case (and can actually welcome input on some points..)
[21:12:30] <@WilliamH> ulm: I don't think that's a good idea because of things like http://www.photolaw.net/did-someone-remove-the-copyright-notice-from-your-photograph.html
[21:12:58] <@dilfridge> technically we dont remove it, we just move it to the authors file
[21:12:58] <@ulm> WilliamH: then the AUTHORS file doesn't solve the problem
[21:13:04] <@leio> taking WilliamH as an example - would there be in the AUTHORS file either
[21:13:04] <@leio> 1) William Hubbs
[21:13:04] <@leio> 2) William Hubbs, Sony Interactive Entertainment
[21:13:04] <@leio> 3) William Hubbs and a separate SIE entry (to cover individual free time contributions, and company contributions as a whole for all paid devs); or
[21:13:04] <@leio> 4) William Hubbs as an individual and a "William Hubbs, SIE" separate entries to cover free time and company time per-person
[21:13:08] <@dilfridge> so yes, we can remove it then
[21:13:09] <@WilliamH> ulm: it does going forward.
[21:13:30] <@WilliamH> ulm: SIE hasn't stated that we can't this is just me being conservative.
[21:14:18] <@WilliamH> leio: I don't care about my name personally being in the AUTHORS file.
[21:14:27] <@ulm> leio: I would say, it should be one line "Willliam Hubbs" and one line "Sony Interactive Entertainment"
[21:14:28] <@WilliamH> leio: I don't know of any of us who do.
[21:14:50] <@leio> it was an example that is known to all; for this purpose, lets say you want it
[21:14:58] <@dilfridge> and the "William Hubbs" line would be unneeded since it's in git
[21:15:07] <@dilfridge> (and unwanted)
[21:15:13] <@K_F> dilfridge: so would sony be if they just used sony email address in Authors
[21:15:19] <@WilliamH> If I did want it, yes there would be two lines.
[21:15:37] <@K_F> in git... but.. yeah, I'd say it should only be SIE... and then in commit mark the commits relevant
[21:15:53] <@dilfridge> that's fine with me too, I even dont object having arbitrary e-mails as committer
[21:16:03] <@slyfox> leio: pong. i'm ehre
[21:16:16] -*- dilfridge hands slyfox the paintbrush
[21:16:20] <@WilliamH> heh
[21:16:21] <@K_F> dilfridge: committer would cause matching issues for keyblock lookup etc, but authors is free
[21:16:28] <@K_F> dilfridge: and technically more correct anyways
[21:16:33] <@dilfridge> hm ok
[21:16:43] <@WilliamH> Yeah committer emails should be *@g.o
[21:16:46] <@ulm> also, no e-mail addresses in the AUTHORS file, because we don't have any in the copyright lines either
[21:16:58] <@K_F> ulm: indeed
[21:17:12] <@leio> There were points raised about multi-company corporations having same domain name, but different legal entities
[21:17:29] <+antarus> ulm: I don't understand that restriction
[21:17:54] <@ulm> avoid address harvesting?
[21:18:38] <@WilliamH> I would say leave it up to the person or entity that wants an entry in the file.
[21:18:43] <@ulm> and I don't think that e-mail addresses are required legally
[21:18:45] <+antarus> ulm: I want to avoid *banning* them
[21:19:10] <@WilliamH> antarus++
[21:19:18] <@WilliamH> Leave it up to the entity.
[21:19:34] <@WilliamH> There's no reason to ban email addresses.
[21:19:34] <@leio> this is all interconnected to how the file is even made
[21:19:36] <+antarus> (discouraging their use seems fine)
[21:19:37] <@ulm> WilliamH: and how would you state that in a commit?
[21:19:45] <@leio> it's not really up to the entity if we go with auto-generation choice
[21:19:47] <@WilliamH> ulm: ?
[21:19:53] <@dilfridge> no autogeneration
[21:19:55] <@ulm> leio: exactly
[21:20:05] <@WilliamH>  I would just state in the top of the file that an email address is optional.
[21:20:22] <@K_F> leio: it is if using a commit header for it, or even if using Authors field but stripping email section
[21:20:25] <@dilfridge> :/
[21:20:32] <@WilliamH> dilfridge++ wrt no auto generation.
[21:20:43] <@ulm> my idea would be to autogenerate it for rsync, adding explicit entries from the file present in git
[21:21:08] <@WilliamH> ulm: no auto generation. It would just be a file that would be maintained manually.
[21:21:15] <@K_F> the issue with autogeneration is it inolves quite a bit of processing to go through and update, and possible some more complex logic if caching
[21:21:24] <@leio> either way, I'm not sure if and what we could be voting on here; we could vote for an AUTHORS file in general, with details still to be determined, but... :)
[21:21:31] <@slyfox> no harder than manifest generation
[21:21:32] <@ulm> WilliamH: that would be a waste of time IMHO
[21:21:38] <@K_F> so I'm not necessarily sure I'm a big fan of it.. but we need a good header for the file if not
[21:21:53] <+antarus> I would prefer you not vote on specific technical implementations
[21:22:00] <@ulm> K_F: you've suggested a good one above :)
[21:22:06] <@K_F> ulm: :)
[21:22:10] <@WilliamH> antarus++
[21:22:20] <@WilliamH> It isn't up to us to vote on implementations
[21:22:29] <+antarus> delegate generation to someone, they can build an impelmentation, and we can tweak it as needed
[21:22:38] <+antarus> I don't see the point in trying to design it here
[21:22:42] <@K_F> well, on some level it is, but we're talking about the level of complexity to add more in general here
[21:22:50] <@WilliamH> antarus++
[21:23:10] <@leio> then who is going to decide if this will be autogenerated or not?
[21:23:18] <+antarus> you can decide that
[21:23:26] <@K_F> personally I'm in favor of manual if doing a proper header for file
[21:23:35] <@dilfridge> we decide everything and antarus implements it
[21:23:36] <+antarus> I'm just saying don't sweat the technical details
[21:23:41] <+antarus> oh I'm not volunteering
[21:23:42] <+antarus> ;)
[21:23:54] <@WilliamH> I'm with k_f on this, it should be manual.
[21:23:56] <+antarus> because there isn't enough time to design the technical implementation in this meeting, and i think its folly to try ;)
[21:24:09] <@K_F> but at the same time I want the commits related to this to be tracked in git also
[21:24:16] <+antarus> (alternatively, we could just turn off rsync mirroring)
[21:24:24] <@K_F> and it will likely be used for some statistics in blog posts etc down the road
[21:24:36] <@ulm> the key question is if we want a complete listing, or opt-in
[21:24:44] <@dilfridge> antarus: rumor says you're working on that anyway :P
[21:24:45] <@WilliamH> K_F: Sure, it would be in gentoo.git, so changes would go in git.
[21:24:46] <@Whissi> I don't understand why we need a auto-gen version: My understanding is that header will always be "Gentoo Authors" and only people/company who think they are special and want to be painted on an ad wall can request to get added to AUTHORS file if they want to. That's all.
[21:24:58] <@K_F> WilliamH: no, each commit relevant for it, not the file itself
[21:24:59] <@WilliamH> Whissi++
[21:25:20] <@WilliamH> K_F: ?
[21:25:20] <@K_F> WilliamH: i.e Copyright-Attribution: Sony .... in commit
[21:25:35] <@ulm> antarus: would Gentoo Foundation want to be listed? :)
[21:25:38] <+antarus> Whissi: your rhetoric is strong today ;)
[21:25:40] <@K_F> or using authors email address for it (but then there isn't specific mapping)
[21:25:44] <@slyfox> some projects (like xmms2) have presubmit tests: author should already in AUTHORS file to get change in. You normally add yourself once
[21:25:49] <@WilliamH> K_F: ah, that's already happening...
[21:26:02] <@Whissi> antarus: Sorry. :)
[21:26:10] <+antarus> ulm: not to my knowledge
[21:26:24] <@WilliamH> antarus: I would think that should happen by default.
[21:26:32] <@ulm> so only one line, for Sony?
[21:26:42] -*- antarus is confused
[21:26:44] <+antarus> one line where?
[21:26:46] <+antarus> in the AUTHORS file?
[21:26:50] <+antarus> it would start empty, no?
[21:26:51] <@ulm> yes
[21:27:04] <@K_F> well, empty sans header
[21:27:08] <+antarus> (assuming its the opt-in variety)
[21:27:54] <@WilliamH> one sec folks, I will put together what I propose for a start of an AUTHORS file.
[21:28:07] <@K_F> I'd say header should have a description of how to grab authors in git, and just general specification .. and then preferably an introduction of the ones listed
[21:28:46] <@WilliamH> give me a minut...
[21:28:48] <@ulm> K_F: that sounds complicated
[21:28:58] <@K_F> ulm: how so?
[21:29:19] <@ulm> "introduction of the ones listed"?
[21:29:24] <@K_F> ulm: the snowflakes line above
[21:29:30] <@ulm> ah :)
[21:29:30] <@Whissi> K_F: But now imagine you have such a marker... you still don't know which value should be shown in AUTHORS file.
[21:29:44] <@K_F> The following can for various reasons not be tracked using the standard method, so this additonal work was caused by;
[21:30:06] <@leio> if we go with opt-in, I see various entities wanting themselves listed - for similar reasons why with extra entities in copyright notices, others will eventually want themselves listed as well
[21:31:00] <@leio> so I don't see any (eventual) relationship to "snowflakes", nor do I think we should call them as such even in jest in the context of a perfectly reasonable AUTHORS file
[21:31:08] <@WilliamH> leio: sure, we just add them when they request it.
[21:31:36] <+antarus> I presumed the council members were being amusing and we would not actually write that in the authors file
[21:31:39] <+antarus> fwiw ;)
[21:32:00] <@K_F> The following copyright holders can for various reaons not be tracked using the standard git method [that is already defined above]...;
[21:32:18] <@K_F> but yes, internal codeword; "snowflakes"
[21:33:00] <@WilliamH> So how would we extract authors from git? Is there a quick one-line command someone could run?
[21:33:30] <@slyfox> I'm a bit lost on discussion. Is addinion of AUTHORS already agreed on (regardless of contents)?
[21:33:39] <@leio> (I meant in our discussions as well in the context of AUTHORS)
[21:33:42] <+antarus> WilliamH: the command exists
[21:34:04] <@Whissi> slyfox: Yes, because this allows us to revert ebuilds to just one single copyright line "Gentoo Authors".
[21:34:18] <@leio> No, the addition of AUTHORS has not been explicitly voted on as of yet
[21:34:22] <@dilfridge> we should probably vote on that
[21:34:56] <@K_F> dilfridge: we need to vote on it, but to me the opt-in variant also depends on how that is introduced in header
[21:35:03] <@leio> I believe for many of us the vote depends on what we end up with copyright notices for Gentoo package repository
[21:35:06] <@Whissi> I took the fact that we discuss about implementation details that we have an agreement somehow...
[21:35:19] <@Whissi> But yes, not vote yet.
[21:35:39] <@dilfridge> K_F: type a proposal into a paste and put it up
[21:36:19] <+antarus> I am off, good luck with proposal and vote
[21:36:23] <@K_F> dilfridge: I've posted the general idea above, but writing the specific git part I'd say leave for implementation later (that'd be just how to extract it anyways)..
[21:36:23] <@WilliamH> past coming...
[21:37:03] <@WilliamH> The only thing missing is the git command to extract authors:
[21:37:08] <@WilliamH> http://dpaste.com/2C1DK5T
[21:37:21] <@K_F> but the file shouldn't be standalone, it should reference that (i) this is a partial list of copyright holders, (ii) The full list of authors can be extraced from git (iii) these are "special"
[21:37:25] <@WilliamH> One more thing I'll add too is a request to keep it sorted.
[21:38:03] <@leio> I don't agree with (iii)
[21:38:21] <@K_F> on some level I'm wondering if we shouldn't require a copyright header in the git commit corresponding to it for new commits to track how much is actually contributed
[21:38:59] <@K_F> so when committing things corresponding to this the git commit should contain something like Copyright-Attribution: Sony Interactive Entertainment Inc.
[21:39:31] <@dilfridge> ehm that link doesnt work for me
[21:39:35] <@WilliamH> We are already doing that, there should be some commits like that in the tree.
[21:39:36] <@slyfox> ebuild copying makes all file attributes to that Copyright-Attribution.
[21:39:55] <@WilliamH> I think we are just using Copyright:
[21:39:57] <@slyfox> while frequently it's a copy of existing file (and git does not track it)
[21:40:23] <@K_F> slyfox: fair enough, but at least it shows the work somehow
[21:40:30] <@WilliamH> I haven't written anything in the tree that is copyrightable since we started it so I haven't used the header. :-)
[21:41:10] <@Whissi> I am against a "Copyright: ..." line in commit messages.
[21:41:16] <@K_F> slyfox: I'd likely be interested in doing some analysis on the impact down the road and write up a blog-post at least
[21:42:07] <@K_F> "this year the following snowflakes in the authors file contributed X amount of commits, changing..."
[21:42:21] <@WilliamH> Whissi: k_f has a good point.
[21:42:30] <@WilliamH> That could be PR
[21:42:36] <@Whissi> Why making things complicated? We wanted clean ebuilds. The AUTHORS file will allows us to have clean ebuilds again. I don't care about anyone who want to get listed in that file. On my boxes I'll probably filter that file ;)
[21:42:51] <@dilfridge> well,
[21:42:55] -*- ulm thinks that any form of opt-in will end up in a mess, or in some strange partial selection of copyright holders
[21:43:12] <@dilfridge> since the vcs history is git-only, the authors file can be git-only too
[21:43:19] <@Whissi> ulm: I share your concerns but I don't care.
[21:43:22] <@ulm> so I'll vote against an AUTHORS file unless it will list all authors
[21:43:27] <@slyfox> For your amusement it's how XMMS2 tracks AUTHORS: https://github.com/chrippa/xmms2/blob/master/AUTHORS
[21:44:01] <@K_F> slyfox: :)
[21:44:02] <@slyfox> presubmit always tells new author to add stanza there
[21:44:48] <@leio> Do we need any tags if the author e-mail could tell too?
[21:45:06] <@leio> in this case, I mean the AUTHORS file would have the e-mail for these cases too, so that does the mapping
[21:45:16] <@dilfridge> brb
[21:45:21] <@K_F> leio: well, they want company name listed, which at least email in author doesn't tell, but likely the Author field itself could stripping email
[21:45:30] <@WilliamH> leio: in the SIE case, sony.com doesn't imply Sony Interactive Entertainment.
[21:45:58] <@slyfox> you should change your email :)
[21:46:05] <@leio> WilliamH: yes, I mean it could imply that in AUTHORS file. AUTHORS file would be listing e-mails (with name) associated with company name
[21:46:11] <@WilliamH> leio: There is Sony Mobile, Sony Imageworks, etc etc
[21:46:46] <@leio> I see a lot of nuances and discussion, and we have other fun topics on the agenda too; can we conclude something?
[21:46:51] <@WilliamH> leio: Not Necessarily, an AUTHORS file doesn't have to list emails.
[21:47:28] <@leio> sure, and I'm saying that if it does for your case, it would provide a concrete mapping of your work e-mail to SIE (as opposed to mobile, imageworks, whatever)
[21:47:29] <@WilliamH> Can we get the file into the tree and deal with details later?
[21:47:37] <@K_F> no
[21:47:59] <@K_F> but I'm tempted to follow ulm and say it needs to list all, and add that it lists it by authors field, stripping the <> email part
[21:48:01] <@leio> time for a working group? *g
[21:48:18] <@slyfox> looks like agenda proposal as-is does not state precise function of AUTHORS file to define entry contents (emails? legal names? PR blurb?). If it would it might be slightly simpler.
[21:48:38] <@WilliamH> heh, did you see my paste above?
[21:48:41] <@WilliamH> slyfox: ^^
[21:48:55] <@slyfox> yeah, what is 'the name'?
[21:49:04] <@WilliamH> http://dpaste.com/2C1DK5T
[21:50:00] <@Whissi> So let's reject AUTHORS file for now and go back to drawing board (mailing list) to come back with implementation details so we can move on with this meeting?
[21:50:35] <@K_F> I'm fine with that, those needing it should come up with a complete proposal
[21:50:50] <@ulm> "[The author] may determine whether the work shall bear a designation of authorship and which designation is to be used." (quoting section 13 of German Urheberrechtsgesetz)
[21:51:16] <@WilliamH> ulm: doesn't that paste I showed allow that?
[21:51:19] <@ulm> probably different in the U.S.
[21:51:24] *** Mode #gentoo-council +v rich0 by ChanServ
[21:51:51] <@WilliamH> ulm: http://dpaste.com/2C1DK5T
[21:52:01] <@WilliamH> if you didn't see it.
[21:52:08] -*- leio notes that this paste will not be visible to the readers of the raw meeting log
[21:52:21] <@K_F> leio: or for that matter in archive
[21:52:28] <@dilfridge> pasteit here once
[21:53:09] <@WilliamH> ok hang on
[21:53:13] <@dilfridge> i cant openthe link
[21:53:27] <@Whissi> #
[21:53:27] <@slyfox> public_html link is coming
[21:53:27] <@Whissi> # This is a list of copyright holders for Gentoo Packages, in addition
[21:53:27] <@Whissi> # to the authors which can be Extracted from git by running the
[21:53:27] <@Whissi> # following command in the repository:
[21:53:29] <@Whissi> #
[21:53:31] <@Whissi> #
[21:53:33] <@Whissi> # This list is opt-in, so if you want to be listed, please file a bug at
[21:53:35] <@Whissi> # https://bugs.gentoo.org.
[21:53:37] <@Whissi> #
[21:53:39] <@Whissi> # Each entry contains the name and an optional email address.
[21:53:41] <@Whissi> #
[21:53:43] <@Whissi> Gentoo Foundation, Inc.
[21:53:45] <@Whissi> Sony Interactive Entertainment Inc.
[21:53:52] <@WilliamH> #
[21:53:52] <@WilliamH> # This is a list of copyright holders for Gentoo Packages, in addition
[21:53:52] <@WilliamH> # to the authors which can be Extracted from git by running the
[21:53:52] <@WilliamH> # following command in the repository:
[21:53:52] <@WilliamH> #
[21:53:55] <@WilliamH> #
[21:53:57] <@WilliamH> # This list is opt-in, so if you want to be listed, please file a bug at
[21:54:00] <@WilliamH> # https://bugs.gentoo.org.
[21:54:02] <@WilliamH> #
[21:54:05] <@WilliamH> # Each entry contains the name and an optional email address.
[21:54:07] <@WilliamH> # Please keep this list sorted.
[21:54:10] <@WilliamH> #
[21:54:12] <@WilliamH> Gentoo Foundation, Inc.
[21:54:15] <@WilliamH> Sony Interactive Entertainment Inc.
[21:54:17] <@leio> my turn :)
[21:54:20] <@K_F> and now, one more..
[21:54:59] <@ulm> sorted how? "LC_COLLATE=en_US.utf8 sort"?
[21:55:20] <@leio> Alright, we have discussed plenty now; please come up with a concrete proposal now for next meeting or earlier
[21:55:41] <@leio> if time permits, we can discuss later again, but we have to move on to other items as well
[21:55:44] <@K_F> the proposal is for it to be a partial list, not a list of, and Extracted should not have capitaliziation since it isn't defined in document etc etc... but
[21:55:45] <@WilliamH> That is the proposal. No one has said what is wrong with it?
[21:55:59] <@K_F> leio++;
[21:56:20] <@dilfridge> why not vote on that ^ ?
[21:56:23] <@K_F> WilliamH: thats only a proposal for the file itself, not other aspects surrouinding it
[21:56:38] <@K_F> surrounding*
[21:56:44] <@ulm> WilliamH: it implies that anyone whose name can be extracted from git _cannot_ be listed
[21:56:59] <@dilfridge> what remains unclear?
[21:57:01] <@WilliamH> ulm: that's simple to fix.
[21:57:16] <@dilfridge> why fix it?
[21:57:40] <@ulm> well, maybe it's just fine like that
[21:57:48] <@slyfox> Is 'the name' supposed to match git author or anyhow related to commits? same for emails
[21:57:55] <@ulm> and optionally expand the file in rsync
[21:58:08] <@slyfox> or one is supposed to do The Reasearch what was the contribution if need arises?
[21:58:51] <@K_F> slyfox: that is where I prefer it is tracked, I think my current preference is for author field to be the company name in these cases..
[21:59:14] <@K_F> alternative would be a copyright attributiation part of the commit, but I see how that can be misunderstood with file copy et
[21:59:17] <@K_F> etc
[21:59:32] <@leio> I personally think the specifics deserve some wider discussion based on such more concrete proposal
[21:59:42] <@leio> not coming up with it during the meeting and then immediately deciding on it
[21:59:48] <@slyfox> yup
[21:59:50] <@K_F> leio: agreed
[21:59:52] <@leio> either way, we have to move on
[21:59:56] <@leio> 3. 13.0 profiles removal
[22:00:05] <@WilliamH> K_F: We can't really mandate what the field is, but if it isn't a git author, I would support a Copyright: line in the commit message.
[22:00:19] <@leio> What has been the traditional deprecation period?
[22:00:29] <@K_F> WilliamH: it has to be a definition for when to use what in that case at least
[22:00:37] <@WilliamH> moving on...
[22:00:40] <@K_F> WilliamH: and what it means to provide a copyright line etc etc...
[22:00:58] <@WilliamH> leio: a year afaik.
[22:00:59] <@slyfox> for 13.0 profile removal is there a tracker bug that shows what is actually broken for 17.0?
[22:01:07] <@ulm> there are still packages that don't build with 17.0 profiles
[22:01:09] <@K_F> but yeah. profile removal.. I saw some points of broken packages, and it doesn't really cost much to keep it
[22:01:30] <@leio> I don't see a problem with removing deprecated profiles, but some 13.0 profiles aren't even deprecated yet, so that doesn't really get rid of 13.0 as a whole
[22:01:32] <@ulm> there was some lisp bug just last week (clozurecl IIRC)
[22:01:34] <@K_F> so lets come back to it at another meeting, but we can encourage bug filings for packages failing 17.0
[22:01:40] <@dilfridge> ++
[22:02:01] <@slyfox> there are many options. 1) remove it today, 2) switch to exp, give a heads-up in gentoo-dev@ and remove later 3) your option
[22:02:26] <@WilliamH> I think part of this depends on what the packages are that are breaking...
[22:02:34] <@leio> for example amd64 13.0 profiles seem to have been marked as deprecated on 6th January 2018
[22:02:43] <@leio> while mips 13.0 profiles still aren't deprecated today
[22:02:51] <@leio> nor arm 13.0 profiles
[22:02:53] <@WilliamH> Obviously if things in base-system don't build with 17.0 that is a big show stopper.
[22:02:59] <@Whissi> ulm: That bug 672454 was closed as resolved btw.
[22:03:02] <+willikins> Whissi: https://bugs.gentoo.org/672454 "dev-lisp/clozurecl-1.11.5: fails to build on ~x86 in 17.0 profile"; Gentoo Linux, Current packages; RESO, FIXE; grozin:common-lisp
[22:03:44] <@K_F> yeah, I believe mgorny pointed out it just needed a --no-pie
[22:03:45] <@dilfridge> mips and arm was still work in progress when I took care of the other arches
[22:03:47] <@leio> dilfridge: do you think we can remove the specific profiles you deprecated back in January after a year has passed?
[22:03:47] <@WilliamH> leio: the amd64 ones can go away in Jan then.
[22:04:03] <@leio> or no big point if 13.0 as a whole has to stick around
[22:04:08] <@dilfridge> definitely, unless bigger breakage is known
[22:04:11] <@K_F> so we really want to split up by arches?
[22:04:36] <@dilfridge> well, why not... 99% of users run amd64 anyway
[22:04:40] <@K_F> I don't.. I'd say we remove when latest deprecation periode is over.. but rule is it needs an upgrade path, not that it has to stay deprecated for 12 months
[22:05:07] <@K_F> so how difficult is it to switch is more interesting to me than when it was deprecated
[22:05:25] <@K_F> and is it possible to provide e.g a binhost with switched packages to replace in-place
[22:05:32] <@dilfridge> ok so let's deprecate the rest now, and remove all in january
[22:05:50] <@leio> that's complicated when there are no 17.0 stage3s for some yet even
[22:05:55] <@slyfox> sounds good but please send out an announcement to -dev@ and -user@ and explicitly list a tracker
[22:05:58] <@dilfridge> right
[22:06:09] <@K_F> leio: that is indeed a good point
[22:06:26] <@WilliamH> leio: why are ther not 17.0 stage 3's for some?
[22:06:30] <@WilliamH> there *
[22:06:33] <@dilfridge> because.
[22:07:02] <@WilliamH> dilfridge: slow arches?
[22:07:16] <@dilfridge> yes
[22:07:40] <@dilfridge> I'm wondering what the status of catalyst autobuilds on all the arches is
[22:07:55] <@dilfridge> in principle it should be able to generate stage3, right?
[22:08:02] <@leio> there are 17.0 stages for some arm's out now, but not all (some listed on downloads page are 13.0 ones from 2016); still nothing for mips
[22:08:07] <@leio> I'm not familiar with others
[22:08:17] <@dilfridge> !expn mips
[22:08:17] <@slyfox> you can subscribe to releng@ and see what works/what does not
[22:08:18] <+willikins> dilfridge: mips = kumba,alexxy,leio,mattst88,blueness,zlogene,slyfox,
[22:08:30] <@dilfridge> lots of people for a dead arch
[22:08:35] <@leio> I have seen recent action in reviewing various exotic arch catalyst autobuilds (ppc and s390 in particular)
[22:08:48] <@slyfox>  !xpn does not do what you expect
[22:08:51] <@leio> (I meant ppc64 too)
[22:09:00] <@dilfridge> it lists alias members
[22:09:07] <@slyfox> what is not project members
[22:09:09] <@WilliamH> !proj mips
[22:09:10] <+willikins> WilliamH: (mips@gentoo.org) blueness, kumba, leio, mattst88, zlogene
[22:09:57] <@leio> I think "stable" arches are mostly on the way to being all on 17.0
[22:10:16] <@leio> but that doesn't mean we have to pull the carpet from under the others
[22:10:36] <@slyfox> toolchain should mostly work thus it should not be big of an issue to switch to 17.0
[22:11:15] <@leio> ok, I will (if no-one else does) follow-up on this on the ml
[22:11:18] <@leio> and lets move on
[22:11:19] <@K_F> well, to me it sounds like, lets encourage switch but not vote on anything today
[22:11:43] <@leio> 4. https://bugs.gentoo.org/637328 - Update of "GLEP 14: security updates based on GLSA" and related discussion
[22:11:48] <@slyfox> sounds fine. but have exact date to aim for would also steer people faster :)
[22:12:08] <@WilliamH> slyfox++
[22:12:14] <@Whissi> Nothing to vote on regarding GLEP 14 yet. Discussion is now public, but still not finished.
[22:12:16] <@K_F> right, so the security project published its current GLEP draft on ML.. the structure of the project impacts how GLSAs are impacted
[22:12:24] <@K_F> so nothing for us at this meeting
[22:12:52] <@leio> this "stable" arch vs "security supported" keeps coming up
[22:13:08] <@dilfridge> I'll give the arches.desc GLEP another try over the holidays
[22:13:11] <@slyfox> yeah, that has to be explicitly defined
[22:13:17] <@leio> and was requested to agenda a bit late
[22:13:23] <@dilfridge> that's somehwat related
[22:14:54] <@leio> ok, lets move on then, I expect some on this topic on open floor
[22:15:08] <@leio> 5. open bugs with council involvement
[22:15:45] <@leio> bug 637328 we just covered
[22:15:47] <+willikins> leio: https://bugs.gentoo.org/637328 "GLEP 14 needs to be updated"; Documentation, GLEP Changes; IN_P; mgorny:security
[22:16:00] <@leio> bug 642072
[22:16:02] <+willikins> leio: https://bugs.gentoo.org/642072 "[Tracker] Copyright policy"; Gentoo Council, unspecified; IN_P; mgorny:council
[22:16:15] <@leio> is a tracker, but on this I'm also concerned about bug 670702
[22:16:18] <+willikins> leio: https://bugs.gentoo.org/670702 "sys-apps/util-linux-2.33: Header does not comply with GLEP 76"; Gentoo Linux, Current packages; RESO, FIXE; ulm:base-system
[22:16:41] <@leio> which was closed after previous meeting
[22:16:44] <@WilliamH> leio: ulm said that it does comply now.
[22:17:00] <@ulm> WilliamH: with GLEP 76
[22:17:01] <@WilliamH> leio: I wouldn't have closed it otherwise.
[22:17:10] <@ulm> not necessarily with tree policy
[22:17:20] <@WilliamH> ulm: the bug was wrt glep 76
[22:17:27] <@leio> I disagree on it complying with GLEP 76 too, but I'm bringing this up in relation to the AUTHORS discussion
[22:17:28] <@WilliamH> ulm: not tree policy
[22:17:44] <@Whissi> I disagree that "RESOLVED:FIXED" was correct but once we have solved the AUTHORS file thing, this will be "reverted" (or "migrated" with the next normal ebuild update).
[22:18:20] <@slyfox> sound good
[22:18:32] <@K_F> Whissi: should it be re-opened to be on radar in tracker then?
[22:18:46] <@ulm> K_F: we have it on radar
[22:18:46] <@slyfox> should we have a bug about AUTHORS file as well then to have it as blocker?
[22:18:58] <@slyfox> might also ease back-and-fort duscussion as well
[22:19:00] <@leio> actually it's currently not marked as blocker of the copyright tracker
[22:19:19] <@WilliamH> I don't think it should be.
[22:19:24] <@WilliamH> leio: ^^
[22:20:19] <@K_F> I'd say we re-open and add it to tracker
[22:20:31] <@K_F> then we can always come back to it when authors is decided
[22:20:34] <@WilliamH> K_F: negative, this has nothing to do with the copyright policy.
[22:20:35] <@K_F> so no further action
[22:20:50] <@leio> retitled as needed; or new bug for the tracker, if someone feels that better
[22:20:50] <@K_F> WilliamH: it does, as far as I can see and interpret it it currently does not comply
[22:21:37] <@WilliamH> ulm agreed with me in a discussion that this does comply with glep 76.
[22:21:40] <@leio> I also think it does NOT comply right now.
[22:21:51] <@WilliamH> not tree policy, but glep 76.
[22:21:55] <@K_F> neither
[22:22:02] <@leio> yes, I believe it does not comply with either.
[22:22:27] <@leio> while not complying with glep 76 appears to be due to strict reading of the GLEP, not the intention of the GLEP authors
[22:22:31] <@WilliamH> I still think you can't touch the copyrights in that ebuild though because of the other link I posted earlier.
[22:22:46] <@ulm> K_F: leio: IMHO a notice like in the following example does comply with GLEP 76: https://gitweb.gentoo.org/proj/ebuild-mode.git/tree/ebuild-mode.el
[22:23:31] <@Whissi> Technically I would agree that we have to re-open but for me it is not required and if it will help to keep some of us happy I would keep it closed. As said, there are some people like me who are maintaining a list of packages we will "fix" once we have AUTHORS file.
[22:23:40] <@ulm> (I would never use that for an ebuild, though)
[22:24:17] <@leio> I don't think it complies with a strict reading of glep 76 either; but that feels like a matter of clarifying the glep as an editorial change, perhaps
[22:24:37] <@K_F> ulm: not reading glep 76
[22:24:48] <@WilliamH> We got ourselves into a mess by having glep 76 then having a separate tree policy on top of it.
[22:25:07] <@K_F> well, that is natural, since glep covers all projects and tree is special case
[22:25:08] <@leio> albeit I don't see why that ebuild-mode.el would comply with glep76, but not what we have in util-linux now
[22:25:14] <@K_F> so more strict requirement there makes sense
[22:25:32] <@K_F> but yeah, I don't see how it would comply with it either
[22:25:44] <@leio> oh
[22:25:56] <@leio> I mixed up who said it from double nick highlight
[22:26:50] <@leio> I don't think ebuild-mode.el complies with GLEP 76; but that's probably an error of glep wording that should be fixed for non-ebuild stuff
[22:27:17] <@WilliamH> I'm looking at the glep again.
[22:27:33] <@ulm> leio: what would you want it to say? "Copyright 2006-2018 <list of authors>"?
[22:27:43] <@leio> Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]
[22:28:02] <@K_F> ulm: yes, that is what the glep mandates
[22:28:12] <@leio> I don't want it to say that there; I would want that for ebuilds (or rather Gentoo Authors)
[22:28:28] <@leio> but that's what the glep currently mandates by K_F and my reading of it.
[22:28:51] <@WilliamH> The problem is, different contributors can have different years.
[22:29:05] <@WilliamH> e.g. in the util-linux ebuild in question.
[22:29:06] <@leio> that's not a problem, it can be earlier and latest year range.
[22:29:16] <@K_F> WilliamH: then Gentoo Authors is likely more appropriate
[22:29:19] <@leio> you are merely declaring it a problem, while it's not.
[22:29:24] <@K_F> but the year range is mostly irrelevant
[22:29:45] <@leio> anyways, this is why it doesn't comply with glep 76; the glep clearly says
[22:29:48] <@leio> "All copyrightable files included in Gentoo projects must contain appropriate copyright and license notices, as defined by this policy"
[22:29:54] <@leio> _as defined by this policy_
[22:30:03] <@WilliamH> The latest year is what is relevant I guess, but why do we have ranges in that case?
[22:30:06] <@leio> nowhere in _this policy_ it gives any provisions for multiple copyright notices
[22:30:23] <@ulm> leio: well, the real reason for that example is that I didn't want to make it "my name and others"
[22:30:42] <@WilliamH> That ebuild should just read Copyright 2018 Gentoo Authors if you want to force that.
[22:30:45] <@ulm> and there are almost no lines of the original author left
[22:31:09] <@ulm> so "<original author> and others" wouldn't be appropriate either
[22:31:13] <@K_F> if encountering that file based on the spec I'd throw an error as non-conforming, thats all I'm saying :)
[22:31:14] <@WilliamH> Another thing to consider is,
[22:31:15] <@leio> instead it defines "A proper copyright notice reads: Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]"
[22:31:24] <@leio> and only gives an option to go with "Gentoo Authors" instead
[22:31:39] <@K_F> we don't really need to spend much time on it, but thats what the glep says, so gentoo authors should likely be used
[22:31:46] <@dilfridge> ++
[22:31:47] <@leio> I am saying it does not comply with it right now; I'm not saying the glep shouldn't allow this for your non-ebuild case
[22:32:01] <@WilliamH> # Copyright <years> William Hubbs, Sony Interactive Entertainment, name2, name3, name4, name5 and others...
[22:32:10] <@ulm> leio: yeah, but for a file imported from an external source we'd want to leve the original notice intact
[22:32:15] <@ulm> *leave
[22:32:15] <@WilliamH> Now you have a qa violation for line length
[22:32:17] <@leio> but the glep doesn't allow it.
[22:32:28] <@leio> WilliamH: you just wrap it...
[22:32:51] <@leio> I'm claiming glep 76 doesn't allow for multiple copyright notices; I'm not saying it doesn't allow multiple lines due to wrapping of one single copyright notice
[22:33:08] <@K_F> leio: exactly
[22:33:08] <@ulm> there are also licenses like CC-BY-SA that explicitly require not to touch any previous notices
[22:33:15] <@WilliamH> leio: Do you want to possibly be accused of dmca violations because you removed someone's notice?
[22:33:16] <@leio> I also believe glep 76 should allow for traditional multi-line copyright notices for the imported stuff and other such traditional uses; but it doesn't right now
[22:33:25] <@K_F> ulm: sounds like a good starting point for a revised GLEP :)
[22:33:52] <@Whissi> WilliamH: You are mixing things. We explained multiple times that GLP-2 allows us to change files.
[22:33:52] <@K_F> it is currently not allowed
[22:33:56] <@ulm> K_F: yeah, looks like that point should be clarified
[22:34:00] <@leio> (e.g. eudev copyright notices violate glep too)
[22:34:35] <@WilliamH> Whissi: Yes, it does, but again I don't think that would apply to copyright info.
[22:34:38] <@dilfridge> ok so we learned something and can improve things now?
[22:34:46] <@K_F> WilliamH: glep covers whole file
[22:34:51] <@K_F> WilliamH: ehrm, gpl
[22:34:57] <@K_F> comments aren't special
[22:35:35] <@WilliamH> K_F: case-in-point the issues we had with eudev when people tried to strip out copyright notices.
[22:35:53] <@K_F> WilliamH: yes, it wasn't necessarily a legal issue, it was a bad PR move
[22:35:59] <@leio> that was a PR nightmare, not necessarily a law infraction
[22:36:03] <@ulm> GPL-2 says "You may modify your copy or copies of the Program or any portion of it"
[22:36:37] <@ulm> and to "publish on each copy an appropriate copyright notice"
[22:36:46] <@WilliamH> ulm: with that logic, if I want to, I could release my own Linux kernel with only my name in the copyrights?
[22:36:56] <@K_F> WilliamH: sure
[22:37:12] <@ulm> WilliamH: I guess that wouldn't be an "appropriate copyright notice"
[22:37:14] <@ulm> but IANAL
[22:37:14] <@dilfridge> well, in the case of ebuilds the attribution can be moved into an authors file
[22:37:45] <@dilfridge> if that's noted in the commit message, I see no problems with it
[22:38:10] <@K_F> we'll come back to that when a more complete proposal is made anyways
[22:38:25] <@dilfridge> ok are we done now?
[22:38:29] <@K_F> but in the mean time I'd say the bug should be re-openened
[22:38:35] -*- dilfridge feels well done
[22:38:53] -*- K_F leaves it for chair if there are other things left
[22:38:57] <@WilliamH> K_F: That will probably be a glep change, not an ebuild change.
[22:39:15] <@K_F> WilliamH: well, that works as well
[22:39:17] <@leio> Lets file a new bug about the GLEP wording, block the tracker and go from there; we can "See also" the util-linux bug
[22:39:32] <@K_F> sounds good
[22:39:37] <@leio> ok, moving on
[22:39:37] <@WilliamH> Do you want me to work on th e glep?
[22:39:40] -*- WilliamH volunteers
[22:39:52] <@leio> we have glep editors to drive this, I suppose?
[22:40:00] <@K_F> WilliamH: since you're the one wanting it changed, sure.. propose it sometime
[22:40:04] <@K_F> leio: well, it requires a champion
[22:40:11] <@dilfridge> the editorial department is standing by
[22:40:15] <@ulm> WilliamH: I'd rather not, because you have a conflict of interest there
[22:40:38] <@K_F> conflict of interest doesn't really block working on something that is voted on by council anyways
[22:40:56] <@WilliamH> K_F++
[22:41:07] <@dilfridge> that, c.o.i. is more about the vote
[22:41:09] <@leio> maybe the previous champions then? It's about getting it to state clearly what they intended in the first place
[22:41:22] <@WilliamH> dilfridge++
[22:41:33] <@ulm> I can work on an updated wording
[22:41:44] <@leio> Thanks, moving on
[22:41:45] <@dilfridge> how about you just talk to each other?
[22:41:45] <@leio> 6. Open floor
[22:41:47] <@ulm> together with current co-authors
[22:42:10] -*- dilfridge sees the floor open up and swallow the discussion
[22:42:44] <@slyfox> I feels like council meetings spend disproportionate amount of time discusiong copyright-related topics without much progress. What can we do to shrink them down?
[22:42:54] <@WilliamH> I will be involved as well, the COI doesn't apply when working on something since council has to approve it.
[22:43:15] <@leio> I don't feel the need to shrink them down when we mostly don't have other topics
[22:43:25] <@K_F> slyfox: in all fairness, it is only the case currently , not generally
[22:43:26] <@ulm> WilliamH: nothing is preventing you from submitting a competing GLEP
[22:43:30] <@leio> I mean, we should earn our paycheck somehow ;p
[22:43:42] <@WilliamH> It isn't a glep, just a patch ulm
[22:43:44] <@K_F> slyfox: so short answer is, we define a policy and stick to it
[22:43:49] <@dilfridge> we need to work on them and decide them, not postpone them
[22:44:16] <@WilliamH> The glep is badly worded imo
[22:44:23] <@K_F> the current case is we have a policy, and some people want to change it.. so will see what comes out of it
[22:44:39] <@ulm> WilliamH: as I said, I don't want to have it watered down
[22:44:40] <@dilfridge> the glep is mostly fine, it just conflicts with SIE
[22:44:43] <@K_F> WilliamH: why wasn't that brought up before voting on it, then?
[22:44:59] <@WilliamH> K_F: Personally, I didn't know there would be ramifications.
[22:45:01] <@dilfridge> and it was discussed for ages already, without much objections
[22:45:14] <@K_F> WilliamH: thats your problem, not ours (where it isn't)
[22:45:20] <@dilfridge> slyfox: you can speed it up by not buying sony
[22:45:49] <@K_F> dilfridge: the rootkit case in 2005 did that already :)
[22:46:07] <@WilliamH> That was Sony Music, not SIE.
[22:46:14] <@WilliamH> Different company.
[22:46:15] <@K_F> same difference, sony is sony
[22:46:35] <@K_F> (not copyright wise, but for what I buy it is..)
[22:46:37] <@dilfridge> anyway, I'm out. have fun with the rest of the open floor.
[22:46:38] <@Whissi> This is still an official meeting. Let's watch our words ;)
[22:46:38] <@WilliamH> K_F: git grep -i sony
[22:46:41] <@WilliamH> on the kernel.
[22:47:13] <@leio> for the record, I appreciate that SIE employees can use company time for contributing to Gentoo, and things seem to be heading in a good direction now, provided that we can move to simplified form for them with a future AUTHORS file
[22:47:29] <@Whissi> ACK
[22:47:35] <@WilliamH> Gentoo is very much in SIE's DNA.
[22:47:35] <@dilfridge> ++
[22:48:26] <@leio> 3 more minutes for open floor; who has to leave, may leave
[22:48:30] <@ulm> something completely unrelated, we've exceeded the 1 million commit mark in gentoo.git (including the historical repo). not sure if that has already been mentioned anywhere?
[22:48:41] <@K_F> ulm: nice :)
[22:48:45] <@ulm> in September already
[22:48:48] <@dilfridge> wow
[22:48:55] <@slyfox> how many of them are not keyword changes? :)
[22:48:59] <@ulm> commit 59cc71c623de, if counting naively
[22:49:00] <@WilliamH> heh
[22:49:07] <@WilliamH> slyfox: ^^
[22:49:40] <@K_F> ulm: how did you count that? $ git log | grep -E "^commit" | wc -l
[22:49:40] <@K_F> 225524
[22:49:51] <@leio> historic too
[22:49:59] <@ulm> K_F: with historic repo grafted
[22:50:02] <@K_F> hmm, or did I not graft historical on this computer
[22:50:19] <@K_F> yeah, my bad, I'd have to switch to other chair :)
[22:50:48] <@leio> it probably happened earlier when counting all commits
[22:51:00] <@leio> historic is missing commits that touched only app-backup/
[22:51:37] <@slyfox> and maybe more with Manifest/ChangeLog updates :)
[22:52:34] -*- leio prepares gavel
[22:53:09] <@WilliamH> The only thing I'll say is, give us time when the new glep goes into affect.
[22:53:27] <@WilliamH> We got special treatment by SIE legal etc to process the original one so fast.
[22:53:48] <@WilliamH> So don't hard enforce for a while.
[22:54:04] <@Whissi> o_O
[22:54:20] <@ulm> WilliamH: you should rather spend the time while it's under discussion, not after it's been approved
[22:54:30] <@dilfridge> please not again
[22:54:40] <@dilfridge> WilliamH: we're not going to repeat this
[22:54:45] <@WilliamH> ulm: We have to link them to the document.
[22:54:58] <@dilfridge> no
[22:55:03] <@ulm> drafts of which will be posted to the ML
[22:55:12] <@dilfridge> this time we provide a best effort, and afterwards it's fixed
[22:55:19] <@dilfridge> then sie legal would have to move.
[22:55:46] <@ulm> so what needs to be fixed? allow multiple lines for the traditional notice?
[22:55:50] <@ulm> anything else?
[22:56:01] <@dilfridge> WilliamH: I'm all for accomodating once, but demanding the same thing twice would use up my goodwill
[22:56:09] <@leio> s/multiple lines/multiple notices/
[22:56:24] <@ulm> leio: that's what I meant :)
[22:56:34] <@leio> (but yes, it'd also mean multiple lines; just right now they could also be multiple lines, wrapped from one notice :)
[22:56:59] <@leio> it's not something I would want to see in the package repository, but is reasonable for e.g. eudev and such
[22:57:06] <@WilliamH> s/lines/notices/
[22:57:15] <@WilliamH> Wrapping would be something imo like:
[22:57:35] <@WilliamH> # copyright name1, name2, name3 \
[22:57:45] <@WilliamH> name4, and others
[22:57:51] <@WilliamH> s/4,/4/
[22:58:00] <@WilliamH> That's wrapping and that's pretty ugly
[22:58:49] <@leio> wrapping of comments is done with the next line having a comment marker, not newline escaping
[22:59:23] <@leio> I can agree that it can be ugly as well, but the point was that the glep doesn't explicitly disallow that imho; nice would be "Gentoo Authors" simplified form ;)(
[22:59:33] <@WilliamH> s/multiple lines/multiple notices/ then.
[22:59:58] <@leio> ok, looks like topics have settled
[23:00:01] <@leio> who is the next meeting chair?
[23:00:25] <@leio> K_F: tag, you're it
[23:00:33] <@leio> Meeting closed, thanks all!