[gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

Dear all,

the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
#gentoo-council on freenode.

Please reply to this message with any items you would like us to discuss
or vote on.

The summary of the last meeting will be uploaded over the next 2-3 days; my 
apologies for the delay.

Thanks,
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer
perl, office, comrel, council

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

Dnia 2015-09-30, o godz. 16:01:16
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> #gentoo-council on freenode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.

I would like to get a final decision/vote on what to do about projects,
herds, etc. and the relevant metadata.

This has been discussed multiple times (at least [1] and [2] recently)
with no consensus so far. What's even worse, this has resulted in some
developers refusing sane changes [3] just because there's no official
consensus on 'the greater scheme'. The lack of any action results
in bugs piling up:

a. we still have no official way of figuring out whose approval is
meaningful regarding packages (project on wiki? herds.xml?).

b. Herd->project delegation became broken along with Wiki migration.
Mike has recently worked around this by copying project members from
wiki verbatim [4]. Sadly, this means we're back to having project &
herd members mis-synced.

c. Nobody has done anything about bug assignment -- we still have to
figure out what e-mail does the herd use.

d. Even then, different projects are using different rules for filling
metadata.xml.


In particular, I'd like to push the scheme proposed by myself at [5].
Long story short:

1. We keep herds.xml and bless it the official source of project/herd
metadata. Which means reusing the reusable format and keeping backwards
compatibility with most of the software out there.

1a. We stop the pointless, meaningless and frustrating bikesheds about
by what name we call them. Projects, herds, teams -- let's make them
all synonyms and finally be done with it because I'm really tired of
technical threads being hijacked on naming bikesheds.

1b. The project listings on Wiki become non-binding. In the future, we
may update them automatically from herds.xml but that's not a priority.

1c. We may also automatically add members to mail aliases from
herds.xml if someone really wants that. But again, not a priority.

1d. So, the official rule becomes: if you want to contact developers
who are maintainers of the package, use !herd. If you want to contact
all people interested in its issues, use !expn.

2. We deprecate <herd/> in metadata.xml and assign herds/teams/projects
via e-mail addresses. This keeps partial backwards compatibility with
existing tools and solves the bug assignment issue.

2a. If someone really cares about this, we add an extra attribute or
element which indicates the 'kind' of <maintainer/>. Otherwise, we just
match herds.xml by e-mail address.

This idea has seen no negative replies. I'm willing to do the necessary
work to get it working, in particular updating herds.xml
and metadata.xml using the script I prepared one year ago. I can also
update willikins.

[1]:https://archives.gentoo.org/gentoo-dev/message/526a5be120b3a14096ede7eef8431fde
[2]:https://archives.gentoo.org/gentoo-dev/message/44ef7ed7c2d9d29c23078d25d84b202b
[3]:https://archives.gentoo.org/gentoo-dev/message/47786e3c78c83c3c557be8224fb56ad3
[4]:https://gitweb.gentoo.org/data/api.git/commit/?id=1377b7c3cf74dcae4b8390529c9577088c17e1a9
[5]:https://archives.gentoo.org/gentoo-dev/message/cba0bfb7e2de780d4ac78f2e6fa9f19b

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

>>>>> On Wed, 30 Sep 2015, Michał Górny wrote:

> 2. We deprecate <herd/> in metadata.xml and assign herds/teams/projects
> via e-mail addresses. This keeps partial backwards compatibility with
> existing tools and solves the bug assignment issue.

I'm pretty sure I've mentioned this before, but seems that you have
missed it. IMHO matching projects via their e-mail address is not a
good idea, because some projects have an address <project>-bugs@g.o or
dev-<project>@g.o which makes guessing the project's name (and finding
the project page) more difficult. Therefore, projects should be
matched by their proper name.

> 2a. If someone really cares about this, we add an extra attribute or
> element which indicates the 'kind' of <maintainer/>. Otherwise, we just
> match herds.xml by e-mail address.

Why don't we follow the KISS principle and replace <herd> by <project>
in metadata.xml? That is, create a project for every herd.

Personally, I find this:

  <project>portage</project>

easier to read than this:

  <maintainer type="project">
    <email>dev-portage@gentoo.org<email>
  </maintainer>

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]

Dnia 2015-09-30, o godz. 21:10:17
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Wed, 30 Sep 2015, Michał Górny wrote:
> 
> > 2. We deprecate <herd/> in metadata.xml and assign herds/teams/projects
> > via e-mail addresses. This keeps partial backwards compatibility with
> > existing tools and solves the bug assignment issue.
> 
> I'm pretty sure I've mentioned this before, but seems that you have
> missed it. IMHO matching projects via their e-mail address is not a
> good idea, because some projects have an address <project>-bugs@g.o or
> dev-<project>@g.o which makes guessing the project's name (and finding
> the project page) more difficult. Therefore, projects should be
> matched by their proper name.

And why would you need to guess that? Wiki project names are already
disjoint from herds.xml <name/>s, so I don't see a problem with that.

> > 2a. If someone really cares about this, we add an extra attribute or
> > element which indicates the 'kind' of <maintainer/>. Otherwise, we just
> > match herds.xml by e-mail address.
> 
> Why don't we follow the KISS principle and replace <herd> by <project>
> in metadata.xml? That is, create a project for every herd.

Because this:

1. breaks backwards compatibility,

2. doesn't change anything but the name which is the most meaningless,
waste-of-time change you could have proposed. if you do this, please
count me out.

> Personally, I find this:
> 
>   <project>portage</project>
> 
> easier to read than this:
> 
>   <maintainer type="project">
>     <email>dev-portage@gentoo.org<email>
>   </maintainer>

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

>>>>> On Wed, 30 Sep 2015, Michał Górny wrote:

>> I'm pretty sure I've mentioned this before, but seems that you have
>> missed it. IMHO matching projects via their e-mail address is not a
>> good idea, because some projects have an address <project>-bugs@g.o
>> or dev-<project>@g.o which makes guessing the project's name (and
>> finding the project page) more difficult. Therefore, projects
>> should be matched by their proper name.

> And why would you need to guess that? Wiki project names are already
> disjoint from herds.xml <name/>s, so I don't see a problem with
> that.

We would need a "shortname" or "id" field in the project page
template, e.g. "Quality Assurance" -> "qa" (but I guess most would be
trivial, like "Emacs" -> "emacs"). I've already discussed this with
a3li some time ago, and there should be no technical problems.

>> > 2a. If someone really cares about this, we add an extra attribute or
>> > element which indicates the 'kind' of <maintainer/>. Otherwise, we just
>> > match herds.xml by e-mail address.
>> 

>> Why don't we follow the KISS principle and replace <herd> by <project>
>> in metadata.xml? That is, create a project for every herd.

> Because this:

> 1. breaks backwards compatibility,

It is already broken. For example, <maintainingproject> in herds.xml
does no longer work.

> 2. doesn't change anything but the name which is the most meaningless,
> waste-of-time change you could have proposed. if you do this, please
> count me out.

Huh? You really think that getting rid of herds and having all
information about project membership in one central place (namely,
the project page in the wiki) doesn't change anything?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

Dnia 2015-09-30, o godz. 21:39:11
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Wed, 30 Sep 2015, Michał Górny wrote:
> 
> >> I'm pretty sure I've mentioned this before, but seems that you have
> >> missed it. IMHO matching projects via their e-mail address is not a
> >> good idea, because some projects have an address <project>-bugs@g.o
> >> or dev-<project>@g.o which makes guessing the project's name (and
> >> finding the project page) more difficult. Therefore, projects
> >> should be matched by their proper name.
> 
> > And why would you need to guess that? Wiki project names are already
> > disjoint from herds.xml <name/>s, so I don't see a problem with
> > that.
> 
> We would need a "shortname" or "id" field in the project page
> template, e.g. "Quality Assurance" -> "qa" (but I guess most would be
> trivial, like "Emacs" -> "emacs"). I've already discussed this with
> a3li some time ago, and there should be no technical problems.

And what's the technical problem of using e-mail address instead
which is already there and is a valid global identifier? Why do we have
to duplicate more information when we can use something we need there
anyway?

> 
> >> > 2a. If someone really cares about this, we add an extra attribute or
> >> > element which indicates the 'kind' of <maintainer/>. Otherwise, we just
> >> > match herds.xml by e-mail address.
> >> 
> 
> >> Why don't we follow the KISS principle and replace <herd> by <project>
> >> in metadata.xml? That is, create a project for every herd.
> 
> > Because this:
> 
> > 1. breaks backwards compatibility,
> 
> It is already broken. For example, <maintainingproject> in herds.xml
> does no longer work.

Small breakage is no excuse for bigger breakage. Right now, all package
managers still work. Tools like 'equery m' still get the e-mails for
bug assignments right.

With your solution, they all broke immediately. 'equery m' no longer
lists correct maintainers. All package managers need to be updated,
including *API changes*.

> > 2. doesn't change anything but the name which is the most meaningless,
> > waste-of-time change you could have proposed. if you do this, please
> > count me out.
> 
> Huh? You really think that getting rid of herds and having all
> information about project membership in one central place (namely,
> the project page in the wiki) doesn't change anything?

Excuse me, but what are you talking about now? All you said was to
change the tag, you didn't mention anything about wiki.

And if you really want to keep this information in the Wiki, then I'm
strongly against it. Because I really like having metadata is useful
format in git repo rather than some proprietary database which can't
even list all developers properly and require fancy software to access.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

>>>>> On Wed, 30 Sep 2015, Michał Górny wrote:

>> We would need a "shortname" or "id" field in the project page
>> template, e.g. "Quality Assurance" -> "qa" (but I guess most would
>> be trivial, like "Emacs" -> "emacs"). I've already discussed this
>> with a3li some time ago, and there should be no technical problems.

> And what's the technical problem of using e-mail address instead
> which is already there and is a valid global identifier? Why do we
> have to duplicate more information when we can use something we need
> there anyway?

Because the mapping from projects to e-mail addresses is neither
injective nor surjective.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

Dnia 2015-09-30, o godz. 22:05:11
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Wed, 30 Sep 2015, Michał Górny wrote:
> 
> >> We would need a "shortname" or "id" field in the project page
> >> template, e.g. "Quality Assurance" -> "qa" (but I guess most would
> >> be trivial, like "Emacs" -> "emacs"). I've already discussed this
> >> with a3li some time ago, and there should be no technical problems.
> 
> > And what's the technical problem of using e-mail address instead
> > which is already there and is a valid global identifier? Why do we
> > have to duplicate more information when we can use something we need
> > there anyway?
> 
> Because the mapping from projects to e-mail addresses is neither
> injective nor surjective.

If you really believe so... are you going to change Bugzilla as well
not to rely on e-mail addresses?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Alexis Ballier]

On Wed, 30 Sep 2015 22:05:11 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Wed, 30 Sep 2015, Michał Górny wrote:
> 
> >> We would need a "shortname" or "id" field in the project page
> >> template, e.g. "Quality Assurance" -> "qa" (but I guess most would
> >> be trivial, like "Emacs" -> "emacs"). I've already discussed this
> >> with a3li some time ago, and there should be no technical problems.
> 
> > And what's the technical problem of using e-mail address instead
> > which is already there and is a valid global identifier? Why do we
> > have to duplicate more information when we can use something we need
> > there anyway?
> 
> Because the mapping from projects to e-mail addresses is neither
> injective nor surjective.

I guess the current proposal is to make it injective: exactly one email
per project. wiki.g.o/${email%@gentoo.org} is a shortcut for the proper
project page.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Wed, Sep 30, 2015 at 3:10 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Wed, 30 Sep 2015, Michał Górny wrote:
>
>> 2. We deprecate <herd/> in metadata.xml and assign herds/teams/projects
>> via e-mail addresses. This keeps partial backwards compatibility with
>> existing tools and solves the bug assignment issue.
>
> I'm pretty sure I've mentioned this before, but seems that you have
> missed it. IMHO matching projects via their e-mail address is not a
> good idea, because some projects have an address <project>-bugs@g.o or
> dev-<project>@g.o which makes guessing the project's name (and finding
> the project page) more difficult. Therefore, projects should be
> matched by their proper name.
>

I kind-of prefer the email solution, because it reduces the number of
identifiers people are effectively using.  Bugzilla is tracking by
email, herds by names, etc.

If some projects/herds/whatevers have less-intuitive email aliases
they can always create new ones that are easier to use.

But, I don't feel very strongly about the issue.

>> 2a. If someone really cares about this, we add an extra attribute or
>> element which indicates the 'kind' of <maintainer/>. Otherwise, we just
>> match herds.xml by e-mail address.
>
> Why don't we follow the KISS principle and replace <herd> by <project>
> in metadata.xml? That is, create a project for every herd.
>
> Personally, I find this:
>
>   <project>portage</project>
>
> easier to read than this:
>
>   <maintainer type="project">
>     <email>dev-portage@gentoo.org<email>
>   </maintainer>

Honestly, I think not specifying the type at all is simpler still.  If
you want to know what dev-portage@gentoo.org is, then go to the single
authoritative source herds.xml for alias->project/team/whatever
mappings, rather than embedding this in every single package
metadata.xml.

I can be persuaded that one particular authoritative source is better
than another, but I really don't like having multiple places that are
all competing for the place you go to store the same information.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

Am Mittwoch, 30. September 2015, 20:15:37 schrieb Michał Górny:
> 
> I would like to get a final decision/vote on what to do about projects,
> herds, etc. and the relevant metadata.

Here's my alternative proposal how to solve this. It takes a slightly more 
radical approach and tries to replace the old mess not with a newer mess but 
with a true simplification. Expanded from [1].

a) Remove the word "herd" from docs and specifications.

b) Package is "in herd" -> package is "maintained by project"

c) In metadata.xml, replace <herd>x<herd>  ->  <project>y<project>
This needs (as Ulrich has already pointed out) a short-name y for each 
project, to be defined on its wiki page.
E.g., "Gentoo KDE project" has shortname kde.

d) Simple and stupid mapping for e-mail aliases: 
project shortname y -> e-mail alias is y-project@g.o
Legacy (e.g. y@g.o) addresses will be forwarded.

e) Since per GLEP 39 only developers can be project members, let's introduce 
"contributors" which are listed on the wiki project page together with the 
members.

f) The project e-mail alias is automatically populated from the wiki page 
(members and contributors).
* We may want to introduce a tick mark on the member listing ("Receives 
project mail"), if not all project members want to be on the alias.
* This introduces the simplification that alias members are a subset of 
project members & contributors. I.e., noone not listed on the project page can 
get project mail.
* Obviously there are exceptions to this rigid structure for few special teams 
(sec, infra, ...)

Thoughts?
Andreas

[1] https://archives.gentoo.org/gentoo-dev/message/7fa1dd0095297d1c3365d432058a088f

-- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Dnia 2015-09-30, o godz. 22:21:27
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> d) Simple and stupid mapping for e-mail aliases: 
> project shortname y -> e-mail alias is y-project@g.o
> Legacy (e.g. y@g.o) addresses will be forwarded.

Sounds like more typing but I guess this is what makes people happy.
Why alter the few team names who have trouble when we can force
a change on everyone...

> e) Since per GLEP 39 only developers can be project members, let's introduce 
> "contributors" which are listed on the wiki project page together with the 
> members.

This doesn't solve the problem with developers who don't want to use
SMW.

> f) The project e-mail alias is automatically populated from the wiki page 
> (members and contributors).

Is anyone going to actually do it? Or is this a purely theoretical idea
with nobody willing to do the work?

> * Obviously there are exceptions to this rigid structure for few special teams 
> (sec, infra, ...)

Doesn't this kill the whole idea? Or are we talking about projects
which are not allowed to maintain packages?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

> > d) Simple and stupid mapping for e-mail aliases:
> > project shortname y -> e-mail alias is y-project@g.o
> > Legacy (e.g. y@g.o) addresses will be forwarded.
> 
> Sounds like more typing but I guess this is what makes people happy.
> Why alter the few team names who have trouble when we can force
> a change on everyone...

I'm also happy with altering the few critical team shortnames, as long as we 
can have a 1:1 mapping here between project shortname and mail alias.

> > e) Since per GLEP 39 only developers can be project members, let's
> > introduce "contributors" which are listed on the wiki project page
> > together with the members.
> 
> This doesn't solve the problem with developers who don't want to use
> SMW.

I just plainly dont care beyond a certain level of obstructiveness.

> > f) The project e-mail alias is automatically populated from the wiki page
> > (members and contributors).
> 
> Is anyone going to actually do it? Or is this a purely theoretical idea
> with nobody willing to do the work?

It's feasible according to Alex (though he doesnt particularly like the idea).

> > * Obviously there are exceptions to this rigid structure for few special
> > teams (sec, infra, ...)
> 
> Doesn't this kill the whole idea? Or are we talking about projects
> which are not allowed to maintain packages?

What's maintaining packages got to do with the generation the mail aliases?

-- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Dnia 2015-09-30, o godz. 22:36:42
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> > > f) The project e-mail alias is automatically populated from the wiki page
> > > (members and contributors).
> > 
> > Is anyone going to actually do it? Or is this a purely theoretical idea
> > with nobody willing to do the work?
> 
> It's feasible according to Alex (though he doesnt particularly like the idea).

That's not my question. I know SMW can do many things. So let me ask
again: will someone actually do it? In a reasonable time?

> > > * Obviously there are exceptions to this rigid structure for few special
> > > teams (sec, infra, ...)
> > 
> > Doesn't this kill the whole idea? Or are we talking about projects
> > which are not allowed to maintain packages?
> 
> What's maintaining packages got to do with the generation the mail aliases?

Well, you just said you want to have team names matching e-mail
addresses. If you add exceptions, that's no longer true. But if they
don't maintain any packages, this won't bite us during bug assignment.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

Am Mittwoch, 30. September 2015, 22:39:14 schrieb Michał Górny:
>
> > > > * Obviously there are exceptions to this rigid structure for few
> > > > special teams (sec, infra, ...)
> > > 
> > > Doesn't this kill the whole idea? Or are we talking about projects
> > > which are not allowed to maintain packages?
> > 
> > What's maintaining packages got to do with the generation the mail
> > aliases?
> 
> Well, you just said you want to have team names matching e-mail
> addresses. If you add exceptions, that's no longer true. But if they
> don't maintain any packages, this won't bite us during bug assignment.

I dont think we really need exceptions for the mail adresses. More for the 
automatic alias management.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Wed, Sep 30, 2015 at 4:36 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
>> > e) Since per GLEP 39 only developers can be project members, let's
>> > introduce "contributors" which are listed on the wiki project page
>> > together with the members.
>>
>> This doesn't solve the problem with developers who don't want to use
>> SMW.
>
> I just plainly dont care beyond a certain level of obstructiveness.
>

So, I'm still not a huge fan of using the wiki as the source of this
info, but frankly I could care less whether a few devs don't want to
use it.  I fully support the Social Contract and FOSS-tools only, but
if you're going to start getting picky beyond that then you're on your
own.

Not using the wiki because it as a PITA to utilize in this manner is a
great argument.  Not using the wiki because I can't be bothered to
sign up for an account is not.  As far as I'm concerned, let's stick
to the former line.

Along this line, here are some pros/cons I can see:
XML file (or other popular markup format)
- Can be stored in vcs
- No inherent mechanism to prevent invalid files from being stored,
distributed, etc, but files can be validated easily.
- Can be synced and parsed offline
- Libraries to parse xml have probably been ported to the PDP11, your
microwave, your car's ECU, the lunar lander, and more exotic cases
like C, python, Java, etc.
- Doesn't tie identity/authentication to specification
- Never "goes down"
- Still readable in 100 years
- Requires a separate distribution mechanism, but not necessarily
limited to a particular mechanism
Wiki
- Easier for non-devs to edit should this become desirable at some point
- Nice presentation comes along for free
- Editor that enforces correct syntax comes along for free.
- Ties identity/authentication to specification (maybe you could argue
this is a pro and a con)
- Distribution is part of the solution

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Alexis Ballier]

On Wed, 30 Sep 2015 22:36:42 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> 
> > > d) Simple and stupid mapping for e-mail aliases:
> > > project shortname y -> e-mail alias is y-project@g.o
> > > Legacy (e.g. y@g.o) addresses will be forwarded.
> > 
> > Sounds like more typing but I guess this is what makes people happy.
> > Why alter the few team names who have trouble when we can force
> > a change on everyone...
> 
> I'm also happy with altering the few critical team shortnames, as
> long as we can have a 1:1 mapping here between project shortname and
> mail alias.

yes, please keep y@g.o emails and forward the few that need renaming
(e.g. media-video@g.o -> video@g.o)

Alexis.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Alexis Ballier]

On Wed, 30 Sep 2015 22:21:27 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> Am Mittwoch, 30. September 2015, 20:15:37 schrieb Michał Górny:
> > 
> > I would like to get a final decision/vote on what to do about
> > projects, herds, etc. and the relevant metadata.
> 
> Here's my alternative proposal how to solve this. It takes a slightly
> more radical approach and tries to replace the old mess not with a
> newer mess but with a true simplification. Expanded from [1].
> 
> a) Remove the word "herd" from docs and specifications.
> 
> b) Package is "in herd" -> package is "maintained by project"
> 
> c) In metadata.xml, replace <herd>x<herd>  ->  <project>y<project>
> This needs (as Ulrich has already pointed out) a short-name y for
> each project, to be defined on its wiki page.
> E.g., "Gentoo KDE project" has shortname kde.


you can just stop here and it's even simpler :)


> d) Simple and stupid mapping for e-mail aliases: 
> project shortname y -> e-mail alias is y-project@g.o
> Legacy (e.g. y@g.o) addresses will be forwarded.
> 
> e) Since per GLEP 39 only developers can be project members, let's
> introduce "contributors" which are listed on the wiki project page
> together with the members.
> 
> f) The project e-mail alias is automatically populated from the wiki
> page (members and contributors).
> * We may want to introduce a tick mark on the member listing
> ("Receives project mail"), if not all project members want to be on
> the alias.
> * This introduces the simplification that alias members are a subset
> of project members & contributors. I.e., noone not listed on the
> project page can get project mail.
> * Obviously there are exceptions to this rigid structure for few
> special teams (sec, infra, ...)

this f) sounds like something that can be done later and is orthogonal
to the current mess

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/30/2015 10:21 PM, Andreas K. Huettel wrote:
> Am Mittwoch, 30. September 2015, 20:15:37 schrieb Michał Górny:
>> 


> 
> d) Simple and stupid mapping for e-mail aliases: project shortname
> y -> e-mail alias is y-project@g.o Legacy (e.g. y@g.o) addresses
> will be forwarded.

I would actually prefer a separate namespace for that in the form of
project@proj.gentoo.org (the name of the subdomain doesn't necessarily
matter and can be shortened further etc if that makes it more appealing)

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWDYSXAAoJECULev7WN52FdqsIAJP0fomhyIfYkCW5j79A/K1j
5l2AQQZm0BreBjGnvP4Lod9hiB50Qpwql7UlwsgJiv6eWLfFZPgXVYcLfMk4gF+E
Q6J4IpB6hK+TltAvzsjAiKQuNChfEQ4hOaTDkbhdFedccYmvL9HefoyGGCWrkFx/
+PBU60vzY2rpVy/lk3kgACAy909NLln/Ay73tbB3ViKxdsSdnggVVololaBtNyff
ojZ8O11NQ1jPSYIFmhO6fxjI0H1mP3wbuDHm3ZKq7gYkZZTzXsg14dcfGZ4VixII
LFHW9beTVe6Y2oZUB728WP5AErUcOxAX2UXrzYU1nh4hrK+rscC/0gk5swMtiWg=
=L00J
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Dnia 2015-10-01, o godz. 21:08:11
Kristian Fiskerstrand <k_f@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 09/30/2015 10:21 PM, Andreas K. Huettel wrote:
> > Am Mittwoch, 30. September 2015, 20:15:37 schrieb Michał Górny:
> >> 
> 
> 
> > 
> > d) Simple and stupid mapping for e-mail aliases: project shortname
> > y -> e-mail alias is y-project@g.o Legacy (e.g. y@g.o) addresses
> > will be forwarded.
> 
> I would actually prefer a separate namespace for that in the form of
> project@proj.gentoo.org (the name of the subdomain doesn't necessarily
> matter and can be shortened further etc if that makes it more appealing)

Doesn't this bring back the issues with reserved usernames?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2015 09:14 PM, Michał Górny wrote:

>>> 
>>> d) Simple and stupid mapping for e-mail aliases: project
>>> shortname y -> e-mail alias is y-project@g.o Legacy (e.g.
>>> y@g.o) addresses will be forwarded.
>> 
>> I would actually prefer a separate namespace for that in the form
>> of project@proj.gentoo.org (the name of the subdomain doesn't
>> necessarily matter and can be shortened further etc if that makes
>> it more appealing)
> 
> Doesn't this bring back the issues with reserved usernames?
> 

Could you expand on that, please?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWDYX6AAoJECULev7WN52FD9UIAMQi8qMR14bxl6w2qvh9rhtq
/aA4fZBAIHN4HJ7I3ETc2mYkNLTxpARYxxXbbLH54Jml4c/gkNZL07j0Z1A6pjZ2
ys51cAmwh19RA3vPeBUuyR8NyDFwmDJYdBRfo3dAELwo+ZcDPRvtPhM2mmk0NjE4
rqmYxH8riUDRW0+wAogLu8j4+A3vcydIiuyHyHBs7CLoSYmjPVF1k1ANCwxcp3hR
yCU8cLpb/CHQLPn2QxsT9//DbbxvZW8nXf61LVT2cln9aUbn28NtpB3qdEUl21pz
au9JcVTQ86g40iIwYEVwC+/+HIjhJ9EBaLWo7DesG2Egv7oC/OnPpAROfhuaAag=
=NLDq
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

Dnia 2015-10-01, o godz. 21:14:06
Kristian Fiskerstrand <k_f@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 10/01/2015 09:14 PM, Michał Górny wrote:
> 
> >>> 
> >>> d) Simple and stupid mapping for e-mail aliases: project
> >>> shortname y -> e-mail alias is y-project@g.o Legacy (e.g.
> >>> y@g.o) addresses will be forwarded.
> >> 
> >> I would actually prefer a separate namespace for that in the form
> >> of project@proj.gentoo.org (the name of the subdomain doesn't
> >> necessarily matter and can be shortened further etc if that makes
> >> it more appealing)
> > 
> > Doesn't this bring back the issues with reserved usernames?
> > 
> 
> Could you expand on that, please?

Weren't we initially using those '-bugs' etc. suffixes because project
names collided with system usernames?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/01/2015 09:39 PM, Michał Górny wrote:
> Dnia 2015-10-01, o godz. 21:14:06 Kristian Fiskerstrand
> <k_f@gentoo.org> napisał(a):
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 
>> On 10/01/2015 09:14 PM, Michał Górny wrote:
>> 
>>>>> 
>>>>> d) Simple and stupid mapping for e-mail aliases: project 
>>>>> shortname y -> e-mail alias is y-project@g.o Legacy (e.g. 
>>>>> y@g.o) addresses will be forwarded.
>>>> 
>>>> I would actually prefer a separate namespace for that in the
>>>> form of project@proj.gentoo.org (the name of the subdomain
>>>> doesn't necessarily matter and can be shortened further etc
>>>> if that makes it more appealing)
>>> 
>>> Doesn't this bring back the issues with reserved usernames?
>>> 
>> 
>> Could you expand on that, please?
> 
> Weren't we initially using those '-bugs' etc. suffixes because
> project names collided with system usernames?
> 

but would that really be an issue in a segregated subdomain?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWDY8bAAoJECULev7WN52Fi2oH/1jgaUR2sjJ1qpxggV7tvVP+
LEWRmsX3ZG3lYoiY07/6cgAU/2XYrjtciQV/5OVYs2CRTNP8r+31vPgALXC5op6Y
yp/PIP37AWx1GV8ar9A3JqL2zYsgbUa9/K2ne9/CWSXSAWPcXi2Gh92KflZsrpXF
GQMzsQ9q3d7qVfsWx0XUiyQtPGUmpia4OVaCjW1tkt1yT2p7dZhG7raYmAFVZ+zA
iEWhfhTMgWUiPWc28TcTdNLuCkTcxoebubqlbicqGoZh2WSYxZt4DhjUv2ntCjNt
DBM/iE1dQ0sYzTzeuulnNL0sHu9ffZrduWsiRBCmuf0G2xRa7rA7ml2QxDWcp/U=
=ZDVR
-----END PGP SIGNATURE-----

Re: Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

Am Wednesday 30 September 2015, 22:21:27 schrieb Andreas K. Huettel:
> Here's my alternative proposal how to solve this. It takes a slightly more
> radical approach and tries to replace the old mess not with a newer mess but
> with a true simplification. Expanded from [1].
> 

Since the syncing of e-mail aliases creates more complications, how about 
focussing on the easier points first? Let's skip d) and f) for now and stick 
with

> a) Remove the word "herd" from docs and specifications.
> 
> b) Package is "in herd" -> package is "maintained by project"
> 
> c) In metadata.xml, replace <herd>x<herd>  ->  <project>y<project>
> This needs (as Ulrich has already pointed out) a short-name y for each
> project, to be defined on its wiki page.
> E.g., "Gentoo KDE project" has shortname kde.
> 
> e) Since per GLEP 39 only developers can be project members, let's introduce
> "contributors" which are listed on the wiki project page together with the
> members.
> 

We can think about more simplifications or unifications later on.

Cheers, Andreas


-- 
Andreas K. Huettel
Gentoo Linux developer
perl, office, comrel, council

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Dnia 2015-10-02, o godz. 16:42:39
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Am Wednesday 30 September 2015, 22:21:27 schrieb Andreas K. Huettel:
> > Here's my alternative proposal how to solve this. It takes a slightly more
> > radical approach and tries to replace the old mess not with a newer mess but
> > with a true simplification. Expanded from [1].
> > 
> 
> Since the syncing of e-mail aliases creates more complications, how about 
> focussing on the easier points first? Let's skip d) and f) for now and stick 
> with
> 
> > a) Remove the word "herd" from docs and specifications.
> > 
> > b) Package is "in herd" -> package is "maintained by project"
> > 
> > c) In metadata.xml, replace <herd>x<herd>  ->  <project>y<project>
> > This needs (as Ulrich has already pointed out) a short-name y for each
> > project, to be defined on its wiki page.
> > E.g., "Gentoo KDE project" has shortname kde.

What's the gain? Does it justify breaking every tool dealing with
metadata.xml out there? Are you going to fix package managers,
gentoolkit, gentoopm, packages.gentoo.org (in both versions),
willikins, Funtoo scripts...? Or is this going to be another smart move
which forces others to do extra work just because someone didn't like
the name?

> > e) Since per GLEP 39 only developers can be project members, let's introduce
> > "contributors" which are listed on the wiki project page together with the
> > members.
> > 
> 
> We can think about more simplifications or unifications later on.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

>>>>> On Fri, 2 Oct 2015, Michał Górny wrote:

>> Am Wednesday 30 September 2015, 22:21:27 schrieb Andreas K. Huettel:
>> > a) Remove the word "herd" from docs and specifications.
>> >
>> > b) Package is "in herd" -> package is "maintained by project"
>> >
>> > c) In metadata.xml, replace <herd>x<herd> -> <project>y<project>
>> > This needs (as Ulrich has already pointed out) a short-name y for
>> > each project, to be defined on its wiki page. E.g., "Gentoo KDE
>> > project" has shortname kde.

> What's the gain? Does it justify breaking every tool dealing with
> metadata.xml out there?

At some point, backwards compatibility becomes a burden. If we are
going to abandon herds then it is only consequent to retire the
corresponding metadata tag. And yes, some tools will have to be
adjusted. You can't make an omelette without breaking eggs.

> Are you going to fix package managers, gentoolkit, gentoopm,
> packages.gentoo.org (in both versions), willikins, Funtoo
> scripts...? Or is this going to be another smart move which forces
> others to do extra work just because someone didn't like the name?

Is there anything in this list that requires more than a trivial fix?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

Dnia 3 października 2015 11:40:22 CEST, Ulrich Mueller <ulm@gentoo.org> napisał(a):
>>>>>> On Fri, 2 Oct 2015, Michał Górny wrote:
>
>>> Am Wednesday 30 September 2015, 22:21:27 schrieb Andreas K. Huettel:
>>> > a) Remove the word "herd" from docs and specifications.
>>> >
>>> > b) Package is "in herd" -> package is "maintained by project"
>>> >
>>> > c) In metadata.xml, replace <herd>x<herd> -> <project>y<project>
>>> > This needs (as Ulrich has already pointed out) a short-name y for
>>> > each project, to be defined on its wiki page. E.g., "Gentoo KDE
>>> > project" has shortname kde.
>
>> What's the gain? Does it justify breaking every tool dealing with
>> metadata.xml out there?
>
>At some point, backwards compatibility becomes a burden. If we are
>going to abandon herds then it is only consequent to retire the
>corresponding metadata tag. And yes, some tools will have to be
>adjusted. You can't make an omelette without breaking eggs.

And why are we going to do that? I feel like you hijacked my agenda item with your own problem.

>
>> Are you going to fix package managers, gentoolkit, gentoopm,
>> packages.gentoo.org (in both versions), willikins, Funtoo
>> scripts...? Or is this going to be another smart move which forces
>> others to do extra work just because someone didn't like the name?
>
>Is there anything in this list that requires more than a trivial fix?

Well, looking at where this is heading, yes. Most likely most of them will be required to implement some kind of MediaWiki RPC...

>
>Ulrich

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On 10/3/15 at 12:49 PM, Michał Górny wote:
> […]
>
>>> Are you going to fix package managers, gentoolkit, gentoopm, 
>>> packages.gentoo.org (in both versions), willikins, Funtoo 
>>> scripts...? Or is this going to be another smart move which
>>> forces others to do extra work just because someone didn't like
>>> the name?
>> 
>> Is there anything in this list that requires more than a trivial
>> fix?
> 
> Well, looking at where this is heading, yes. Most likely most of them
> will be required to implement some kind of MediaWiki RPC...

Could you stop constantly spreading your FUD already? Your
hyperbole-laden, neverending rants on our lists are getting really old
by now.

On the topic: I have multiple times said that when people know what data
they need out of anything listed in the Wiki, they will get it in a
format that suits them.

Right now, we already have an open, non-proprietary, XML-based RDF graph
that you can query for any machine-readable information. I understand
that not every consumer of our data wants to parse this, so I'll say
this again just for you: If you provide me with a use case and at least
a sketch of the required data structure, you can get near-instantly
updated data in pretty much any serialization format you need.

Until you know what you really want, though, I'll leave you to painting
the bikeshed.

Much love,
  Alex

PS: I'll gladly fix packages.gentoo.org (in the one version that will stay)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[gentoo-project] Project membership vs being on a mail alias: pitfalls and problems

[Robin H. Johnson]

I've picked the top mail in this thread to response to a single issue,
because I think it's important. Dilfridge was in #gentoo-infra earlier
this week, trying to figure out projects->alias generation, and we had
a productive discussion of some the fundamental issues behind that goal.

This email is a result of that discussion.

On Wed, Sep 30, 2015 at 08:15:37PM +0200, Michał Górny wrote:
> 1c. We may also automatically add members to mail aliases from
> herds.xml if someone really wants that. But again, not a priority.

A lot of this discussion seems to conflate project membership with being
on a mail alias, and this is problematic in various ways.

0. Some projects have MORE than one alias.

1. While project membership MUST be public, it's entirely possible that
   some or all of the alias members are private:
1.1. Infra & Security aliases: Some of the aliases themselves might be
     secret, used to filter some mail. The list of addresses on the alias is
	 also private.
1.1.1. "private alias" => members of the alias are hidden, but the alias name is published
1.1.2. "secret alias" => the alias name is not published
1.2. Some contributors to projects LIKE their privacy and/or have
     specific addresses for the alias. This set includes upstream devs that
     care about Gentoo bugs for their app.

2. Just because a developer is a member of a project, does not always
   they want ALL the mail on a given alias. Some aliases, esp the older
   ones or more central ones are firehoses of both real bug mail and
   spam.

The combination of these points has a few implications:

A. Developers need to be able to opt-out of an alias while retaining
   project membership. 
A.1. Should this fact be visible?

B. Non-developer members of a project need to addable to an alias by a
developer
B.1. While preserving the privacy of that contributor entirely, if they
     don't want to show up on a listing of members)
B.2. While preserving the privacy of the contributor's email address, if
     they don't want their email address published.
B.2.1. Additional implication is that the email addresses CANNOT be in a
       public repository at all!
B.3. This scares some developers, not known that a non-developer is on a
     mail alias.

From this, I have a rough plot of a data model that tries to take it
into account. It doesn't cover where to store it, other than it needs to
be private.

= Projects have members
== members fall into two groups: developers, contributors
== members can be public or private, this controls if they are shown on the wiki etc.
== developers are public members by default
== contributors are private members by default
= Projects have mail aliases
== members opt into project mail aliases.
== Public project members NOT in a mail alias are visibly flagged.
== Private project members IN a mail alias are visibly flagged (how to
   do this without exposing them too much?)

I think part of the solution will lie in separating the identity of a
contributor vs their email address: Allow viewing of who is on an alias
without exposing the actual email address.

"John X. (upstream author)" in a alias listing is MUCH more useful than
a random email address.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-project] Project membership vs being on a mail alias: pitfalls and problems

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

Dnia 2015-10-02, o godz. 00:57:33
"Robin H. Johnson" <robbat2@gentoo.org> napisał(a):

> From this, I have a rough plot of a data model that tries to take it
> into account. It doesn't cover where to store it, other than it needs to
> be private.

Just to be clear, do all the mail aliases get auto-generated in this
model? Can we still have non-project aliases? Can we add members to
project aliases externally?

> = Projects have members
> == members fall into two groups: developers, contributors
> == members can be public or private, this controls if they are shown on the wiki etc.
> == developers are public members by default
> == contributors are private members by default

I'm not sure if this isn't extending past project membership scope. Do
private members have any significance besides receiving mail? Does that
mean that anyone can join a project as a contributor (or a developer --
private member)?

Again reaching into package maintainership, let's assume that package P
is maintained by project P2, and developer D gives me ok to commit
a change. Now, how can I check if developer D is allowed to do that?
I would guess only developers who are public project members would be
the official members who have that privilege.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

Dnia 2015-09-30, o godz. 20:15:37
Michał Górny <mgorny@gentoo.org> napisał(a):

> Dnia 2015-09-30, o godz. 16:01:16
> "Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):
> 
> > the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> > #gentoo-council on freenode.
> > 
> > Please reply to this message with any items you would like us to discuss
> > or vote on.
> 
> I would like to get a final decision/vote on what to do about projects,
> herds, etc. and the relevant metadata.

Since this whole thing turned into a huge mess where people keep
bringing solutions to their own problems without defining them, I'm
going to try to organize this into smaller topics which should be
suitable for discussion. If someone could improve this split, I'd
appreciate.


1. Herds vs projects. Are projects enough? Don't we need a 'more
lightweight' maintainer groups that don't have a wiki page?

2. Group e-mail addresses. Aren't they supposed to be unique? Should
more than one project share the same e-mail alias? How is that supposed
to work when the projects can have different members? (related: e-mail
alias autogeneration)

3. Wiki as reference project metadata store. We already kept project
metadata in website and we all know how it all turned out. Moving them
to wiki sounded fine when the alternative was CVS but we have
proj/api.git know. (don't confuse this with exporting the data)

4. Wording. If we decide that projects are enough, can we make 'herd'
a synonym of 'project', and avoid unnecessary renames?

5. Herd/project names vs e-mail addresses. How to make them more
consistent and ease bug assignments? (related: metadata.xml)

6. Autogeneration of mail aliases. Do we want it? How should it work?

7. Future of herds.xml. Should we autogenerate it from Wiki or replace
with another file serving the same purpose?

8. Changes in metadata.xml. How to solve the issue of ordering between
<herd/> and <maintainer/>? Can be related to solving the issue of bug
assignment when project e-mail doesn't match the name.

9. Backwards compatibility. How much effort will be required to fix all
the software? Is the change worth the effort? What about semi-external
services which Gentoo users use but are unlikely to be fixed in short
time?


I hope this covers all the ideas that have been floating around here.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-project] Re: Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Please add "Behaviour of asterisk with = dependency operator" to the
agenda.

In a nutshell: By the current description of the * operator in PMS,
a dependency cat/foo-1.2* matches cat/foo-1.2, cat/foo-1.2.1, etc.
(which is what is intended) but it also matches cat/foo-1.20.
For details see bug 560466 [1].

I propose that we update the definition in PMS such that version
components cannot be split when matching (i.e. 1.2* would not match
1.20).

Alternatives to vote on (in order of my own preference):
a) Introduce this change retroactively for all EAPIs
b) Introduce it in EAPI 6
c) Introduce it in a later EAPI

A patch for variant a) can be found in [2]. For the other variants,
it would be similar but with an additional EAPI table.

Note that Portage anticipated this change and implements the new
behaviour since version 2.2.21 already [3].

Ulrich

[1] https://bugs.gentoo.org/show_bug.cgi?id=560466
[2] https://560466.bugs.gentoo.org/attachment.cgi?id=412594
[3] https://gitweb.gentoo.org/proj/portage.git/commit/?id=d4966a381ee4577818bd972946647338046715b1

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

Dnia 2015-09-30, o godz. 16:01:16
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> #gentoo-council on freenode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.

The second issue that may need Council's attention is developers'
attitude towards pull request source via GitHub.

One and a half month since enabling it, we already had almost 150 pull
requests from Gentoo users (and a few Gentoo developers who use this as
a collaboration tool). Sadly, some developers not only refuse to use
GitHub (which is an acceptable choice) but also have very negative
attitude towards users submitting pull requests and the developers
helping with them.

The point is, if we want users to submit pull requests, we should be
handling them. Then we can't really agree on some developer refusing to
look at the request, and requesting the user to re-send it some other,
less convenient way. Or another developer just silently ignoring every
request and rudely responding to pings.

Since the amount of work necessary to proxy between users
and developers who refuse to use GitHub is huge, I have prepared
a script that opens Bugzilla bugs for GitHub pull requests
and bidirectionally copies comments between them, therefore allowing
Gentoo developers to handle pull requests via Bugzilla at their
convenience. However, it is currently waiting for review and approval
by Robin before it will get deployed.

But even then, I need to make sure the developers will actually use it
politely. Developers can't really close those bugs 'because it's
GitHub', or 'attach a patch', or 'duplicate of #nnnnnn' (because
it's a synced bug, it can't be magically coerced into existing bug).
In fact, I mailed bug-wranglers about this already but I got no reply.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

Hello all,

On Wed, 30 Sep 2015 20:45:10 +0200 Michał Górny wrote:
> The second issue that may need Council's attention is developers'
> attitude towards pull request source via GitHub.
> 
> One and a half month since enabling it, we already had almost 150 pull
> requests from Gentoo users (and a few Gentoo developers who use this as
> a collaboration tool). Sadly, some developers not only refuse to use
> GitHub (which is an acceptable choice) but also have very negative
> attitude towards users submitting pull requests and the developers
> helping with them.
> 
> The point is, if we want users to submit pull requests, we should be
> handling them. Then we can't really agree on some developer refusing to
> look at the request, and requesting the user to re-send it some other,
> less convenient way. Or another developer just silently ignoring every
> request and rudely responding to pings.
> 
> Since the amount of work necessary to proxy between users
> and developers who refuse to use GitHub is huge, I have prepared
> a script that opens Bugzilla bugs for GitHub pull requests
> and bidirectionally copies comments between them, therefore allowing
> Gentoo developers to handle pull requests via Bugzilla at their
> convenience. However, it is currently waiting for review and approval
> by Robin before it will get deployed.
> 
> But even then, I need to make sure the developers will actually use it
> politely. Developers can't really close those bugs 'because it's
> GitHub', or 'attach a patch', or 'duplicate of #nnnnnn' (because
> it's a synced bug, it can't be magically coerced into existing bug).
> In fact, I mailed bug-wranglers about this already but I got no reply.

I'd like to ask the Council to consider pros and cons of this issue
with extreme care. Benefits and dangers of the integration with the
proprietary GitHub service were discussed many times already,
starting from [1].

While the GitHub integration allows to receive a bit more
contributions, it contains long-term dangers of the Gentoo Social
Contract violation and loosing independence of the infrastructure
and the development workflow itself.

I propose that we should draw a line which should not be crossed to
satisfy both the Social Contract and freedom of people to use
whatever tools they want, including GitHub. As a first approximation
I suggest the following:

  All connections with external infrastructure should be done in a
  such way, that in case this external infrastructure will instantly
  and permanently disappear, we should not loss any valuable data
  and metadata, including commits, commit history, discussions,
  patches, issues, bug reports and so on.

As far as I understand Mgorny's proposal, it implies that pull
request issues and patches will be mirrored on bugzilla, but not
patches themselves. In my opinion this is not acceptable, since
violates both the Social Contract (by dependence on propietary
metadata, such as GitHub issues (and pull request is a special type
of issue on GitHub)) and Bugzilla's policy of having all patches
attached to the Bugzilla.

I honestly do not understand why developers should be forced to
violate the Social contract under the excuse of "being polite" to
GitHub contributors nor why such actions should be allowed at all.

[1]
https://archives.gentoo.org/gentoo-project/message/27e8b99db6fcd2654fc2548a605f0b70

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/8/15 8:42 AM, Andrew Savchenko wrote:
> Hello all,
>
> On Wed, 30 Sep 2015 20:45:10 +0200 Michał Górny wrote:
>> The second issue that may need Council's attention is developers'
>> attitude towards pull request source via GitHub.
>>
>> One and a half month since enabling it, we already had almost 150 pull
>> requests from Gentoo users (and a few Gentoo developers who use this as
>> a collaboration tool). Sadly, some developers not only refuse to use
>> GitHub (which is an acceptable choice) but also have very negative
>> attitude towards users submitting pull requests and the developers
>> helping with them.
>>
>> The point is, if we want users to submit pull requests, we should be
>> handling them. Then we can't really agree on some developer refusing to
>> look at the request, and requesting the user to re-send it some other,
>> less convenient way. Or another developer just silently ignoring every
>> request and rudely responding to pings.
>>
>> Since the amount of work necessary to proxy between users
>> and developers who refuse to use GitHub is huge, I have prepared
>> a script that opens Bugzilla bugs for GitHub pull requests
>> and bidirectionally copies comments between them, therefore allowing
>> Gentoo developers to handle pull requests via Bugzilla at their
>> convenience. However, it is currently waiting for review and approval
>> by Robin before it will get deployed.
>>
>> But even then, I need to make sure the developers will actually use it
>> politely. Developers can't really close those bugs 'because it's
>> GitHub', or 'attach a patch', or 'duplicate of #nnnnnn' (because
>> it's a synced bug, it can't be magically coerced into existing bug).
>> In fact, I mailed bug-wranglers about this already but I got no reply.
> I'd like to ask the Council to consider pros and cons of this issue
> with extreme care. Benefits and dangers of the integration with the
> proprietary GitHub service were discussed many times already,
> starting from [1].
>
> While the GitHub integration allows to receive a bit more
> contributions, it contains long-term dangers of the Gentoo Social
> Contract violation and loosing independence of the infrastructure
> and the development workflow itself.
>
> I propose that we should draw a line which should not be crossed to
> satisfy both the Social Contract and freedom of people to use
> whatever tools they want, including GitHub. As a first approximation
> I suggest the following:
>
>    All connections with external infrastructure should be done in a
>    such way, that in case this external infrastructure will instantly
>    and permanently disappear, we should not loss any valuable data
>    and metadata, including commits, commit history, discussions,
>    patches, issues, bug reports and so on.

Thanks for this language Andrew.  It reflects my concerns and I can 
support it in the council.

>
> As far as I understand Mgorny's proposal, it implies that pull
> request issues and patches will be mirrored on bugzilla, but not
> patches themselves. In my opinion this is not acceptable, since
> violates both the Social Contract (by dependence on propietary
> metadata, such as GitHub issues (and pull request is a special type
> of issue on GitHub)) and Bugzilla's policy of having all patches
> attached to the Bugzilla.

I'm hopeful that Michal will be able to figure out a technical solution.

I have one situation where I wanted a user to post his patches to our 
bugzilla for discussions but he did not.  As a result I was unable to 
discuss them on our bugzilla, nor commit them in their current state.  I 
could have discussed them on github but I did not want to create a long 
discussion history there, since that's supposed to be on bugzilla.   So 
now what?
>
> I honestly do not understand why developers should be forced to
> violate the Social contract under the excuse of "being polite" to
> GitHub contributors nor why such actions should be allowed at all.
There may be a technical solution where we can mirror pull requests, 
bugs and patches on bugzilla.

As a side note, this approach to pushing through agendas by creating 
situations where its easier to accept a "solution" rather than reject it 
is not going to work in Gentoo.  We have lots of smart people that see 
through this.  If we wind up being "impolite" to our users, the blame 
belongs to those who created that situation in the first place, not to 
the council.  The Social Contract is correct and I'm not going to 
support anything that violates it.

>
> [1]
> https://archives.gentoo.org/gentoo-project/message/27e8b99db6fcd2654fc2548a605f0b70
>
> Best regards,
> Andrew Savchenko


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

Dnia 8 października 2015 14:58:14 CEST, "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>On 10/8/15 8:42 AM, Andrew Savchenko wrote:
>> Hello all,
>>
>> On Wed, 30 Sep 2015 20:45:10 +0200 Michał Górny wrote:
>>> The second issue that may need Council's attention is developers'
>>> attitude towards pull request source via GitHub.
>>>
>>> One and a half month since enabling it, we already had almost 150
>pull
>>> requests from Gentoo users (and a few Gentoo developers who use this
>as
>>> a collaboration tool). Sadly, some developers not only refuse to use
>>> GitHub (which is an acceptable choice) but also have very negative
>>> attitude towards users submitting pull requests and the developers
>>> helping with them.
>>>
>>> The point is, if we want users to submit pull requests, we should be
>>> handling them. Then we can't really agree on some developer refusing
>to
>>> look at the request, and requesting the user to re-send it some
>other,
>>> less convenient way. Or another developer just silently ignoring
>every
>>> request and rudely responding to pings.
>>>
>>> Since the amount of work necessary to proxy between users
>>> and developers who refuse to use GitHub is huge, I have prepared
>>> a script that opens Bugzilla bugs for GitHub pull requests
>>> and bidirectionally copies comments between them, therefore allowing
>>> Gentoo developers to handle pull requests via Bugzilla at their
>>> convenience. However, it is currently waiting for review and
>approval
>>> by Robin before it will get deployed.
>>>
>>> But even then, I need to make sure the developers will actually use
>it
>>> politely. Developers can't really close those bugs 'because it's
>>> GitHub', or 'attach a patch', or 'duplicate of #nnnnnn' (because
>>> it's a synced bug, it can't be magically coerced into existing bug).
>>> In fact, I mailed bug-wranglers about this already but I got no
>reply.
>> I'd like to ask the Council to consider pros and cons of this issue
>> with extreme care. Benefits and dangers of the integration with the
>> proprietary GitHub service were discussed many times already,
>> starting from [1].
>>
>> While the GitHub integration allows to receive a bit more
>> contributions, it contains long-term dangers of the Gentoo Social
>> Contract violation and loosing independence of the infrastructure
>> and the development workflow itself.
>>
>> I propose that we should draw a line which should not be crossed to
>> satisfy both the Social Contract and freedom of people to use
>> whatever tools they want, including GitHub. As a first approximation
>> I suggest the following:
>>
>>    All connections with external infrastructure should be done in a
>>    such way, that in case this external infrastructure will instantly
>>    and permanently disappear, we should not loss any valuable data
>>    and metadata, including commits, commit history, discussions,
>>    patches, issues, bug reports and so on.
>
>Thanks for this language Andrew.  It reflects my concerns and I can 
>support it in the council.
>
>>
>> As far as I understand Mgorny's proposal, it implies that pull
>> request issues and patches will be mirrored on bugzilla, but not
>> patches themselves. In my opinion this is not acceptable, since
>> violates both the Social Contract (by dependence on propietary
>> metadata, such as GitHub issues (and pull request is a special type
>> of issue on GitHub)) and Bugzilla's policy of having all patches
>> attached to the Bugzilla.
>
>I'm hopeful that Michal will be able to figure out a technical
>solution.
>
>I have one situation where I wanted a user to post his patches to our 
>bugzilla for discussions but he did not.  As a result I was unable to 
>discuss them on our bugzilla, nor commit them in their current state. 
>I 
>could have discussed them on github but I did not want to create a long
>
>discussion history there, since that's supposed to be on bugzilla.   So
>


I see a few problems with that:

1. Should we create separate patches for each commit? If we don't, we discard history.

2. Should we attach the patches separately or tar them? The latter is inconvenient, the former can create a lot of patches.

3. Each update implies mass obsoleting of all patches.

4. Bugzilla has attachment size limit that we'd have to account for.

Now imagine a pull request doing mass fixing. Git can handle that with ease. For bugzie it will be a serious mess.

Potential alternative is to back-mirror pull requests in git.gentoo.org and work on that. But that's likely to cause even more uproar.

>>
>> I honestly do not understand why developers should be forced to
>> violate the Social contract under the excuse of "being polite" to
>> GitHub contributors nor why such actions should be allowed at all.
>There may be a technical solution where we can mirror pull requests, 
>bugs and patches on bugzilla.
>
>As a side note, this approach to pushing through agendas by creating 
>situations where its easier to accept a "solution" rather than reject
>it 
>is not going to work in Gentoo.  We have lots of smart people that see 
>through this.  If we wind up being "impolite" to our users, the blame 
>belongs to those who created that situation in the first place, not to 
>the council.  The Social Contract is correct and I'm not going to 
>support anything that violates it.
>
>>
>> [1]
>>
>https://archives.gentoo.org/gentoo-project/message/27e8b99db6fcd2654fc2548a605f0b70
>>
>> Best regards,
>> Andrew Savchenko

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/8/15 10:09 AM, Michał Górny wrote:
>
> Dnia 8 października 2015 14:58:14 CEST, "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>> On 10/8/15 8:42 AM, Andrew Savchenko wrote:
>>> Hello all,
>>>
>>> On Wed, 30 Sep 2015 20:45:10 +0200 Michał Górny wrote:
>>>> The second issue that may need Council's attention is developers'
>>>> attitude towards pull request source via GitHub.
>>>>
>>>> One and a half month since enabling it, we already had almost 150
>> pull
>>>> requests from Gentoo users (and a few Gentoo developers who use this
>> as
>>>> a collaboration tool). Sadly, some developers not only refuse to use
>>>> GitHub (which is an acceptable choice) but also have very negative
>>>> attitude towards users submitting pull requests and the developers
>>>> helping with them.
>>>>
>>>> The point is, if we want users to submit pull requests, we should be
>>>> handling them. Then we can't really agree on some developer refusing
>> to
>>>> look at the request, and requesting the user to re-send it some
>> other,
>>>> less convenient way. Or another developer just silently ignoring
>> every
>>>> request and rudely responding to pings.
>>>>
>>>> Since the amount of work necessary to proxy between users
>>>> and developers who refuse to use GitHub is huge, I have prepared
>>>> a script that opens Bugzilla bugs for GitHub pull requests
>>>> and bidirectionally copies comments between them, therefore allowing
>>>> Gentoo developers to handle pull requests via Bugzilla at their
>>>> convenience. However, it is currently waiting for review and
>> approval
>>>> by Robin before it will get deployed.
>>>>
>>>> But even then, I need to make sure the developers will actually use
>> it
>>>> politely. Developers can't really close those bugs 'because it's
>>>> GitHub', or 'attach a patch', or 'duplicate of #nnnnnn' (because
>>>> it's a synced bug, it can't be magically coerced into existing bug).
>>>> In fact, I mailed bug-wranglers about this already but I got no
>> reply.
>>> I'd like to ask the Council to consider pros and cons of this issue
>>> with extreme care. Benefits and dangers of the integration with the
>>> proprietary GitHub service were discussed many times already,
>>> starting from [1].
>>>
>>> While the GitHub integration allows to receive a bit more
>>> contributions, it contains long-term dangers of the Gentoo Social
>>> Contract violation and loosing independence of the infrastructure
>>> and the development workflow itself.
>>>
>>> I propose that we should draw a line which should not be crossed to
>>> satisfy both the Social Contract and freedom of people to use
>>> whatever tools they want, including GitHub. As a first approximation
>>> I suggest the following:
>>>
>>>     All connections with external infrastructure should be done in a
>>>     such way, that in case this external infrastructure will instantly
>>>     and permanently disappear, we should not loss any valuable data
>>>     and metadata, including commits, commit history, discussions,
>>>     patches, issues, bug reports and so on.
>> Thanks for this language Andrew.  It reflects my concerns and I can
>> support it in the council.
>>
>>> As far as I understand Mgorny's proposal, it implies that pull
>>> request issues and patches will be mirrored on bugzilla, but not
>>> patches themselves. In my opinion this is not acceptable, since
>>> violates both the Social Contract (by dependence on propietary
>>> metadata, such as GitHub issues (and pull request is a special type
>>> of issue on GitHub)) and Bugzilla's policy of having all patches
>>> attached to the Bugzilla.
>> I'm hopeful that Michal will be able to figure out a technical
>> solution.
>>
>> I have one situation where I wanted a user to post his patches to our
>> bugzilla for discussions but he did not.  As a result I was unable to
>> discuss them on our bugzilla, nor commit them in their current state.
>> I
>> could have discussed them on github but I did not want to create a long
>>
>> discussion history there, since that's supposed to be on bugzilla.   So
>>
>
> I see a few problems with that:
>
> 1. Should we create separate patches for each commit? If we don't, we discard history.
>
> 2. Should we attach the patches separately or tar them? The latter is inconvenient, the former can create a lot of patches.
>
> 3. Each update implies mass obsoleting of all patches.
>
> 4. Bugzilla has attachment size limit that we'd have to account for.
>
> Now imagine a pull request doing mass fixing. Git can handle that with ease. For bugzie it will be a serious mess.
>
> Potential alternative is to back-mirror pull requests in git.gentoo.org and work on that. But that's likely to cause even more uproar.

So perhaps it was unwise for us to get into a situation where either 1) 
we violate the Social Contract or 2) we have to surmount a technically 
difficult situation.

Perhaps those responsible for doing so should fix this.

>
>>> I honestly do not understand why developers should be forced to
>>> violate the Social contract under the excuse of "being polite" to
>>> GitHub contributors nor why such actions should be allowed at all.
>> There may be a technical solution where we can mirror pull requests,
>> bugs and patches on bugzilla.
>>
>> As a side note, this approach to pushing through agendas by creating
>> situations where its easier to accept a "solution" rather than reject
>> it
>> is not going to work in Gentoo.  We have lots of smart people that see
>> through this.  If we wind up being "impolite" to our users, the blame
>> belongs to those who created that situation in the first place, not to
>> the council.  The Social Contract is correct and I'm not going to
>> support anything that violates it.
>>
>>> [1]
>>>
>> https://archives.gentoo.org/gentoo-project/message/27e8b99db6fcd2654fc2548a605f0b70
>>> Best regards,
>>> Andrew Savchenko


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/08/2015 05:01 PM, Anthony G. Basile wrote:
> 
> So perhaps it was unwise for us to get into a situation where either 1)
> we violate the Social Contract or 2) we have to surmount a technically
> difficult situation.
> 

Sorry to jump in without contributing anything useful, but this has been
really going on for too long.

We do not violate the Social Contract in any way. Anyone is free to fork
gentoo and serve it on mirrors which run totally proprietary software
and accept contributions there.

But gentoo does _not_ depend on that infrastructure, because we still
have our own mirrors and contribution platforms.

If people use alternative platforms, then that is their own choice. And
a lot of gentoo developers and overlays do that since years (you'd have
to shut all of them down, including the gentoo github organization).
However, it has never deprecated our own infrastructure channels and as
long as that is true, all these "social contract violated" mails are
pure FUD.

So yes, 2) is correct, 1) not.


So, now to the useful part:

In case infra cares, there's an alternative solution to gitlab which is
called gogs [0]. Previously it was lacking pull request support and
because of that it was pretty useless as a contribution platform. But
that has been implemented now [1]. The only deal-breaker left are
performance problems with repositories which have a huge amount of
folders (like gentoo) [2].
It is very easy to deploy and there are numerous docker images [3][4]
available.
It also supports Github OAuth, which will make it painless for drive-by
contributors.


[0] http://gogs.io/
[1] https://github.com/gogits/gogs/issues/5
[2] https://github.com/gogits/gogs/issues/1518
[3] https://github.com/gogits/gogs/tree/master/docker
[4] https://github.com/hasufell/docker-gentoo-gogs

omg... those are all hosted on github! social contract to the rescue

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Thu, Oct 8, 2015 at 11:01 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> So perhaps it was unwise for us to get into a situation where either 1) we
> violate the Social Contract or 2) we have to surmount a technically
> difficult situation.
>

I don't see how mirroring github on bugzilla violates our social
contract, for several reasons:

1.  Developers aren't required to post patches to bugzilla before
committing them to the tree, so nothing is lost by posting patches on
github that might otherwise not be posted anywhere.
2.  Developers aren't required to open bugs on bugzilla before fixing
bugs.  So, nothing is lost by opening pull requests on github that
might otherwise not be opened anywhere.
3.  Developers aren't required to close bugs on bugzilla even if other
people do open them.  Sure, that might be "rude" in some sense, and
others can of course step in and co-maintain packages and close bugs.
But, we don't kick out developers if they ignore bugs.  I don't think
we'd even treeclean a package with an open critical security bug if
the developer fixed the bug in the repo and just left the bug open.

Bugzilla is already an optional part of our workflow as far as I can
tell.  The proposal is to just add another optional tool to the
workflow.

The proposed integration is just another way to enter data into
bugzilla.  Devs are free to pretend that no data exists which isn't in
the bug, and if somebody contributes a patch the dev is more than
welcome to donate their time independently creating and testing the
same patch instead of looking in a proprietary tool to see the patch
somebody helpfully donated to us already.

Nobody is required to use github to contribute to Gentoo, and nothing
is really lost that we'd otherwise be certain to have if it goes away,
so I don't see the conflict with our social contract.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Thu, 8 Oct 2015 14:24:30 -0400 Rich Freeman wrote:
> On Thu, Oct 8, 2015 at 11:01 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> > So perhaps it was unwise for us to get into a situation where either 1) we
> > violate the Social Contract or 2) we have to surmount a technically
> > difficult situation.
> >
> 
> I don't see how mirroring github on bugzilla violates our social
> contract, for several reasons:
> 
> 1.  Developers aren't required to post patches to bugzilla before
> committing them to the tree, so nothing is lost by posting patches on
> github that might otherwise not be posted anywhere.
> 2.  Developers aren't required to open bugs on bugzilla before fixing
> bugs.  So, nothing is lost by opening pull requests on github that
> might otherwise not be opened anywhere.

The problem comes not from the fact that GitHub stuff is not
mirrored on bugzilla, but from the fact that with GitHub
integration Gentoo becomes dependent on a proprietary
metadata, which is outside of control of our community. Bugzilla
mirroring was discussed only as one of possible solutions.

When talking about Gentoo Social Contract violation by GitHub
integration I apply to the following cause of the Social
Contract [1]:

 However, Gentoo will never depend upon a piece of software or
 metadata unless it conforms to the GNU General Public License, the
 GNU Lesser General Public License, the Creative Commons -
 Attribution/Share Alike or some other license approved by the Open
 Source Initiative (OSI).

If developer commits changes directly to git without bugzilla being
used, this is OK, because out git repo is free and we control it.
But when we start to depend on github pull requests or similar
proprietary metadata, the Social Contract is violated.

Suggested solution with pull requests mirroring on out git repo may
solve this issue if all other data (discussions, issues and so on)
will be mirrored as well (bugzilla looks like a good candidate for
mirroring here).

IMO the best solution will be to deploy some free platform like
Gogs for code review, pull request and all other fashionable
features as was already suggested in this thread by Hasufell.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Thu, Oct 8, 2015 at 9:21 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> When talking about Gentoo Social Contract violation by GitHub
> integration I apply to the following cause of the Social
> Contract [1]:
>
>  However, Gentoo will never depend upon a piece of software or
>  metadata unless it conforms to the GNU General Public License, the
>  GNU Lesser General Public License, the Creative Commons -
>  Attribution/Share Alike or some other license approved by the Open
>  Source Initiative (OSI).
>
> If developer commits changes directly to git without bugzilla being
> used, this is OK, because out git repo is free and we control it.
> But when we start to depend on github pull requests or similar
> proprietary metadata, the Social Contract is violated.

I don't see how we're "depending" on github if we've already agreed
that you can do the same thing without using it in the first place.

If I told you that I secretly push all my changes to github, then pull
them to another machine, then push them to gentoo, would that be some
kind of violation of the social contract.

Nobody is required to even look at github to do their job, and I don't
believe that there is a proposal to require anybody to do so.  If
there were I think we could consider that separately from having an
integration.

People are using github TODAY to work on Gentoo.  If it went away
tomorrow, it really wouldn't affect us much.  It is just an optional
tool, and I don't see the proposal changing that.

> IMO the best solution will be to deploy some free platform like
> Gogs for code review, pull request and all other fashionable
> features as was already suggested in this thread by Hasufell.

You're welcome to do that, and if you need permission to get infra to
host it you're welcome to ask us for it, assuming they're willing to
host it for you (and if that is really the limitation then that is
something we can try to tackle).  Right now nobody is actually doing
the work on that, and I don't see the value in holding up the project
people are working on merely because they could be volunteering their
time on something else instead.  By that argument we'd still be using
the 32-bit binary emul-* packages.

Ultimately we're a bit of a do-acracy and you get further with an
implementation and an argument than you get with an argument alone.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/9/15 5:44 AM, Rich Freeman wrote:
> On Thu, Oct 8, 2015 at 9:21 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>> When talking about Gentoo Social Contract violation by GitHub
>> integration I apply to the following cause of the Social
>> Contract [1]:
>>
>>   However, Gentoo will never depend upon a piece of software or
>>   metadata unless it conforms to the GNU General Public License, the
>>   GNU Lesser General Public License, the Creative Commons -
>>   Attribution/Share Alike or some other license approved by the Open
>>   Source Initiative (OSI).
>>
>> If developer commits changes directly to git without bugzilla being
>> used, this is OK, because out git repo is free and we control it.
>> But when we start to depend on github pull requests or similar
>> proprietary metadata, the Social Contract is violated.
> I don't see how we're "depending" on github if we've already agreed
> that you can do the same thing without using it in the first place.

You become dependent in that discussions about a bug or patch are now on 
github and if that goes away you loose it.  Therefore we depend on 
github to keep that history for us and that history is as important as 
the fix itself.  Saying that you don't have to use github doesn't fix 
this unless that history is mirrored on our bugzilla.

xkcd says it best https://xkcd.com/743/   Many gentoo devs get this and 
that's why they're unhappy about where we've come with this.  I 
contribute to Gentoo under the assumption of the Social Contract.  I 
expect it upheld and not watered down.  You can say "I don't see" and 
put depend in quotes, but all this does is discourage me from 
contributing and remind me that the conditions under which I contributed 
can be just waved away by capriciousness.  This is not an issue that you 
will make go away with redefining "depend".  It strikes at the moral 
fiber of the open source community.

As for rage quitting an issue, are you sure that watering down the 
Social Contract won't cause other kinds of quitting?  This issue is 
above such theatrics.

>
> If I told you that I secretly push all my changes to github, then pull
> them to another machine, then push them to gentoo, would that be some
> kind of violation of the social contract.
>
> Nobody is required to even look at github to do their job, and I don't
> believe that there is a proposal to require anybody to do so.  If
> there were I think we could consider that separately from having an
> integration.
>
> People are using github TODAY to work on Gentoo.  If it went away
> tomorrow, it really wouldn't affect us much.  It is just an optional
> tool, and I don't see the proposal changing that.
>
>> IMO the best solution will be to deploy some free platform like
>> Gogs for code review, pull request and all other fashionable
>> features as was already suggested in this thread by Hasufell.
> You're welcome to do that, and if you need permission to get infra to
> host it you're welcome to ask us for it, assuming they're willing to
> host it for you (and if that is really the limitation then that is
> something we can try to tackle).  Right now nobody is actually doing
> the work on that, and I don't see the value in holding up the project
> people are working on merely because they could be volunteering their
> time on something else instead.  By that argument we'd still be using
> the 32-bit binary emul-* packages.
>
> Ultimately we're a bit of a do-acracy and you get further with an
> implementation and an argument than you get with an argument alone.
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ian Delaney]

On Fri, 9 Oct 2015 06:29:51 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 10/9/15 5:44 AM, Rich Freeman wrote:
> > On Thu, Oct 8, 2015 at 9:21 PM, Andrew Savchenko
> > <bircoph@gentoo.org> wrote:
> >> When talking about Gentoo Social Contract violation by GitHub
> >> integration I apply to the following cause of the Social
> >> Contract [1]:
> >>
> >>   However, Gentoo will never depend upon a piece of software or
> >>   metadata unless it conforms to the GNU General Public License,
> >> the GNU Lesser General Public License, the Creative Commons -
> >>   Attribution/Share Alike or some other license approved by the
> >> Open Source Initiative (OSI).
> >>
> >> If developer commits changes directly to git without bugzilla being
> >> used, this is OK, because out git repo is free and we control it.
> >> But when we start to depend on github pull requests or similar
> >> proprietary metadata, the Social Contract is violated.
> > I don't see how we're "depending" on github if we've already agreed
> > that you can do the same thing without using it in the first place.
> 
> You become dependent in that discussions about a bug or patch are now
> on github and if that goes away you loose it.  Therefore we depend on 
> github to keep that history for us and that history is as important
> as the fix itself.  Saying that you don't have to use github doesn't
> fix this unless that history is mirrored on our bugzilla.
> 
> xkcd says it best https://xkcd.com/743/   Many gentoo devs get this
> and that's why they're unhappy about where we've come with this.  I 
> contribute to Gentoo under the assumption of the Social Contract.  I 
> expect it upheld and not watered down.  You can say "I don't see" and 
> put depend in quotes, but all this does is discourage me from 
> contributing and remind me that the conditions under which I
> contributed can be just waved away by capriciousness.  This is not an
> issue that you will make go away with redefining "depend".  It
> strikes at the moral fiber of the open source community.
> 
> As for rage quitting an issue, are you sure that watering down the 
> Social Contract won't cause other kinds of quitting?  This issue is 
> above such theatrics.
> 

and so on and so forth. Sorry but my head is spinning. If the Council
is to do anything on this issue it seems it needs to address the
basics. Does github and its pull requests undermine or violate the
Social contract or not? Clearly it's a corner stone to the fabric of
this dilemma. High profile devs on both sides are arguing yay and ney.
Dammit this has split gentoo community like I haven't seen before.

I always thought of github as a body that hosts opensource repos of
packages embraced by gentoo. Now we're told it's proprietary software
like MS. User beware.

Once the fundamental issues are sorted the state of the pull requests
has a chance of reaching some form of systemic endorsement or approval.
On my part I have agreed to merge pull requests only to find most
around me have stamped their foot and said no. 

A housed divided is a house that falls. What do we have here?

"We will be handling GitHub pull requests on our own." presumably in
isolation to the rest of those who don't. The definition, the epitome of
division. What follows now?

developers of gentoo community tread very carefully.  This is no time
for rashness or brashness.


-- 
kind regards

Ian Delaney

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Fri, Oct 9, 2015 at 12:12 PM, Ian Delaney <idella4@gentoo.org> wrote:
> On Fri, 9 Oct 2015 06:29:51 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>
>> You become dependent in that discussions about a bug or patch are now
>> on github and if that goes away you loose it.  Therefore we depend on
>> github to keep that history for us and that history is as important
>> as the fix itself.  Saying that you don't have to use github doesn't
>> fix this unless that history is mirrored on our bugzilla.

The proposal is to mirror github pull requests on bugzilla.  So, I'm
not really sure I understand your objection.

Today work is done in github and isn't mirrored to bugzilla.

The proposal is to start mirroring some of that work on bugzilla.  How
does this make us more dependent on proprietary tools?

Nobody is proposing that anybody should have to look at github.  They
can just pretend that it doesn't exist.

>>
>> As for rage quitting an issue, are you sure that watering down the
>> Social Contract won't cause other kinds of quitting?  This issue is
>> above such theatrics.

I'm not sure I follow your argument.  My whole point was to quit the
theatrics.  I'm not impressed by people threatening to ragequit.  I'd
think that you'd probably agree on that front but perhaps we're
misunderstanding each other.

Are developers going to quit because other developers are using
github?  Wouldn't that be a bit like quitting because somebody else is
using a proprietary text editor to edit their ebuilds?  Or quitting on
openrc development because somebody else is maintaining systemd and we
didn't ban that from the tree?

The proposal is to open bugs on bugzilla when pull requests are
submitted on github.  I'm not sure how that is worse than not opening
bug requests on bugzilla when pull requests are submitted on github.

> and so on and so forth. Sorry but my head is spinning. If the Council
> is to do anything on this issue it seems it needs to address the
> basics. Does github and its pull requests undermine or violate the
> Social contract or not?

Does it matter?  The Council hasn't been asked whether developers can
use github.  They're already using github, and we can no more prevent
them from using it than we can prevent them from using emacs to do
their work.  There is no way to distinguish in our repo from a commit
that started its life on github from one that did not.

We don't force developers to use bugzilla today, so I'm not sure why
we'd start forcing them to use github (or not) tomorrow.

> Clearly it's a corner stone to the fabric of
> this dilemma. High profile devs on both sides are arguing yay and ney.
> Dammit this has split gentoo community like I haven't seen before.

This is probably one of less contentious issues I've seen just in my
tenure on the Council, which hasn't been all that long.  I'm not
suggesting that it isn't controversial, but rather that it seems no
worse than many issues that have come up.

Are lots of devs planning on forking Gentoo because lots of other devs
are using github?  Maybe I'm just not paying attention to the same
conversations.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/09/2015 03:21 AM, Andrew Savchenko wrote:
> On Thu, 8 Oct 2015 14:24:30 -0400 Rich Freeman wrote:
>> On Thu, Oct 8, 2015 at 11:01 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>>> So perhaps it was unwise for us to get into a situation where either 1) we
>>> violate the Social Contract or 2) we have to surmount a technically
>>> difficult situation.
>>>
>>
>> I don't see how mirroring github on bugzilla violates our social
>> contract, for several reasons:
>>
>> 1.  Developers aren't required to post patches to bugzilla before
>> committing them to the tree, so nothing is lost by posting patches on
>> github that might otherwise not be posted anywhere.
>> 2.  Developers aren't required to open bugs on bugzilla before fixing
>> bugs.  So, nothing is lost by opening pull requests on github that
>> might otherwise not be opened anywhere.
> 
> The problem comes not from the fact that GitHub stuff is not
> mirrored on bugzilla, but from the fact that with GitHub
> integration Gentoo becomes dependent on a proprietary
> metadata, which is outside of control of our community. Bugzilla
> mirroring was discussed only as one of possible solutions.
> 

No, gentoo does not become dependent on a proprietary metadata.
The metadata is in the git repository. How someone communicates a change
to other maintainers is up to him and that may as well happen via
VoIP... you want people to record their talk and then upload it to
bugzilla? No, I won't, because it was encrypted and private.
The same applies for IRC, where you could argue we don't have full
control over the infrastructure and as a result, no one is allowed to
discuss stuff there, but only on bugzilla. This really makes no sense.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/9/15 6:31 AM, hasufell wrote:
> On 10/09/2015 03:21 AM, Andrew Savchenko wrote:
>> On Thu, 8 Oct 2015 14:24:30 -0400 Rich Freeman wrote:
>>> On Thu, Oct 8, 2015 at 11:01 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>>>> So perhaps it was unwise for us to get into a situation where either 1) we
>>>> violate the Social Contract or 2) we have to surmount a technically
>>>> difficult situation.
>>>>
>>> I don't see how mirroring github on bugzilla violates our social
>>> contract, for several reasons:
>>>
>>> 1.  Developers aren't required to post patches to bugzilla before
>>> committing them to the tree, so nothing is lost by posting patches on
>>> github that might otherwise not be posted anywhere.
>>> 2.  Developers aren't required to open bugs on bugzilla before fixing
>>> bugs.  So, nothing is lost by opening pull requests on github that
>>> might otherwise not be opened anywhere.
>> The problem comes not from the fact that GitHub stuff is not
>> mirrored on bugzilla, but from the fact that with GitHub
>> integration Gentoo becomes dependent on a proprietary
>> metadata, which is outside of control of our community. Bugzilla
>> mirroring was discussed only as one of possible solutions.
>>
> No, gentoo does not become dependent on a proprietary metadata.
> The metadata is in the git repository. How someone communicates a change
> to other maintainers is up to him and that may as well happen via
> VoIP... you want people to record their talk and then upload it to
> bugzilla? No, I won't, because it was encrypted and private.
> The same applies for IRC, where you could argue we don't have full
> control over the infrastructure and as a result, no one is allowed to
> discuss stuff there, but only on bugzilla. This really makes no sense.
>
Some changes are trivial and can be communicated in any way.  Eg. you 
communicated to me recently via github that I needed and `|| die` in a 
ebuild.  But some changes are not trivial and have far reaching 
consequences.  I will ask for those to be discussed in a public forum 
where other devs can see it and its open to public scrutiny.  Eg. we had 
the discussion about libressl on this list. If an important discussion 
starts on github, what am I to say, or what will most devs say?  They 
will not say let's move it to bugzilla, they'll have the discussion 
there.  Once that happens, we have important history on infrastructure 
outside of our control. That where we cross the line with the social 
contract.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/09/2015 12:50 PM, Anthony G. Basile wrote:
> Once that happens, we have important history on infrastructure
> outside of our control.

That implies IRC. And important discussions DO happen there.

The history however is saved. The same goes for github (saved via github
mail notifications).


However, once something needs to be discussed community wide, we
_always_ take that discussion to the public MLs, possibly copying the
relevant history.

This does not change in any way with github.


Are you suggesting that we move away from IRC now, because not all
important discussions start on our mailing lists?

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/9/15 6:58 AM, hasufell wrote:
> On 10/09/2015 12:50 PM, Anthony G. Basile wrote:
>> Once that happens, we have important history on infrastructure
>> outside of our control.
> That implies IRC. And important discussions DO happen there.

I have logs where I tried to get devs to discuss an issue on a bug 
rather than IRC so others could see it.  They resisted.  So to some 
degree yes.

>
> The history however is saved. The same goes for github (saved via github
> mail notifications).

Actually that may be the way around this.  If we could archive those and 
have them searchable that would address my concern and I would change my 
position.  This seems doable.

>
>
> However, once something needs to be discussed community wide, we
> _always_ take that discussion to the public MLs, possibly copying the
> relevant history.
>
> This does not change in any way with github.
>
>
> Are you suggesting that we move away from IRC now, because not all
> important discussions start on our mailing lists?
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/9/15 6:58 AM, hasufell wrote:
> On 10/09/2015 12:50 PM, Anthony G. Basile wrote:
>> Once that happens, we have important history on infrastructure
>> outside of our control.
>
>
> Are you suggesting that we move away from IRC now, because not all
> important discussions start on our mailing lists?
>
I just reread this and have another clarification.  Its not whether 
important discussion happens on IRC or on github or wherever, it whether 
we keep that stuff ourselves on our own infrastructure.  So for example, 
council business is done via IRC but we post the logs on our wiki along 
with a summary.  In hardened, we do the same but email the logs out and 
a summary so it gets into our email archives.  If we could do the same 
with github business, we would resolve the "dependency" issue.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/09/2015 01:17 PM, Anthony G. Basile wrote:
> On 10/9/15 6:58 AM, hasufell wrote:
>> On 10/09/2015 12:50 PM, Anthony G. Basile wrote:
>>> Once that happens, we have important history on infrastructure
>>> outside of our control.
>>
>>
>> Are you suggesting that we move away from IRC now, because not all
>> important discussions start on our mailing lists?
>>
> I just reread this and have another clarification.  Its not whether
> important discussion happens on IRC or on github or wherever, it whether
> we keep that stuff ourselves on our own infrastructure.  So for example,
> council business is done via IRC but we post the logs on our wiki along
> with a summary.  In hardened, we do the same but email the logs out and
> a summary so it gets into our email archives.  If we could do the same
> with github business, we would resolve the "dependency" issue.
> 

That's pretty trivial to do on a case-by-case basis and can be left to
the involved parties.

If you want to automate that on global scale (I don't see why, though),
the gentoo-bot[0] could probably forward all incoming github
notifications to a dedicated ML.


[0] https://github.com/gentoo-bot

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/9/15 7:23 AM, hasufell wrote:
> On 10/09/2015 01:17 PM, Anthony G. Basile wrote:
>> On 10/9/15 6:58 AM, hasufell wrote:
>>> On 10/09/2015 12:50 PM, Anthony G. Basile wrote:
>>>> Once that happens, we have important history on infrastructure
>>>> outside of our control.
>>>
>>> Are you suggesting that we move away from IRC now, because not all
>>> important discussions start on our mailing lists?
>>>
>> I just reread this and have another clarification.  Its not whether
>> important discussion happens on IRC or on github or wherever, it whether
>> we keep that stuff ourselves on our own infrastructure.  So for example,
>> council business is done via IRC but we post the logs on our wiki along
>> with a summary.  In hardened, we do the same but email the logs out and
>> a summary so it gets into our email archives.  If we could do the same
>> with github business, we would resolve the "dependency" issue.
>>
> That's pretty trivial to do on a case-by-case basis and can be left to
> the involved parties.
>
> If you want to automate that on global scale (I don't see why, though),
> the gentoo-bot[0] could probably forward all incoming github
> notifications to a dedicated ML.
>
>
> [0] https://github.com/gentoo-bot
>
Well let's think about this.  If github went away, or we needed to part 
ways with github, what we would we want to keep from their site?  An 
example is all the discussion on "The Crystal Programming Language" pull 
#105.  That discussion should have happened on our bugzilla so we have 
that history on our own infra.  Can we get the gentoo-bot to organize 
email notifications in such a way that we can easily search and read 
histories by issues and/or pull requests?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
> Well let's think about this.  If github went away, or we needed to part
> ways with github, what we would we want to keep from their site?

It is more likely that our infra servers go down or break than github.
From a reliability standpoint, our infra servers clearly lose.

> An
> example is all the discussion on "The Crystal Programming Language" pull
> #105.  That discussion should have happened on our bugzilla so we have
> that history on our own infra.  

I don't see why that discussion should have happened on bugzilla.
Reviews on bugzilla are painful and broken. And it's not a global matter.

I can and will review (new) ebuilds anywhere I please, including private
mails from my proxied maintainers (some use that workflow) or mails to
project aliases (which are only semi-public), although it's preferred
that the information is public. Information on who has reviewed the
ebuild are supposed to go into the git merge commit message, so you can
always contact the reviewer.

> Can we get the gentoo-bot to organize email notifications in such
> a way that we can easily search and read histories by issues and/or
> pull requests?

The gentoo-bot already gets those mail notifications (I guess? can
mgorny confirm?), so the data would already be there, just needs to be
processed. But that's not something that needs to happen overnight,
since there is no data loss imminent.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
> > Well let's think about this.  If github went away, or we needed to part
> > ways with github, what we would we want to keep from their site?
> 
> It is more likely that our infra servers go down or break than github.
> From a reliability standpoint, our infra servers clearly lose.
> 

I think you're missing the point here completely. Whatever.

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWGFCGAAoJEB9VdM6hupKVNSMP/304fACDUUZHUBf2ayMXzsU/
P5TJ4y/ev3iW6Xa1DxAf//RKCqtKa5CnfmFLxayDalRKc8YrnhDcVvS6O1XcgpAT
5ZPS6Pp+JsUDfnfvazmaP2CtIAQv8VtrP6k+5b7OzSCvoTrL1CRwTX7ViY2wlDoP
N3eAQ6k8wWI2nozP/DUBDXe6d2poXO7XQU7QOVI2TMBakGtb1E/1Fb10Nhzykm0O
9l+7SS1iDPS1B7iZe6zQFer52zU3WBBva+uaPmgouqhXrxw3NGeblQFFx+unqVT2
UIEBBbMA+7GBKfo8IPL69ZES7AiiUJWARkn9N6q9iJO0v8vP6QxF6CcU7elKrnM2
dUwDzOxXTWuuJTBlmZzz0S2WkW75YNb//CCgVlb90PqUxnku5oGMI3EDpcxuSvM9
VoMtwXufSrHwhgymlcnQNOuEXObfSDhuVERPXAtCG2wfC+VimOEsvWzsZzSLUbVY
rrz0tht7gH7TLSuC99DdThzbLVFbL9wF2DOLSXAnGcir9IlFgEdJhQ2QauUGuys3
Lp+cITJKosLrcuEyGNjnV6eN/MwpW3VzpN+wVyX/AKx8Keh47wcN76azGSxVmo0d
lTD3d6E0/mMxlNLstTPmIFrI8leyHVcopFh6zSkviV2XOaNmm7eHV4k+kTe1i7lX
EP0xBjL/h4QhF1Naz/FA
=rqeu
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
> Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
>>> Well let's think about this.  If github went away, or we needed to part
>>> ways with github, what we would we want to keep from their site?
> 
>> It is more likely that our infra servers go down or break than github.
>> From a reliability standpoint, our infra servers clearly lose.
> 
> 
> I think you're missing the point here completely. Whatever.
> 

Not at all, but you'd have to read my whole mail.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Samstag, 10. Oktober 2015, 12:16:26 schrieb hasufell:
> On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
> > Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
> >> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
> >>> Well let's think about this.  If github went away, or we needed to part
> >>> ways with github, what we would we want to keep from their site?
> >> 
> >> It is more likely that our infra servers go down or break than github.
> >> From a reliability standpoint, our infra servers clearly lose.
> > 
> > I think you're missing the point here completely. Whatever.
> 
> Not at all, but you'd have to read my whole mail.

The rest is even more irrelevant.

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWGPgBAAoJEB9VdM6hupKVOMMP/1CZoi71KWuCO7/UO14bZs1U
2aWq5slDKMXlG8jjtF7txhFWgEX/F5wPIzAHRRTI8Pae5WxvEw2JGAcJMK8FFWUp
Ni+RJiIoQI7P6FEzQGu8yv77x9iVZPFhlZc9JDo24qMEEj4AKPUBlqG+VD8R6jL/
xROWReN5WttNLtbINGjxhbGW8VO5aBrHEdRrDLzEF3d35Vk4igO0XHECrK477ged
JY9yztJwoIa9h5FmNQ+vvKFosKRQxO21pfZ3jyUhkfOZ3CXXIfUTNWaRwYavS90W
bsnmeWhIDIieRlOq9x3Yoif6rsHeBu2E90hYPdgBJh6piQzpM3ZEm+UXeYc+pvDb
6mcXzlZZazYEsof9VDKC2fI6YeYLCfgEVFLSfMtVhyOKi2epUwMSLkVeAWngD+Uf
nAMf5BsszpEuBhs0gso/zrd6UGjCNFUNZH5EgR36IkuTB3b5YSopUHXZoQ8njGTz
9BNUz/SeeB/NhgZtX6ALbFgkfhr6oCd90N1oBl7JxgwB502nFlw22oIH+EP4LC+Z
Crf92mJvybwGsLZyA11bybccgaGqyIc1+MaWVZvRsnCEQq5RQjbsBeewW4dLGsxK
nWeG6Wa7Vu43zm2ex8xdZc+QpfHrtjomMGjNYOvjdR84kIk8+gJELNaTzp8zqTlK
Vw/YH2swFY/8c3KyWFVb
=R2Xy
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/10/2015 01:35 PM, Andreas K. Huettel wrote:
> Am Samstag, 10. Oktober 2015, 12:16:26 schrieb hasufell:
>> On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
>>> Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
>>>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
>>>>> Well let's think about this.  If github went away, or we needed to part
>>>>> ways with github, what we would we want to keep from their site?
>>>>
>>>> It is more likely that our infra servers go down or break than github.
>>>> From a reliability standpoint, our infra servers clearly lose.
>>>
>>> I think you're missing the point here completely. Whatever.
> 
>> Not at all, but you'd have to read my whole mail.
> 
> The rest is even more irrelevant.
> 

Not at all, it discusses solutions to what I and blueness were
discussing. If you cannot follow the discussion, why do you respond then?

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On 10-10-2015 13:37:24 +0200, hasufell wrote:
> On 10/10/2015 01:35 PM, Andreas K. Huettel wrote:
> > Am Samstag, 10. Oktober 2015, 12:16:26 schrieb hasufell:
> >> On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
> >>> Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
> >>>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
> >>>>> Well let's think about this.  If github went away, or we needed to part
> >>>>> ways with github, what we would we want to keep from their site?
> >>>>
> >>>> It is more likely that our infra servers go down or break than github.
> >>>> From a reliability standpoint, our infra servers clearly lose.
> >>>
> >>> I think you're missing the point here completely. Whatever.
> > 
> >> Not at all, but you'd have to read my whole mail.
> > 
> > The rest is even more irrelevant.
> 
> Not at all, it discusses solutions to what I and blueness were
> discussing. If you cannot follow the discussion, why do you respond then?

Outsider's perspective: you and Anthony/Andreas are discussing completely
different topics.

My €0.02
Fabian


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/10/2015 02:21 PM, Fabian Groffen wrote:
> On 10-10-2015 13:37:24 +0200, hasufell wrote:
>> On 10/10/2015 01:35 PM, Andreas K. Huettel wrote:
>>> Am Samstag, 10. Oktober 2015, 12:16:26 schrieb hasufell:
>>>> On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
>>>>> Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
>>>>>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
>>>>>>> Well let's think about this.  If github went away, or we needed to part
>>>>>>> ways with github, what we would we want to keep from their site?
>>>>>>
>>>>>> It is more likely that our infra servers go down or break than github.
>>>>>> From a reliability standpoint, our infra servers clearly lose.
>>>>>
>>>>> I think you're missing the point here completely. Whatever.
>>>
>>>> Not at all, but you'd have to read my whole mail.
>>>
>>> The rest is even more irrelevant.
>>
>> Not at all, it discusses solutions to what I and blueness were
>> discussing. If you cannot follow the discussion, why do you respond then?
> 
> Outsider's perspective: you and Anthony/Andreas are discussing completely
> different topics.
> 

Thanks for the contribution. Can we get ontopic now instead of
nitpicking on a few single sentences that don't make sense if you didn't
read the whole discussion or didn't try to understand what the author
was getting at?

Thanks.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Samstag, 10. Oktober 2015, 14:23:32 schrieb hasufell:
> On 10/10/2015 02:21 PM, Fabian Groffen wrote:
> > On 10-10-2015 13:37:24 +0200, hasufell wrote:
> >> On 10/10/2015 01:35 PM, Andreas K. Huettel wrote:
> >>> Am Samstag, 10. Oktober 2015, 12:16:26 schrieb hasufell:
> >>>> On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
> >>>>> Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
> >>>>>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
> >>>>>>> Well let's think about this.  If github went away, or we needed to
> >>>>>>> part ways with github, what we would we want to keep from their
> >>>>>>> site?
> >>>>>> 
> >>>>>> It is more likely that our infra servers go down or break than
> >>>>>> github. From a reliability standpoint, our infra servers clearly
> >>>>>> lose.
> >>>>> 
> >>>>> I think you're missing the point here completely. Whatever.
> >>>> 
> >>>> Not at all, but you'd have to read my whole mail.
> >>> 
> >>> The rest is even more irrelevant.
> >> 
> >> Not at all, it discusses solutions to what I and blueness were
> >> discussing. If you cannot follow the discussion, why do you respond
> >> then?
> > 
> > Outsider's perspective: you and Anthony/Andreas are discussing completely
> > different topics.
> 
> Thanks for the contribution. Can we get ontopic now instead of
> nitpicking on a few single sentences that don't make sense if you didn't
> read the whole discussion or didn't try to understand what the author
> was getting at?

Sure. You go first. :)

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWGRj5AAoJEB9VdM6hupKVYv8QAK5f3s3NKW2+qHCersr4tvfj
2YWfLNQWUhzEv6ObzUVwjg6cvtaOPMSPpRKDxQOOeKhJ6pq5V1vR+nRsOTb2VHs4
A/xCO+K7qnznukos3LXj/BTLGkEpxX9qKgF7KYW6bqN5VPdVZD6o2M3JgoRMwgr0
R9kng/f36Gz7FyXM/RsCLt3+HjUfyOXYRA3sVAgDNt9grPRSp/Fa9TbG/+s68ABP
JQMK7RRZvu5Cby7MP1vU58Yds5UOW7jRuSDfSIId8hgxp4Q6gd5io6Fgfu31bQJy
ejKeLjjvgrR8NKaaBlXA0774FLOzvPO0CyhV6KfR4o6RCNOY0JkdaHugkTZtQ9g1
xxJByzaUo1q4Y/wcAyEafZhr5iNztJtLJUGSeiHPvqQM5QqxG1/xP3QL+HjV0+f+
QU8DC4tYDDXdaiNOYavZAbnAFnt8RRxkdDwZ6fGou8P1tS27IlyBSSWgv3a3eqh2
MUKtjwClzSK7yn/U6I1BbidUGmEhZaeEisAxl/21Hnqs+VQwaA4yb2RNQa8Nq8o5
HanAQqP1SG4gsPZlviGoowx+i/LYEE1FaR/bVj4ZLWOQwb4m2r+V9TCM6zcjjwtL
/irao4V7nNdSwyuM8vKTpR3R9AzASxpO6pbNqRgsUjM1rlpAapt0a3G0rxtMVnIk
EI6VzTJHaGtSuSi2nt0a
=Kl8d
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Dale]

hasufell wrote:
> On 10/10/2015 02:21 PM, Fabian Groffen wrote:
>> On 10-10-2015 13:37:24 +0200, hasufell wrote:
>>> On 10/10/2015 01:35 PM, Andreas K. Huettel wrote:
>>>> Am Samstag, 10. Oktober 2015, 12:16:26 schrieb hasufell:
>>>>> On 10/10/2015 01:40 AM, Andreas K. Huettel wrote:
>>>>>> Am Freitag, 9. Oktober 2015, 14:15:15 schrieb hasufell:
>>>>>>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
>>>>>>>> Well let's think about this.  If github went away, or we needed to part
>>>>>>>> ways with github, what we would we want to keep from their site?
>>>>>>> It is more likely that our infra servers go down or break than github.
>>>>>>> From a reliability standpoint, our infra servers clearly lose.
>>>>>> I think you're missing the point here completely. Whatever.
>>>>> Not at all, but you'd have to read my whole mail.
>>>> The rest is even more irrelevant.
>>> Not at all, it discusses solutions to what I and blueness were
>>> discussing. If you cannot follow the discussion, why do you respond then?
>> Outsider's perspective: you and Anthony/Andreas are discussing completely
>> different topics.
>>
> Thanks for the contribution. Can we get ontopic now instead of
> nitpicking on a few single sentences that don't make sense if you didn't
> read the whole discussion or didn't try to understand what the author
> was getting at?
>
> Thanks.
>
>
>


I been following this too.  I think it is you who doesn't get it this
time.  May want to rethink this.  I'm not a developer and I don't even
claim to know all the details of the changes being made but even I can
follow what Andreas is saying.  He's making a point and either you can't
see it or just don't want to see it. 

Dale

:-)  :-) 

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

On Fri, 9 Oct 2015 14:15:15 +0200 hasufell wrote:
> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
> > Well let's think about this.  If github went away, or we needed to part
> > ways with github, what we would we want to keep from their site?
> 
> It is more likely that our infra servers go down or break than github.
> From a reliability standpoint, our infra servers clearly lose.

This is not a question of infrastructure high availability, this is
a question of the data long-term availability. GitHub is outside of
our control. If it perishes, we are in trouble, big trouble if we
stored important data and had important workflow via GitHub only.

And unfortunately the words above are not sheer speculation.

1) GitHub _was already blocked_ in several countries [1]. We are an
international community, thus we can't rely on such resource.

2) Since GitHub is not completely open, it has a rist of following
SourceForge fate. Before GitHub appeared SourceForge was probably
the most popular development platform, at least 8-10 years ago.
They were good guys. Later their owner changed, their policy
changed, with known consequences: now SourceForge is known for its
project hijacking [2] and adware. The worst result is that
SourceForge is damaged good Free Software projects, e.g. GIMP [3]
and now blocked by most anti-ads software [4,5]. 

And now GitHub are good guys. But for how long?
I want to ensure long-time project stability of Gentoo, that's why
I can't accept the violation of the Gentoo Social contract, which
was made to protect the project from dangers alike this one. That's
why we must have our own infrastructure.

Please note, nobody says: you can use GitHub only overy my dead
body. As can be seen from this discussion, there is a solution: all
GitHub data must be mirrored on our infrastructure in a usable and
searchable way, so that:
1) we will ensure long-time availability of all development data;
2) no single developer will be force to use GitHub to "politely
review pull requests" or whatever.

[1] https://en.wikipedia.org/wiki/Censorship_of_GitHub
[2] https://en.wikipedia.org/wiki/SourceForge#Controversies
[3]
https://mail.gnome.org/archives/gimp-developer-list/2015-May/msg00144.html
[4]
https://ma.ttias.be/ublock-origin-now-blocking-access-to-sourceforge/
[5]
http://www.ghacks.net/2015/06/15/popular-software-projects-leave-sourceforge/

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On Sat, 10 Oct 2015 21:56:52 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:
> 1) GitHub _was already blocked_ in several countries [1]. We are an
> international community, thus we can't rely on such resource.

And no doubt Gentoo will be blocked at some point, if it becomes
popular enough and continues to include software which upsets people.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Sat, Oct 10, 2015 at 2:59 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 10 Oct 2015 21:56:52 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
>> 1) GitHub _was already blocked_ in several countries [1]. We are an
>> international community, thus we can't rely on such resource.
>
> And no doubt Gentoo will be blocked at some point, if it becomes
> popular enough and continues to include software which upsets people.

Of course, the whole point of the social contract is that if Gentoo is
ever "blocked" or taken over by a hostile interest, etc, then
everything of value that makes us what we are is already FOSS.

Ideally we should get to a state where all of infra (minus things like
credentials or personal info) is documented and trivial for anybody to
copy.  That would both make it easier for others to contribute and
make it easy to roll your own Gentoo should that be useful.

We haven't really pushed for a copyright attribution solution, but
even there we were looking at something like the FSFe FLA which is
designed to prevent being held hostage by a hostile owner (maybe the
trustees lose their minds or somebody sues Gentoo, prevails, and is
awarded all our copyrights).

In any case, I think the arguments have been hashed out.  FWIW I fully
support the social contract and the importance of building on FOSS.
At the same time, we should be pragmatic when somebody comes along
with a largely-free solution and nobody else is stepping up with a
completely-free alternative.  I suspect we'll manage to find a
reasonable compromise.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

Hi,

On Sat, 10 Oct 2015 17:41:57 -0400 Rich Freeman wrote:
> On Sat, Oct 10, 2015 at 2:59 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Sat, 10 Oct 2015 21:56:52 +0300
> > Andrew Savchenko <bircoph@gentoo.org> wrote:
> >> 1) GitHub _was already blocked_ in several countries [1]. We are an
> >> international community, thus we can't rely on such resource.
> >
> > And no doubt Gentoo will be blocked at some point, if it becomes
> > popular enough and continues to include software which upsets people.
> 
> Of course, the whole point of the social contract is that if Gentoo is
> ever "blocked" or taken over by a hostile interest, etc, then
> everything of value that makes us what we are is already FOSS.
> 
> Ideally we should get to a state where all of infra (minus things like
> credentials or personal info) is documented and trivial for anybody to
> copy.  That would both make it easier for others to contribute and
> make it easy to roll your own Gentoo should that be useful.
> 
> We haven't really pushed for a copyright attribution solution, but
> even there we were looking at something like the FSFe FLA which is
> designed to prevent being held hostage by a hostile owner (maybe the
> trustees lose their minds or somebody sues Gentoo, prevails, and is
> awarded all our copyrights).
> 
> In any case, I think the arguments have been hashed out.  FWIW I fully
> support the social contract and the importance of building on FOSS.
> At the same time, we should be pragmatic when somebody comes along
> with a largely-free solution and nobody else is stepping up with a
> completely-free alternative.  I suspect we'll manage to find a
> reasonable compromise.
 
FSF announced GNU ethical criteria for code repositories:
https://www.fsf.org/news/gnu-ethical-repo-criteria
https://www.gnu.org/software/repo-criteria.html

We should take it into consideration as well. I really doubt that
GitHub will be able to pass even C class check :) Such check are
under way right now.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Sat, Oct 17, 2015 at 7:14 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> FSF announced GNU ethical criteria for code repositories:
> https://www.fsf.org/news/gnu-ethical-repo-criteria
> https://www.gnu.org/software/repo-criteria.html
>
> We should take it into consideration as well. I really doubt that
> GitHub will be able to pass even C class check :) Such check are
> under way right now.

I'm pretty sure our own infra wouldn't pass the C check, since we
don't recommend GPL3+ specifically but do recommend other licenses
(such as GPL2+).  Gentoo itself is not endorsed as a free distribution
on their site, because it packages non-free software (even if nothing
non-free is installed by default or required) - and the same is true
of Debian and just about any other linux distro you've heard of.

Indeed, if github happens to not endorse any specific license at all
it is possible that it would rate higher than we do on the Gnu scale.
:)  I think the only question is whether they have any non-free
Javascript which is required for the site to function.

For the most part I like their criteria, but their social contract is
not quite the same as our own.

That said, I'm interested in their findings all the same - hopefully
they'll be specific about any concerns they raise.  I suspect
Javascript would be the main issue if there is one (I'm just referring
to their grade of C - I doubt it would score higher).

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/17/15 7:36 PM, Rich Freeman wrote:
> On Sat, Oct 17, 2015 at 7:14 PM, Andrew Savchenko <bircoph@gentoo.org> wrote:
>> FSF announced GNU ethical criteria for code repositories:
>> https://www.fsf.org/news/gnu-ethical-repo-criteria
>> https://www.gnu.org/software/repo-criteria.html
>>
>> We should take it into consideration as well. I really doubt that
>> GitHub will be able to pass even C class check :) Such check are
>> under way right now.
> I'm pretty sure our own infra wouldn't pass the C check, since we
> don't recommend GPL3+ specifically but do recommend other licenses
> (such as GPL2+).  Gentoo itself is not endorsed as a free distribution
> on their site, because it packages non-free software (even if nothing
> non-free is installed by default or required) - and the same is true
> of Debian and just about any other linux distro you've heard of.
>
> Indeed, if github happens to not endorse any specific license at all
> it is possible that it would rate higher than we do on the Gnu scale.
> :)  I think the only question is whether they have any non-free
> Javascript which is required for the site to function.
>
> For the most part I like their criteria, but their social contract is
> not quite the same as our own.
>
> That said, I'm interested in their findings all the same - hopefully
> they'll be specific about any concerns they raise.  I suspect
> Javascript would be the main issue if there is one (I'm just referring
> to their grade of C - I doubt it would score higher).
>
Andrew thanks for this.  Its nice to see that open source communities 
outside of our own are engaging similar concerns.  Let's keep an eye on 
what the FSF and GNU have to say about github.

Rich, they are purists, and we don't have to follow their guidelines to 
the letter, but they may provide useful insight.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 18/10/15 01:14, Andrew Savchenko wrote:
> FSF announced GNU ethical criteria for code repositories: 
> https://www.fsf.org/news/gnu-ethical-repo-criteria 
> https://www.gnu.org/software/repo-criteria.html
As I have discussed elsewhere this morning, these criteria are rather
bad. One problem is that there are several vague criteria. But more
importantly, there are several criteria that are completely unrelated
to the issue at hand. Some of these are important issues themselves,
like accessibility. Some are just stupid, like not allowing the site
to recommend SaaSS, when the sites themselves are in fact SaaSS.

Some are trying to push unrelated FSF politics -- like "you need to
say GNU/Linux when we think you might be talking about a GNU+Linux
system, not just Linux". To make that one even worse, it's actually
considered *more important* than *accessibility for the handicapped*
and *anonymity*.

If GNU are able to fix these criteria, I think they would be useful
for us. Right now I don't think they are though.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWJgsmAAoJENQqWdRUGk8BuOcQAOrO4Sv5rJnL8wpuKqbJBRsA
0x440ZYdsJZ688d45cSDG+wRQxB5FJK1tt8WskIh01mEW79jnwsBw/qW3cS2RAK4
E7TtUWs+WgIm/Ynh9ZcRotjcGCtH0+HgpTJBVQp+Ytl2SZDdBaYXylPqlPKv/VTU
PEiLSHMZJ2t71bVH3seBYx96t3uTEoplfXVOvJ7l9/+u4YvGV9PXLx09lvp/efdC
aU9vW6cgiGigUliUwHuzOgXqSM3mdmI6LJnt9FOG2IVgqupuzkjlJtWYYm2H0H3Y
CYRlONwPMFHH2oXTOIzU+Gdgv98YKBZIBPRh3v5Ux0nSjWFY8XoF31Cn5WWryd57
GC9TNMpuG1GQbRyrDf73XN4lkSD/hpuxHWSSu4g2Nnc2KoAvCg/Ard4KjzvEAfjB
7q1mSfF2evuuRremE4D50TDsHr3q1wMCPcwlfQFTAP++EDRV7RB0rTXSgekp+yA1
Zz1UUD9jmKZ6Us+p8lCEZR+gocSu9/nzJH4MDE0PB8CGBjPzcpHBL5i6a6CVMduY
KvAlpz+QP97IWZbIVgaq+zg3Y36sl2tqQuG/XHn0H7RaaO9R6Ho4AJ0UahqcaNaG
koLTAjrPEo43B4EWWfOa+Z/8rIb57bnHXfigrj+i0ZcYjXV8ObycCtDfHC/2fcLK
fWsmrlFI49zRU5EIs6E+
=ROpl
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Tue, Oct 20, 2015 at 5:36 AM, Alexander Berntsen <bernalex@gentoo.org> wrote:
>
> Some are trying to push unrelated FSF politics -- like "you need to
> say GNU/Linux when we think you might be talking about a GNU+Linux
> system, not just Linux". To make that one even worse, it's actually
> considered *more important* than *accessibility for the handicapped*
> and *anonymity*.
>

Agree.

I probably won't put too much stock in whether sites get an A/B/C/F
from the FSF on its own.

However, if they do assessments that are broken down against each of
their criteria I think that would be useful.  I think there is value
in knowing whether a site has sources available for their javascript
or if it requires the use of javascript.  I just don't see why that
gets lumped in with "must promote GPL3+ (specifically) at least as
much as other licenses" - gentoo.org fails their criteria here,
because we use the apparently-now-evil GPL2+ which the FSF originally
created.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 20/10/15 12:05, Rich Freeman wrote:
> gentoo.org fails their criteria here, because we use the 
> apparently-now-evil GPL2+ which the FSF originally created.
FSF do not recommend GPLv2 any longer because they identified a
weakness in it that they addressed in GPLv3. (Gentoo should not use
GPLv2, but that is a separate issue.) It is furthermore a nonsensical
observation either way, as gentoo.org is not a source code host
provider for the general public.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWJhM0AAoJENQqWdRUGk8BbPoQAM+QAVLAHUg/pst1qTA1Ht2C
fpVeyx4UFo2Wl3zOx/pmnQT+R0/9FqIUrPv2C6+2qUPts7OCdZHDZwPfGDEUDB90
zLWjcE/Hgj0KQMsYAAD/RkNOPp5h6Naa49H014JoRFXoiIjn7Wot670RAFBPfoLA
r1VGFZhXNP11QRdjnaU2PhNJUjmnh7vXSVy7414cnL+azH9VTuS94qt6NY7CA7Ui
WOVSO6wEsZsDvANgWeUjVqk+64Iy2yQUA7YHPOsW9ebLrxKALU+hdgugTlQQGYx6
WteDhWuTleDRc6QwunMZJlgnxbJazmpVu+gMM9JBtrBqY/DJMfubr3Td7PWwOJsX
ZrmdZHdR1WAAehbPo3vx2tABDx/wQtyTvBeNHDClczYm3cDpYKJPakzDbUeOr5Mo
hS2Ul/cTKioResyIIl/UeRaDzrdh2Wlm9rZBUeLQ2pMTJ4fX0pukIWBx4CqX+p9Z
q6zz+JyHbERPiuPfa5oSFb2/2yRhs7Wt4RqcmGJpf2P1fDPHYDn6w4WK4MyvZ1N3
6TPn/3dxZsWYzooPKkiin90St32ZPj7fQ5cbiLUNbdDUs6KDxlCLNPPYLpMPAh/X
7hfGxnOZ6+Em3X4RQX5lClSc+dHefqwUERT3OL1AZ9vKmmir1Efe1byoU1rdf8CC
fR8YIn4R36cVjvKZnYM3
=lRTc
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/10/2015 08:56 PM, Andrew Savchenko wrote:
> On Fri, 9 Oct 2015 14:15:15 +0200 hasufell wrote:
>> On 10/09/2015 01:56 PM, Anthony G. Basile wrote:
>>> Well let's think about this.  If github went away, or we needed to part
>>> ways with github, what we would we want to keep from their site?
>>
>> It is more likely that our infra servers go down or break than github.
>> From a reliability standpoint, our infra servers clearly lose.
> 
> This is not a question of infrastructure high availability, this is
> a question of the data long-term availability. GitHub is outside of
> our control. If it perishes, we are in trouble, big trouble if we
> stored important data and had important workflow via GitHub only.
> 
> And unfortunately the words above are not sheer speculation.
> 
> 1) GitHub _was already blocked_ in several countries [1]. We are an
> international community, thus we can't rely on such resource.
> 

We do not rely on it as you make it sound. Most big projects have
multiple contribution channels and because they do have more than one,
the data is even more safe. Not the other way around.

Since most of github related actions are recorded via mails, we won't
even have to care if it gets shut down. We have the data. And we still
have the git repository. We just lost one contribution platform which
was _never_ mandatory.

And as long as it is not mandatory, all your fears are completely misguided.

The only problem that arises is the desync of data. Mgorny was trying to
fix it, until you came up (sorry if that sounds offensive, but that's
what I got from the flow of the discussion).

> 2) Since GitHub is not completely open, it has a rist of following
> SourceForge fate. Before GitHub appeared SourceForge was probably
> the most popular development platform, at least 8-10 years ago.
> They were good guys. Later their owner changed, their policy
> changed, with known consequences: now SourceForge is known for its
> project hijacking [2] and adware. The worst result is that
> SourceForge is damaged good Free Software projects, e.g. GIMP [3]
> and now blocked by most anti-ads software [4,5]. 
> 
> And now GitHub are good guys. But for how long?
> I want to ensure long-time project stability of Gentoo, that's why
> I can't accept the violation of the Gentoo Social contract, which
> was made to protect the project from dangers alike this one. That's
> why we must have our own infrastructure.
> 

Again: we already have our own infrastructure. Github is optional.

> Please note, nobody says: you can use GitHub only overy my dead
> body. As can be seen from this discussion, there is a solution: all
> GitHub data must be mirrored on our infrastructure in a usable and
> searchable way, so that:
> 1) we will ensure long-time availability of all development data;
> 2) no single developer will be force to use GitHub to "politely
> review pull requests" or whatever.
> 

Yes, the proposed solution seems to have gone down in all that spam of
the previous posts. This ML should really be moderated.

However, instead of repeating your fears over and over again you could
just connect with the involved people and infra to help moving forward
that solution. From the way you argue about this, I suspect you have a
lot of energy and time to help.

In addition... who is going to mirror all Freenode data to our own
infrastructure? Are you going to help with that too? If not, then I
suggest you slow down a little bit and don't offend all the gentoo
projects that are running overlays on github since years in order to be
more open to contributions.

You didn't really make it sound like you want to improve something, so
that's probably why people got pissed off. Are you going to offer that
help now?

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Matt Turner]

On Thu, Oct 8, 2015 at 11:24 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Oct 8, 2015 at 11:01 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> So perhaps it was unwise for us to get into a situation where either 1) we
>> violate the Social Contract or 2) we have to surmount a technically
>> difficult situation.
>>
>
> I don't see how mirroring github on bugzilla violates our social
> contract, for several reasons:

That's not what his claim was. You misunderstood, so most of the rest
of your reply is irrelevant.

To explain, his claim was that we either (1) will be violating the
Social Contract by relying on github, or (2) have to solve a difficult
technical problem (to mirror github data in bugzilla).

> 1.  Developers aren't required to post patches to bugzilla before
> committing them to the tree, so nothing is lost by posting patches on
> github that might otherwise not be posted anywhere.
> 2.  Developers aren't required to open bugs on bugzilla before fixing
> bugs.  So, nothing is lost by opening pull requests on github that
> might otherwise not be opened anywhere.
> 3.  Developers aren't required to close bugs on bugzilla even if other
> people do open them.  Sure, that might be "rude" in some sense, and
> others can of course step in and co-maintain packages and close bugs.
> But, we don't kick out developers if they ignore bugs.  I don't think
> we'd even treeclean a package with an open critical security bug if
> the developer fixed the bug in the repo and just left the bug open.
>
> Bugzilla is already an optional part of our workflow as far as I can
> tell.  The proposal is to just add another optional tool to the
> workflow.

I find that to be absurd, and I really don't think that "bugzilla is
just an optional tool" is a serious argument.

> The proposed integration is just another way to enter data into
> bugzilla.  Devs are free to pretend that no data exists which isn't in
> the bug, and if somebody contributes a patch the dev is more than
> welcome to donate their time independently creating and testing the
> same patch instead of looking in a proprietary tool to see the patch
> somebody helpfully donated to us already.
>
> Nobody is required to use github to contribute to Gentoo, and nothing
> is really lost that we'd otherwise be certain to have if it goes away,
> so I don't see the conflict with our social contract.

Again, you're making a silly point that people don't *have* to use bugzilla.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Dnia 2015-10-08, o godz. 11:01:49
"Anthony G. Basile" <blueness@gentoo.org> napisał(a):

> So perhaps it was unwise for us to get into a situation where either 1) 
> we violate the Social Contract or 2) we have to surmount a technically 
> difficult situation.
> 
> Perhaps those responsible for doing so should fix this.

Thank all of your for your continuous support. I will not be deploying
any scripts to improve integration in any way. If you want to take this
over, the script is in repo-mirror-ci, in github-pr-sync branch, I
think. I suggest you copy it somewhere because I may randomly remove
the branch when cleaning up the repo at some point.

We will be handling GitHub pull requests on our own. If someone is
willing to contribute, sure. If someone is not, I don't care. This is
the end of the topic as far as I'm concerned, and I guess we can remove
the item from the Council agenda to offload the unnecessarily
overburdened Council from dealing with problems that have no solution.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Thu, Oct 8, 2015 at 2:30 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> Thank all of your for your continuous support. I will not be deploying
> any scripts to improve integration in any way.

Ok, this makes this the second item on the agenda where the proponents
essentially have announced an intention to quit before the meeting
because of voiced disagreement.  As with the other, I suggest we move
forward and discuss/decide so that at least the issue has some closure
and either Michał or others have a sense of what does and doesn't have
support.

Gentoo is a relatively large project.  If this were a group of 5
self-selected developers maybe we could all just do our own thing and
rely on the fact that we knew we agreed on everything before we
started.  If we had a big complex release process we could perhaps
rely on the fact that revert wars and such aren't really visible to
our users.  We have neither of those, so we need to have at least a
semblance of governance before we go making changes.

In both of the cases at hand (dynamic deps and github integration) the
proponents have known for many months that the issues were
controversial.  When you propose any change you're going to have to
expect opposition.  When you propose a controversial change you're
deluding yourself if you think you'll avoid it.

People have a right to voice contrary opinions with reasoned
arguments.  The fact that not everybody agrees with those arguments
does not diminish their value.

You do have a right to expect timely resolution of the issues, but the
council meeting schedule isn't a mystery.  We meet once a month per
the wiki page, and the meeting chairs are all pre-announced.  Your
issue will be discussed on the lists before we meet, as a courtesy to
the entire community so that we can make informed and reasoned
decisions, and there is no appearance of insiders/etc.  We just have
too many users to go shooting from the hip on things that are directly
visible to them, even if this might have been more fashionable at a
time in the past.

I appreciate the efforts individuals and teams go through to come up
with new features, and seeing them criticized, perhaps unfairly, is no
doubt difficult.  However, there are others in Gentoo who contribute
and they need us to have some kind of semblance of policy to do so.
That includes teams like QA, or Comrel, or Infra, who don't want to be
the referees in revert wars and battles over bugzilla configuration
and so on.  They count on some kind of semblance of order to do their
jobs.  So does the entire developer community, because in the end
we're all trusting each other to cooperate.

The Council doesn't operate solely as a popularity contest.  We don't
print out and weigh the emails for and against to make every decision.
Bring your arguments to the lists.  You don't have to have the last
reply to every email to win.  Indeed, you don't /necessarily/ need to
reply to any of them to win.  So, take a break from the argument if it
is making your blood boil.  Half the time when people seem to want to
give up on issues it is in cases where 6/7 council members seem
inclined to support them.  You'll never persuade everybody, nor do you
have to.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Matt Turner]

On Fri, Oct 9, 2015 at 2:35 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Oct 8, 2015 at 2:30 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> Thank all of your for your continuous support. I will not be deploying
>> any scripts to improve integration in any way.
>
> Ok, this makes this the second item on the agenda where the proponents
> essentially have announced an intention to quit before the meeting
> because of voiced disagreement.  As with the other, I suggest we move
> forward and discuss/decide so that at least the issue has some closure
> and either Michał or others have a sense of what does and doesn't have
> support.

I don't believe it was because of voiced disagreement, but rather that
Michał found the comment from Anthony ("Perhaps those responsible for
doing so should fix this.") to be offensive given that he *is actively
working on it*. At least, that's how I'd feel.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Anthony G. Basile]

On 10/9/15 9:51 PM, Matt Turner wrote:
> On Fri, Oct 9, 2015 at 2:35 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Thu, Oct 8, 2015 at 2:30 PM, Michał Górny <mgorny@gentoo.org> wrote:
>>> Thank all of your for your continuous support. I will not be deploying
>>> any scripts to improve integration in any way.
>> Ok, this makes this the second item on the agenda where the proponents
>> essentially have announced an intention to quit before the meeting
>> because of voiced disagreement.  As with the other, I suggest we move
>> forward and discuss/decide so that at least the issue has some closure
>> and either Michał or others have a sense of what does and doesn't have
>> support.
> I don't believe it was because of voiced disagreement, but rather that
> Michał found the comment from Anthony ("Perhaps those responsible for
> doing so should fix this.") to be offensive given that he *is actively
> working on it*. At least, that's how I'd feel.
>
Thank you Matt, and you are right.  I retract that statement and apologize.

Michal, I'm sorry for an unnecessarily provocative statement and will 
work with you to move forward if you so wish.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Donnerstag, 8. Oktober 2015, 20:30:32 schrieb Michał Górny:
> Dnia 2015-10-08, o godz. 11:01:49
> 
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> > So perhaps it was unwise for us to get into a situation where either 1)
> > we violate the Social Contract or 2) we have to surmount a technically
> > difficult situation.
> > 
> > Perhaps those responsible for doing so should fix this.
> 
> Thank all of your for your continuous support. I will not be deploying
> any scripts to improve integration in any way.

Oh please. A number of fitting replies to this comes into my mind, however 
sadly none of them would really be in line with our code of conduct.

Why does it always have to be "my way or the highway"? If you do participate 
in a bigger project you will have to compromise at some point.

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWGFAEAAoJEB9VdM6hupKVb+8QAJ7K8VOv4aA/6pGHk98FUltz
acQRkZm7pdFofvh2mEVIcRfFojqDwECTmoXASLHCxnxK5mEEIQzMIruPpDsmMJmF
c2TJHrIrY0WSU8sUmGum0hlfSvTuPjCJT9pBOkOMdcr/cBePbRU0Pw0jB1vQbTbs
IUsmDCfuYEOWfdJ2IE0OBcgSE1toHYNM/xBhXfnHRuDWkgBtxs8zB0bTE6zBX5PD
meocksJBsxJUq+ntXYXuLG1ZR3W4C2nnXJdue39ZgL1fBHh2LlBPadx/wuvYOEhp
9q5X7uXrrfh2mPGrCQVDN6G/Gc+RRqsOlEW56Z/Z8gnN1JHH5QUJz8mAJbm6hgTF
pP2vLMxUqIXulMazDg773qM5/SVPPkUihPgvFMuo0O+FZyux0cWMHDPduauy7Am3
ECrdE00r3HvizeL0fVQg0uh13SY4b3GbjOos3stjzgnlXVbex+xs5KYBo7IGTQFt
djV/ccvuDcloYW+WL2NCtQhpVOL+MdlcDcTsnTnLMo9hyoNBpOiUgQ26DWlHQAxo
qH267XqU5AiIO4OHu0UfZgtV7c0yXx8Hlw4pvL6dNs29YvL5UP6w3acksxFkQVd0
z1Y/3wkthj+mSjYxuA2CxIDpNkWdNRT78rqjkEvMBMz5QiwDF/Osv7UdgH7GlCXk
ZwufwL6uwobLApS2DZ7z
=rMcy
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Dnia 2015-10-10, o godz. 01:38:43
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Am Donnerstag, 8. Oktober 2015, 20:30:32 schrieb Michał Górny:
> > Dnia 2015-10-08, o godz. 11:01:49
> > 
> > "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
> > > So perhaps it was unwise for us to get into a situation where either 1)
> > > we violate the Social Contract or 2) we have to surmount a technically
> > > difficult situation.
> > > 
> > > Perhaps those responsible for doing so should fix this.
> > 
> > Thank all of your for your continuous support. I will not be deploying
> > any scripts to improve integration in any way.
> 
> Oh please. A number of fitting replies to this comes into my mind, however 
> sadly none of them would really be in line with our code of conduct.

Are you aware that you are *not* helping?

> Why does it always have to be "my way or the highway"? If you do participate 
> in a bigger project you will have to compromise at some point.

No, it's not that. It is the fact that I'm working hard and giving my
hand over and over again to the people that don't want to use GitHub.
I'm trying hard to find a solution, and all I get back is aggression,
accusations and the attitude 'you go figure out how to satisfy me'.

I'm not the only developer in Gentoo, and I'm one being particularly
tired of how some of the developers are trying to operate Gentoo. Maybe
it's time some developers learn how to do something themselves rather
than inventing bright ideas that are supposed to be carried out by
others.

As you can see from the attitude here, my work is unwanted
and pointless. I'm going to find a better use for my time.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Matt Turner]

On Thu, Oct 8, 2015 at 11:30 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2015-10-08, o godz. 11:01:49
> "Anthony G. Basile" <blueness@gentoo.org> napisał(a):
>
>> So perhaps it was unwise for us to get into a situation where either 1)
>> we violate the Social Contract or 2) we have to surmount a technically
>> difficult situation.
>>
>> Perhaps those responsible for doing so should fix this.
>
> Thank all of your for your continuous support. I will not be deploying
> any scripts to improve integration in any way. If you want to take this
> over, the script is in repo-mirror-ci, in github-pr-sync branch, I
> think. I suggest you copy it somewhere because I may randomly remove
> the branch when cleaning up the repo at some point.
>
> We will be handling GitHub pull requests on our own. If someone is
> willing to contribute, sure. If someone is not, I don't care. This is
> the end of the topic as far as I'm concerned, and I guess we can remove
> the item from the Council agenda to offload the unnecessarily
> overburdened Council from dealing with problems that have no solution.

I don't believe his "Perhaps those responsible for doing so should fix
this." comment was warranted, and can definitely understand why you
find it offensive, since you're *doing the work*, but please don't
"take your ball and go home" so to speak. Your contributions are
extremely valuable, and I don't think we'd be where we are today
without them. (Check out the increase in the number of contributors
since the switch to git! [1])

[1] https://www.openhub.net/p/gentoo

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michael Orlitzky]

On 10/08/2015 10:09 AM, Michał Górny wrote:
> 
> Potential alternative is to back-mirror pull requests in
> git.gentoo.org and work on that. But that's likely to cause even more
> uproar.
> 

Why would this be a problem? Suppose we copy the "gentoo.git" directory
on git.gentoo.org to "gentoo.github" or something like that.

All pull requests come from a branch -- essentially our gentoo.git with
some more commits on top of it. Couldn't we mirror every pull request
(which is really just a series of additional commits) onto a branch of
gentoo.github? Then point bugzilla at that.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Thu, 8 Oct 2015 14:48:31 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> All pull requests come from a branch -- essentially our gentoo.git
> with some more commits on top of it. Couldn't we mirror every pull
> request (which is really just a series of additional commits) onto a
> branch of gentoo.github? Then point bugzilla at that.

You may already know this but that it's worth mentioning that is super
easy to do.

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Github_PRs_made_easy

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Andreas K. Huettel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Am Donnerstag, 8. Oktober 2015, 20:48:31 schrieb Michael Orlitzky:
> On 10/08/2015 10:09 AM, Michał Górny wrote:
> > Potential alternative is to back-mirror pull requests in
> > git.gentoo.org and work on that. But that's likely to cause even more
> > uproar.
> 
> Why would this be a problem? Suppose we copy the "gentoo.git" directory
> on git.gentoo.org to "gentoo.github" or something like that.
> 

Sure (just let's use a separate repo for it since not everyone wants to 
download all these blobs forever). It's not so 100% clear cut though, since 
with pull requests a force push to update it is more or less the norm, meaning 
the history gets lost.

In combination with some sort of notification archiving (shove it into 
archives.gentoo.org) that should be fine though.

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWGE7vAAoJEB9VdM6hupKVBLMP/i1ctW9GrDTAAot4PhID0/c1
aEkm5+6a9nBCKSYoRLbb4XBu2XsGIBYaijBwr39baq3HYrfD2AvY7SdY0Blv8CZX
6Wiwd+i+5KDVgInvRwhiI4j5ksjiC9kmx6dr1lexMfgzdRZFCbK4N100DtGKAaJ3
NU/oLT5cYI8RzNMUSE7yR5OKuVuvEpMmX1ZOfm/tWbwQ7B3HEnLXFhh1HZ3Gtj0U
lQp77J+XA9qfzNOIy5uIPty97fTXcieIvDhalj0T2UMbK6/3b/AiXEdzt02bQW6V
Zj4K381Z3UrZPPh1EpW8SKJ1B8Cd1UrMyzhYy2mnlDigFLwOc/vG51uhsO+7/0rw
lJI5wQkleDt+oEEg6YcvrddvXD0PQxx9BtUQzaC3KKH3BxNiCMFweINJXOTH/+Jv
N28+uH2VCH6XXqy0zYdGz5UvHNDZi/WXhMclPca0ngOy8aoCx7JuDDKZsjpgjEyi
Ph14SGTF5B9wTagwcuv4+B6swMwax2fpg1LoZT4UeDiabJsjzKLTSUzZAnTKkuny
GbJPghwhwDuI09qrlKeHACXHPIWKIzETSNwF69HHDnRNnNrwYpCvkvVv0aTHkg/6
gbOPDtxSHRAercE9qX+KGONOpgW9I/pyZ9j59ABKDboJOdxSn0KUs8E0NBnKsQxB
0CAomFGfmToeFbaRnFtV
=1UM2
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

Dnia 2015-10-10, o godz. 01:34:07
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Am Donnerstag, 8. Oktober 2015, 20:48:31 schrieb Michael Orlitzky:
> > On 10/08/2015 10:09 AM, Michał Górny wrote:
> > > Potential alternative is to back-mirror pull requests in
> > > git.gentoo.org and work on that. But that's likely to cause even more
> > > uproar.
> > 
> > Why would this be a problem? Suppose we copy the "gentoo.git" directory
> > on git.gentoo.org to "gentoo.github" or something like that.
> > 
> 
> Sure (just let's use a separate repo for it since not everyone wants to 
> download all these blobs forever). It's not so 100% clear cut though, since 
> with pull requests a force push to update it is more or less the norm, meaning 
> the history gets lost.

Git *does not* download all refs by default. Putting pull requests
in gentoo.git won't affect the common fetch.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Wed, Sep 30, 2015 at 10:01 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> #gentoo-council on freenode.
>
> Please reply to this message with any items you would like us to discuss
> or vote on.
>

I'd like to actually drive to some kinds of votes around dynamic dependencies.

To that end I intend to propose a few concrete resolutions that can be
taken individually around changes in:
1. Direct runtime dependencies in ebuilds.
2. Dependencies in virtuals.
3. Dependencies in eclasses.

In some cases I may publish more than one proposal, both to get some
discussion, and also in the hope that we have an alternative ready
should some options not be approved.

I'm posting this now though as a placeholder and to get it in this thread.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Wed, Sep 30, 2015 at 3:12 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Sep 30, 2015 at 10:01 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
>>
>> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
>> #gentoo-council on freenode.
>>
>> Please reply to this message with any items you would like us to discuss
>> or vote on.
>>
>
> I'd like to actually drive to some kinds of votes around dynamic dependencies.
>
> To that end I intend to propose a few concrete resolutions that can be
> taken individually around changes in:
> 1. Direct runtime dependencies in ebuilds.
> 2. Dependencies in virtuals.
> 3. Dependencies in eclasses.
>
> In some cases I may publish more than one proposal, both to get some
> discussion, and also in the hope that we have an alternative ready
> should some options not be approved.
>
> I'm posting this now though as a placeholder and to get it in this thread.

Proposals posted at:
http://thread.gmane.org/gmane.linux.gentoo.devel/97428/focus=97480

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Manuel Rüger]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On 30.09.2015 16:01, Andreas K. Huettel wrote:
> Dear all,
> 
> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> #gentoo-council on freenode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.
> 
> The summary of the last meeting will be uploaded over the next 2-3 days; my 
> apologies for the delay.
> 
> Thanks,
> Andreas
> 

I'd like the council to vote on EAPI 4 deprecation.

Rationale: As [1] shows, it takes a long time to remove packages using
deprecated EAPI versions from the tree. Marking EAPI 4 as deprecated,
leaves us with EAPI 5 as the only "modern" EAPI, resulting in a
(hopefully) quicker removal of old EAPIs, as developers will consider
bumping to the latest EAPI when version/revbumping ebuilds (as repoman
will mention the deprecated EAPI).

[1] http://www.akhuettel.de/~huettel/plots/eapi.php


Cheers,

Manuel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 605 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Wed, Sep 30, 2015 at 10:01 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
>
> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> #gentoo-council on freenode.
>
> Please reply to this message with any items you would like us to discuss
> or vote on.
>

So, this has been going around in various circles, and I think it is
better to just air stuff out here.  There are lots of arguments for
and against this.  I'm interested in what the general sense is, beyond
just those who have been vocal in bringing this up.

I'd like the Council to consider:
1.  Decide that games should not be owned by a games group, and that
in the default configuration users should not have to be in the games
group to run games.
2.  Games should be installed in /usr and not /usr/games as with most
applications
3.  Assuming 1&2 are both approved, deprecate games.eclass.  Otherwise
modify it accordingly.
4.  If 1&2 aren't approved, when should the games policy apply?  Does
it include games bundled in kde/gnome/etc?  Do we intend to give more
or less deference to maintainers when there is a dispute over whether
something is a "game?"  I'm not going to ask the Council to define
"game."

I don't want to get too much further into detail than that (does
nethack bones go in /var/lib/nethack, or /var/lib/games/nethack, and
what gid is used?).  I think that beyond a point it is best left to
the games team or maintainers.  Honestly, I'm not even 100% convinced
that we shouldn't leave the whole thing to the games team, but right
now we don't have an active one, and it seems like a lot of people are
passionate about it so I'm more inclined to set a policy now than let
the games team set a policy and then yell at them for getting it
wrong.

I'll go ahead and say now that from a personal standpoint I think we
should approve 1&2, deprecate the eclass, and #4 is moot.  I'm not
sure I'll end up voting that way because Gentoo policy is more than
personal preference, but I'm thinking that simpler is better here, and
it works for everything else that involves moving images on the
screen, sound, etc.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

>>>>> On Thu, 1 Oct 2015, Rich Freeman wrote:

> So, this has been going around in various circles, and I think it is
> better to just air stuff out here.  There are lots of arguments for
> and against this.  I'm interested in what the general sense is,
> beyond just those who have been vocal in bringing this up.

> I'd like the Council to consider:
> 1.  Decide that games should not be owned by a games group, and that
> in the default configuration users should not have to be in the
> games group to run games.

Definitely +1 from me. We should get rid of the games group
altogether.

> 2.  Games should be installed in /usr and not /usr/games as with most
> applications

I have no strong opinion on this one. There are arguments for both
alternatives.

> 3.  Assuming 1&2 are both approved, deprecate games.eclass.
> Otherwise modify it accordingly.
> 4.  If 1&2 aren't approved, when should the games policy apply?
> Does it include games bundled in kde/gnome/etc?  Do we intend to
> give more or less deference to maintainers when there is a dispute
> over whether something is a "game?"  I'm not going to ask the
> Council to define "game."

> I don't want to get too much further into detail than that (does
> nethack bones go in /var/lib/nethack, or /var/lib/games/nethack, and
> what gid is used?).  I think that beyond a point it is best left to
> the games team or maintainers.  Honestly, I'm not even 100% convinced
> that we shouldn't leave the whole thing to the games team, but right
> now we don't have an active one, and it seems like a lot of people
> are passionate about it so I'm more inclined to set a policy now
> than let the games team set a policy and then yell at them for
> getting it wrong.

I want to point out that we have a QA policy on shared high-score or
game state files:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games

It's short enough to quote it here:
"Games that need privileged access to shared high-score or game state
files can be installed setgid (mode g+s or 2755). Group "gamestat"
with gid 36 (but not the "games" group) should be used for them.
The files for state/scores should then be created in /var/games or
a subdirectory of it and have appropriate owner and permissions
(root:gamestat, mode g+w)."

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]

Dnia 2015-10-01, o godz. 08:32:01
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Wed, Sep 30, 2015 at 10:01 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
> >
> > the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> > #gentoo-council on freenode.
> >
> > Please reply to this message with any items you would like us to discuss
> > or vote on.
> >
> 
> So, this has been going around in various circles, and I think it is
> better to just air stuff out here.  There are lots of arguments for
> and against this.  I'm interested in what the general sense is, beyond
> just those who have been vocal in bringing this up.
> 
> I'd like the Council to consider:
> 1.  Decide that games should not be owned by a games group, and that
> in the default configuration users should not have to be in the games
> group to run games.

This one has passed yesterday.

> 2.  Games should be installed in /usr and not /usr/games as with most
> applications

This one was 2y-2n-3a, so I think we should try to reconsider it from
another perspective to get more uniform vote. New facts about FHS also
came up during the meeting.

The specific directories, and they relevance to PMS:

| GAMES_PREFIX=${GAMES_PREFIX:-/usr/games}
| GAMES_BINDIR=${GAMES_BINDIR:-${GAMES_PREFIX}/bin}

Custom Gentoo prefix. Implicitly causes /usr/games/bin for
binaries, /usr/games/lib* for libraries.

PMS states only /usr/games as bindir for games (i.e. no /bin subdir, no
libraries).

| GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt}

Not used directly, only for prepgamesdirs which is going out.

| GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games}

PMS valid.

| GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share}

Not used at all. Intended for use when game appends 'games' itself...

| GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games}

Custom Gentoo path.

| GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games}

PMS valid.

| GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games}

Gentoo custom.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

>>>>> On Mon, 12 Oct 2015, Michał Górny wrote:

> Dnia 2015-10-01, o godz. 08:32:01
> Rich Freeman <rich0@gentoo.org> napisał(a):

>> 2.  Games should be installed in /usr and not /usr/games as with
>> most applications

> This one was 2y-2n-3a, so I think we should try to reconsider it
> from another perspective to get more uniform vote. New facts about
> FHS also came up during the meeting.

> The specific directories, and they relevance to PMS:

1,$s/PMS/FHS/g; :)

> | GAMES_PREFIX=${GAMES_PREFIX:-/usr/games}
> | GAMES_BINDIR=${GAMES_BINDIR:-${GAMES_PREFIX}/bin}

> Custom Gentoo prefix. Implicitly causes /usr/games/bin for
> binaries, /usr/games/lib* for libraries.

> PMS states only /usr/games as bindir for games (i.e. no /bin subdir,
> no libraries).

I believe that installing binaries directly in /usr/games is not an
option for us, because of the existing subdirs. So if we decide to
keep /usr/games then binaries must stay in /usr/games/bin.

Not sure about /usr/games/lib*. If we follow the system of
/usr/share/games then libraries should be installed in /usr/lib*/games
(which is sort of pointless, because then they could as well go to
/usr/lib* directly).

> | GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt}

> Not used directly, only for prepgamesdirs which is going out.

/opt needs to stay the install location for binary-only packages.
I think this is clear and we don't need a decision.

> | GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games}

> PMS valid.

> | GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share}

> Not used at all. Intended for use when game appends 'games' itself...

> | GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games}

> Custom Gentoo path.

I have no strong opinion about /usr/share/games vs /usr/share and
/etc/games vs /etc. The additional subdir doesn't do any harm, but why
is it needed?

> | GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games}

> PMS valid.

Keep. Rationale is in FHS section 5.7.

> | GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games}

> Gentoo custom.

Won't work any more after dropping games user and group, because of
permission issues. FHS says game play logs should be placed in
/var/games too.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

Following up to this. I think the choice is between the two extremes
of keeping the status quo and of changing all non-FHS locations, or
some intermediate solution.

1. Keep status quo:

   /usr/games/bin     games binaries
   /usr/games/lib*    games libraries
   /usr/share/games   static games data
   /etc/games         games configuration
   /var/games         variable game data
   /var/log/games     games logs

2. Change all locations that are not conforming to FHS 3.0:

   /usr/bin           games binaries
   Rationale: The FHS has /usr/games as an optional directory for
   binaries, but we cannot use it because it is blocked by the current
   directory layout with /usr/games/{bin,lib*}.

   /usr/lib*          games libraries

   /usr/share         static games data
   Rationale: The FHS also allows an optional /usr/share/games but its
   description says "Static data files for /usr/games". So if the
   binaries are installed in /usr/bin then (as I read it) the data
   should go to /usr/share (i.e., to /usr/share/${PN} really).

   /etc               games configuration

   /var/games         variable game data
   Rationale: FHS section 5.7.: "Any variable data relating to games
   in /usr should be placed here."
   This could also be used for logs previously placed in
   /var/log/games, when for some reason they cannot got to /var/log
   (but AFAICS it would affect only two packages in the tree).

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Sun, Oct 18, 2015 at 4:58 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Following up to this. I think the choice is between the two extremes
> of keeping the status quo and of changing all non-FHS locations, or
> some intermediate solution.

The value of keeping the status quo is that it is the status quo, IMO.
Tweaking it makes it no longer the status quo and it just means lot of
change for questionable value (again, IMO).

I'd just as soon do away with the games eclass altogether if we're
going to make a change.  Then games become like any other package.
That is a state I think is worth changing for.  If we're just going to
move one or two directories around, I don't really see why we need to
make everybody jump through hoops, unless those few directories are
causing major problems today.

Sometimes the compromise between two arguable positions isn't
something that makes sense to anybody.  If we're going to change,
let's make sure that what we change to makes sense on its own.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

>>>>> On Sun, 18 Oct 2015, Rich Freeman wrote:

> The value of keeping the status quo is that it is the status quo,
> IMO. Tweaking it makes it no longer the status quo and it just means
> lot of change for questionable value (again, IMO).

> I'd just as soon do away with the games eclass altogether if we're
> going to make a change.  Then games become like any other package.
> That is a state I think is worth changing for.  If we're just going
> to move one or two directories around, I don't really see why we
> need to make everybody jump through hoops, unless those few
> directories are causing major problems today.

In fact, under the second option almost all locations would be the
standard locations. The single exception would be /var/games which is
used for shared highscore/bones files. These require special treatment
(permissions etc.) in any case.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/18/2015 11:18 PM, Rich Freeman wrote:
> On Sun, Oct 18, 2015 at 4:58 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> Following up to this. I think the choice is between the two extremes
>> of keeping the status quo and of changing all non-FHS locations, or
>> some intermediate solution.
> 
> The value of keeping the status quo is that it is the status quo, IMO.
> Tweaking it makes it no longer the status quo and it just means lot of
> change for questionable value (again, IMO).
> 

Not keeping status quo means:
1. less patching
2. less ebuild code
3. no misplaced menu files and friends in /usr/share/games/applications
and whatnot anymore, since DATADIR and DATAROOTDIR in e.g. autotools
based build systems have to be both defined to make this work (only in
case upstream has a sane build system). For cmake based build systems
this can be even more funny, depending on what upstream does.

Installing into these games directories is actually _uncommon_ and most
upstreams don't have these defaults.

But it will not be that painful once someone _actually_ deprecates
games.eclass, so we get rid of those GAMES_* variables that can point to
arbitrary non-FHS compliant directories. These are the biggest problem.


> I'd just as soon do away with the games eclass altogether if we're
> going to make a change.  Then games become like any other package.
> That is a state I think is worth changing for.  If we're just going to
> move one or two directories around, I don't really see why we need to
> make everybody jump through hoops, unless those few directories are
> causing major problems today.
> 
> Sometimes the compromise between two arguable positions isn't
> something that makes sense to anybody.  If we're going to change,
> let's make sure that what we change to makes sense on its own.
> 

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Sun, Oct 18, 2015 at 6:13 PM, hasufell <hasufell@gentoo.org> wrote:
> On 10/18/2015 11:18 PM, Rich Freeman wrote:
>> On Sun, Oct 18, 2015 at 4:58 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>> Following up to this. I think the choice is between the two extremes
>>> of keeping the status quo and of changing all non-FHS locations, or
>>> some intermediate solution.
>>
>> The value of keeping the status quo is that it is the status quo, IMO.
>> Tweaking it makes it no longer the status quo and it just means lot of
>> change for questionable value (again, IMO).
>>
>
> Not keeping status quo means:

My point wasn't that we should keep the status quo, but rather that if
we're going to make a change we should just go to the most sensible
design possible, and not just tweak a few things here and there.

I think this is one of those situations where compromise may not make sense.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

On Sun, 18 Oct 2015 22:58:31 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> Following up to this. I think the choice is between the two extremes
> of keeping the status quo and of changing all non-FHS locations, or
> some intermediate solution.
> 
> 1. Keep status quo:
> 
>    /usr/games/bin     games binaries
>    /usr/games/lib*    games libraries
>    /usr/share/games   static games data
>    /etc/games         games configuration
>    /var/games         variable game data
>    /var/log/games     games logs

This is no longer 'status quo', rather 'past status quo' which is
slowly removed in favor of whatever upstream uses.

> 2. Change all locations that are not conforming to FHS 3.0:
> 
>    /usr/bin           games binaries
>    Rationale: The FHS has /usr/games as an optional directory for
>    binaries, but we cannot use it because it is blocked by the current
>    directory layout with /usr/games/{bin,lib*}.
> 
>    /usr/lib*          games libraries
> 
>    /usr/share         static games data
>    Rationale: The FHS also allows an optional /usr/share/games but its
>    description says "Static data files for /usr/games". So if the
>    binaries are installed in /usr/bin then (as I read it) the data
>    should go to /usr/share (i.e., to /usr/share/${PN} really).

I'd say we shouldn't take FHS this strongly, and use whatever upstream
uses. If upstream uses /usr/share/games, so be it. If it
uses /usr/share directly, so be it. Otherwise, we end up patching stuff
and unnecessary patching is no fun at all. I still remember how much
code I had to patch to make random games comply to 'gentoo' locations.

>    /etc               games configuration
> 
>    /var/games         variable game data
>    Rationale: FHS section 5.7.: "Any variable data relating to games
>    in /usr should be placed here."
>    This could also be used for logs previously placed in
>    /var/log/games, when for some reason they cannot got to /var/log
>    (but AFAICS it would affect only two packages in the tree).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/18/2015 11:28 PM, Michał Górny wrote:
> On Sun, 18 Oct 2015 22:58:31 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
> 
>> Following up to this. I think the choice is between the two extremes
>> of keeping the status quo and of changing all non-FHS locations, or
>> some intermediate solution.
>>
>> 1. Keep status quo:
>>
>>    /usr/games/bin     games binaries
>>    /usr/games/lib*    games libraries
>>    /usr/share/games   static games data
>>    /etc/games         games configuration
>>    /var/games         variable game data
>>    /var/log/games     games logs
> 
> This is no longer 'status quo', rather 'past status quo' which is
> slowly removed in favor of whatever upstream uses.
> 

Exactly.

>> 2. Change all locations that are not conforming to FHS 3.0:
>>
>>    /usr/bin           games binaries
>>    Rationale: The FHS has /usr/games as an optional directory for
>>    binaries, but we cannot use it because it is blocked by the current
>>    directory layout with /usr/games/{bin,lib*}.
>>
>>    /usr/lib*          games libraries
>>
>>    /usr/share         static games data
>>    Rationale: The FHS also allows an optional /usr/share/games but its
>>    description says "Static data files for /usr/games". So if the
>>    binaries are installed in /usr/bin then (as I read it) the data
>>    should go to /usr/share (i.e., to /usr/share/${PN} really).
> 
> I'd say we shouldn't take FHS this strongly, and use whatever upstream
> uses. If upstream uses /usr/share/games, so be it. If it
> uses /usr/share directly, so be it. Otherwise, we end up patching stuff
> and unnecessary patching is no fun at all. I still remember how much
> code I had to patch to make random games comply to 'gentoo' locations.
> 

Patching was probably in more than 90% of the cases not related to the
fact that we install into /usr/games and friends, but into eclass
variables that can be overridden by the user and that was/is a supported
games.eclass feature.

Installing consistently into /usr/bin, /usr/lib* and /usr/share will
require little to no patching, I am pretty sure of that. I converted
probably more than half of all games ebuilds to use these directories in
an overlay and all I did was removing patches and --prefix=foo lines.
It will also be consistent and not interfere with the old layout (as ulm
said, we cannot install into /usr/games), so transition will be safe.

But for /usr/share specifically we could indeed be a bit more lax. So
people should prefer /usr/share, but if it requires patching, they can
just go with /usr/share/games. But I did not hit that case yet.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

>>>>> On Sun, 18 Oct 2015, Michał Górny wrote:

>>    /usr/share         static games data
>>    Rationale: The FHS also allows an optional /usr/share/games but
>>    its description says "Static data files for /usr/games". So if
>>    the binaries are installed in /usr/bin then (as I read it) the
>>    data should go to /usr/share (i.e., to /usr/share/${PN} really).

> I'd say we shouldn't take FHS this strongly, and use whatever
> upstream uses. If upstream uses /usr/share/games, so be it. If it
> uses /usr/share directly, so be it.

No objections, as /usr/share/games is still in /usr/share.
The point is that we don't require things to be installed in a games
subdirectory.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/18/2015 02:28 PM, Michał Górny wrote:
> On Sun, 18 Oct 2015 22:58:31 +0200 Ulrich Mueller <ulm@gentoo.org> 
> wrote:
> 
>> Following up to this. I think the choice is between the two 
>> extremes of keeping the status quo and of changing all non-FHS 
>> locations, or some intermediate solution.
>> 
>> 1. Keep status quo:
>> 
>> /usr/games/bin     games binaries /usr/games/lib*    games 
>> libraries /usr/share/games   static games data /etc/games games
>> configuration /var/games         variable game data 
>> /var/log/games     games logs
> 
> This is no longer 'status quo', rather 'past status quo' which is 
> slowly removed in favor of whatever upstream uses.
> 
>> 2. Change all locations that are not conforming to FHS 3.0:
>> 
>> /usr/bin           games binaries Rationale: The FHS has 
>> /usr/games as an optional directory for binaries, but we cannot 
>> use it because it is blocked by the current directory layout
>> with /usr/games/{bin,lib*}.
>> 
>> /usr/lib*          games libraries
>> 
>> /usr/share         static games data Rationale: The FHS also 
>> allows an optional /usr/share/games but its description says 
>> "Static data files for /usr/games". So if the binaries are 
>> installed in /usr/bin then (as I read it) the data should go to 
>> /usr/share (i.e., to /usr/share/${PN} really).
> 
> I'd say we shouldn't take FHS this strongly, and use whatever 
> upstream uses. If upstream uses /usr/share/games, so be it. If it 
> uses /usr/share directly, so be it. Otherwise, we end up patching 
> stuff and unnecessary patching is no fun at all. I still remember 
> how much code I had to patch to make random games comply to 
> 'gentoo' locations.
> 
>> /etc               games configuration
>> 
>> /var/games         variable game data Rationale: FHS section 
>> 5.7.: "Any variable data relating to games in /usr should be 
>> placed here." This could also be used for logs previously placed 
>> in /var/log/games, when for some reason they cannot got to 
>> /var/log (but AFAICS it would affect only two packages in the 
>> tree).
> 
(Replying normally and CCing the list since Tbird didn't give me a
"Reply to List" option)


I'm in favor of sticking to upstream where possible. Keeping a bunch
of patches around would make the already-arduous work of games
maintenance even worse. I can appreciate the interest in keeping games
in one place, though, since some users would want their games to
perform well and put a specific path on an SSD or something. The key
part, imo, is whatever we decide on is realistic to implement and
doesn't ruin the filesystem structure. Some upstreams could be
considered less-than-ideal in their care (or lack thereof) when
dealing with directories and install locations.

Maybe we should take an inventory of some common games and determine
where upstream wants to put them in the first place.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWJB0LAAoJEAEkDpRQOeFwxIcP/Rt8/zUejhuCgVatnD+KFhqg
lNrTgkesuTRCl1Q5c2Fyjs6XaXoGxv0G+eVL3V0zlM8haHNY6bJL4+XnnthBD1qI
WyRT07xpFPbNPCXiBaYb2z4EaYugMjugHgmpYg6JFny4YNvOsTHGKDxwTqHegdB0
qmzkOVKj2k6gYGHs10mRHpVuDFF4kAvahafkKC41moD1LNcoJLzVALwT/UwZlB6s
hvWuwYiYcfOuDbyQXmYg5zuWP+77lfcLh1oUtcTzJW/L7H2EQCF4d+aREP1mUEnG
5q7LvIIUsdNyV8L7u0CifoHezK7Er23fn5LnSgvYXgBq0n+Efx9HWqSgcb/fuSfI
qTi4Gs6LMDt0PSRyetrI0/0DcthfVzsDuHyRxdiEMNHvZPJsRimNqm/6gm2B+n3h
/nglbx3IHLp0t0jkwHNA2DyGwFROlf59OQyPHlJ58gR7Mu5TbzoV9Ep5GJrE3pSg
31zkkoefLVGOgTWimsvKMbEZVqI0iA+3fQoJqrH3dXT756vfs45Pm0bFcjL+V93c
WWZrK+UByPTb2Xww6FVvnx04n+k/UQXus8FDRhcuiCqvZ2IsPDx4QUSsr0oylCMe
jDsnFktRWOPzvKzoRkW2FSfWRkR/nR2hYQVJRaFzHF07lOuYkAYnOIJ1GaEtz88U
yXRylZIf1mf4YsOl1GD3
=6avU
-----END PGP SIGNATURE-----

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Sun, 18 Oct 2015 15:28:28 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> Maybe we should take an inventory of some common games and determine
> where upstream wants to put them in the first place.

These days most games don't even bother trying to respect FHS at all.
Those that aren't only available through Steam are often designed to be
just unpacked and run in place. Most games comprise of a binary, some
bundled libraries, and some assets. Assuming you can unbundle all the
libraries, it's sometimes sufficient to put the assets somewhere
under /usr/share and then change to that directory in a wrapper before
executing the binary. The only question is where to put that
binary. /usr/share would be bad.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Sun, 18 Oct 2015 23:40:21 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> On Sun, 18 Oct 2015 15:28:28 -0700
> Daniel Campbell <zlg@gentoo.org> wrote:
> 
> > Maybe we should take an inventory of some common games and determine
> > where upstream wants to put them in the first place.  
> 
> These days most games don't even bother trying to respect FHS at all.
> Those that aren't only available through Steam are often designed to be
> just unpacked and run in place. Most games comprise of a binary, some
> bundled libraries, and some assets. Assuming you can unbundle all the
> libraries, it's sometimes sufficient to put the assets somewhere
> under /usr/share and then change to that directory in a wrapper before
> executing the binary. The only question is where to put that
> binary. /usr/share would be bad.

I'd say per FHS it would be /opt/foo or /usr/lib/foo (*not*
$(get_libdir)).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/19/2015 09:55 AM, Michał Górny wrote:
> On Sun, 18 Oct 2015 23:40:21 +0100
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
>> On Sun, 18 Oct 2015 15:28:28 -0700
>> Daniel Campbell <zlg@gentoo.org> wrote:
>>
>>> Maybe we should take an inventory of some common games and determine
>>> where upstream wants to put them in the first place.  
>>
>> These days most games don't even bother trying to respect FHS at all.
>> Those that aren't only available through Steam are often designed to be
>> just unpacked and run in place. Most games comprise of a binary, some
>> bundled libraries, and some assets. Assuming you can unbundle all the
>> libraries, it's sometimes sufficient to put the assets somewhere
>> under /usr/share and then change to that directory in a wrapper before
>> executing the binary. The only question is where to put that
>> binary. /usr/share would be bad.
> 
> I'd say per FHS it would be /opt/foo or /usr/lib/foo (*not*
> $(get_libdir)).
> 

Correct. They belong in /opt/foo and that's what we already do for
humble-bundle, gog and other binary-only games (steam games are mostly
irrelevant, since they cannot be packaged).

https://devmanual.gentoo.org/general-concepts/filesystem/index.html

> /opt: Binary-only applications.

That link also needs some updates.

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[hasufell]

On 10/12/2015 10:23 AM, Michał Górny wrote:
> Dnia 2015-10-01, o godz. 08:32:01
> Rich Freeman <rich0@gentoo.org> napisał(a):
> 
>> On Wed, Sep 30, 2015 at 10:01 AM, Andreas K. Huettel
>> <dilfridge@gentoo.org> wrote:
>>>
>>> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
>>> #gentoo-council on freenode.
>>>
>>> Please reply to this message with any items you would like us to discuss
>>> or vote on.
>>>
>>
>> So, this has been going around in various circles, and I think it is
>> better to just air stuff out here.  There are lots of arguments for
>> and against this.  I'm interested in what the general sense is, beyond
>> just those who have been vocal in bringing this up.
>>
>> I'd like the Council to consider:
>> 1.  Decide that games should not be owned by a games group, and that
>> in the default configuration users should not have to be in the games
>> group to run games.
> 
> This one has passed yesterday.
> 

From what I see, the games project didn't care about the QA vote [0]
either and have since been keeping their old workflow and using and
developing games.eclass further. What makes people think this will
change? Do we want to increase inconsistency now and have 3 layouts for
games or fix the underlying problem? I've seen numerous claims from the
council to do that, none of them were successful.

>> 2.  Games should be installed in /usr and not /usr/games as with most
>> applications
> 
> This one was 2y-2n-3a, so I think we should try to reconsider it from
> another perspective to get more uniform vote. New facts about FHS also
> came up during the meeting.
> 

FHS says that /usr/games is optional [1] (same for the other games
related locations) and it doesn't specify in what way this is optional,
so I think it makes sense to just leave it out and use standard
locations, which will also heavily reduce required patching.


[0]
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Games_team_policies_issue
[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#theUsrHierarchy

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

Dnia 2015-09-30, o godz. 16:01:16
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> the Gentoo Council will meet again on Sunday, October 11 at 19:00 UTC in
> #gentoo-council on freenode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.

Since apparently any tiny change requires Council approval these days,
here's another one...

Can I change the 'games' component of Bugzilla to assign bugs to
bug-wranglers@ rather than games@? Otherwise, newly reported game bugs
get assigned directly to games team and often are not reassigned to
correct maintainers but instead are left ignored.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Rich Freeman]

On Sun, Oct 4, 2015 at 7:13 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> Since apparently any tiny change requires Council approval these days,
> here's another one...

Trust me, we're as unhappy about this as anybody.

>
> Can I change the 'games' component of Bugzilla to assign bugs to
> bug-wranglers@ rather than games@? Otherwise, newly reported game bugs
> get assigned directly to games team and often are not reassigned to
> correct maintainers but instead are left ignored.

++ - in light of the decision that anybody can maintain a game apart
from the games team, it really doesn't make sense to have a bugzilla
component for games at all.  They should be assigned just like any
other generic package.

As long as we're expanding the scope of the discussion around the
games team, I'd like the council to ask themselves, "after we're done
approving or disapproving all the requested actions around the games
team, is there actually anything the games team is supposed to do?"
It seems to me that if all the proposed actions like getting rid of
the eclass, letting anybody maintain games, not auto-assigning bugs,
etc are all approved, then the games team is just a bunch of
individual games package maintainers that don't actually maintain all
the games.  To the extent that the council doesn't approve all the
requested actions, it might have additional functions.

This is starting to feel like one of those situations where ANY
decision is going to be better than kicking the can, but I acknowledge
that any decision we make firmly is going to leave some fairly
unhappy.

-- 
Rich

Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

Dnia 2015-10-04, o godz. 08:17:22
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Sun, Oct 4, 2015 at 7:13 AM, Michał Górny <mgorny@gentoo.org> wrote:
> >
> > Since apparently any tiny change requires Council approval these days,
> > here's another one...
> 
> Trust me, we're as unhappy about this as anybody.
> 
> >
> > Can I change the 'games' component of Bugzilla to assign bugs to
> > bug-wranglers@ rather than games@? Otherwise, newly reported game bugs
> > get assigned directly to games team and often are not reassigned to
> > correct maintainers but instead are left ignored.
> 
> ++ - in light of the decision that anybody can maintain a game apart
> from the games team, it really doesn't make sense to have a bugzilla
> component for games at all.  They should be assigned just like any
> other generic package.

Well, that was my point but other Infra members disagree that we aren't
allowed to change this without full Council approval.

And to be honest, if I were to expand the topic, I'd rather go towards
Bugzilla components on 'Gentoo Linux'. Because right now most of them
don't make any sense, and are confusing to new users who don't know
what to choose. They're pretty much all legacy, and as I see it most of
them should be removed and bugs moved to a single common component.

But that's a topic for another trollfest, I guess.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]