[gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Michał Górny]

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

Hello, developers.

We have added a new mail alias travis-ci@g.o and set up travis-ci [1]
to send notifications on status change there. Please seriously consider
adding yourself to the alias, and contributing to the quality
of Gentoo.

The mail load is low -- travis will only send notices when the state
changes from 'good' to 'bad', and the other way around. However, you
will need to manually grep the logs provided by travis for occurences
of 'FATAL'.

Please remember that keeping the repository in a broken state is
inconvenient both for users and other developers. In particular
the issues include:

1. dependency resolution errors blocking @world upgrades,

2. Portage unnecessarily switching packages to ~arch (and therefore
   reducing quality of stable systems),

3. repoman refusing to commit irrelevant changes to packages.

Therefore, whenever possible please try to fix the issues ASAP.

However, if you are not the person directly responsible for
the dependency graph breakage, please *reliably* inform him
about the revert/change you're doing. Failing to do has already
resulted in developers repeating their mistakes because of
misinformation.

Preferably, always file a bug in such a case and make it block
the 'broken-depgraph' tracker [2]. When assigning/CC-ing to the bug,
please make sure to include both the maintainers of the broken package,
and the maintainers of the dependency as necessary.

[1]:https://travis-ci.org/gentoo/gentoo-portage-rsync-mirror
[2]:https://bugs.gentoo.org/show_bug.cgi?id=broken-depgraph

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Andrew Savchenko]

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

On Thu, 9 Apr 2015 00:23:29 +0200 Michał Górny wrote:
> Hello, developers.
> 
> We have added a new mail alias travis-ci@g.o and set up travis-ci [1]
> to send notifications on status change there. Please seriously consider
> adding yourself to the alias, and contributing to the quality
> of Gentoo.
> 
> The mail load is low -- travis will only send notices when the state
> changes from 'good' to 'bad', and the other way around. However, you
> will need to manually grep the logs provided by travis for occurences
> of 'FATAL'.
> 
> Please remember that keeping the repository in a broken state is
> inconvenient both for users and other developers. In particular
> the issues include:
> 
> 1. dependency resolution errors blocking @world upgrades,
> 
> 2. Portage unnecessarily switching packages to ~arch (and therefore
>    reducing quality of stable systems),
> 
> 3. repoman refusing to commit irrelevant changes to packages.
> 
> Therefore, whenever possible please try to fix the issues ASAP.
> 
> However, if you are not the person directly responsible for
> the dependency graph breakage, please *reliably* inform him
> about the revert/change you're doing. Failing to do has already
> resulted in developers repeating their mistakes because of
> misinformation.
> 
> Preferably, always file a bug in such a case and make it block
> the 'broken-depgraph' tracker [2]. When assigning/CC-ing to the bug,
> please make sure to include both the maintainers of the broken package,
> and the maintainers of the dependency as necessary.

While I must admit that travis is a quite convenient tool (thought
it has its limitations), I'd like to raise related software freedom
concern.

Travis itself is a closed, proprietary and non-trivial-to-replace
solution. If travis will become essential for Gentoo development,
it may undermine development freedom and Gentoo social contract,
which states: "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 travis will change their terms of service in future and our
workflow/infra will depends on these checks, whole development
process may be hampered.

So developers should think twice before depending their workflow on
this solution. I'm refusing to sign up to the list which in my
opinion indirectly violates Gentoo social contract.

If some other free tool (preferably deployed on Gentoo
infrastructure) will be used for this task, I'll sign-up right away.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Gordon Pettey]

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

On Sat, Apr 11, 2015 at 5:47 PM, Andrew Savchenko <bircoph@gentoo.org>
wrote:

> While I must admit that travis is a quite convenient tool (thought
> it has its limitations), I'd like to raise related software freedom
> concern.
>
> Travis itself is a closed, proprietary and non-trivial-to-replace
> solution.
>

Looks pretty open to me... https://github.com/travis-ci/travis-ci
Replacement may be non-trivial purely due to the large number
of components involved, but closed and proprietary are a bit
extreme.

[-- Attachment #2: Type: text/html, Size: 923 bytes --]

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Jorge Manuel B. S. Vicetto]

On Sun, 12 Apr 2015, Andrew Savchenko wrote:

> On Thu, 9 Apr 2015 00:23:29 +0200 Michał Górny wrote:
>> Hello, developers.
>>
>> We have added a new mail alias travis-ci@g.o and set up travis-ci [1]
>> to send notifications on status change there. Please seriously consider
>> adding yourself to the alias, and contributing to the quality
>> of Gentoo.

<snip>

> While I must admit that travis is a quite convenient tool (thought
> it has its limitations), I'd like to raise related software freedom
> concern.
>
> Travis itself is a closed, proprietary and non-trivial-to-replace
> solution. If travis will become essential for Gentoo development,
> it may undermine development freedom and Gentoo social contract,
> which states: "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)."

I've seen no one suggest the use of travis is or will be mandatory.
What Michał has done is setup the environment to help identify tree 
breakage. I want to thank him for working on a tool to improve the quality 
of Gentoo.

> If travis will change their terms of service in future and our
> workflow/infra will depends on these checks, whole development
> process may be hampered.

Our infra has no dependency over travis. The only thing we've done infra 
side about this is to create the alias travis-ci and an ml[1] 
(gentoo-automated-testing) where we plan to send the output of several 
automated tools so that interested parties can check the status and "fix" 
any issues.

  [1] - https://archives.gentoo.org/gentoo-automated-testing/

> So developers should think twice before depending their workflow on
> this solution. I'm refusing to sign up to the list which in my
> opinion indirectly violates Gentoo social contract.

I fail to see how by adding yourself to the alias, joining the ml or 
checking the archives, you are breaking in any way the Social Contract - 
but every developer is free to choose whether to use this tool or not.

> If some other free tool (preferably deployed on Gentoo
> infrastructure) will be used for this task, I'll sign-up right away.

If you care about this topic, you should talk to the QA team and 
developers that have showed an interest in automated testing.
Just the other day Magnus sent an email to this ml about a project his 
working on.

> Best regards,
> Andrew Savchenko

Regards,
Jorge Manuel B. S. Vicetto

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Andrew Savchenko]

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

On Sun, 12 Apr 2015 03:03:18 +0000 (UTC) Jorge Manuel B. S. Vicetto
wrote:
> > If travis will change their terms of service in future and our
> > workflow/infra will depends on these checks, whole development
> > process may be hampered.
> 
> Our infra has no dependency over travis. The only thing we've done infra 
> side about this is to create the alias travis-ci and an ml[1] 
> (gentoo-automated-testing) where we plan to send the output of several 
> automated tools so that interested parties can check the status and "fix" 
> any issues.
> 
>   [1] - https://archives.gentoo.org/gentoo-automated-testing/
> 
> > So developers should think twice before depending their workflow on
> > this solution. I'm refusing to sign up to the list which in my
> > opinion indirectly violates Gentoo social contract.
> 
> I fail to see how by adding yourself to the alias, joining the ml or 
> checking the archives, you are breaking in any way the Social Contract - 
> but every developer is free to choose whether to use this tool or not.

Right now there is no hard dependency on github or travis, of
course. But present pathway worries me: with current pace at some
point we _will_ depend on travis or github too much. Then they may
change their terms of service or license argeement, or just shut
down the whole service (as Google recently shut down Google Code).
And then we will be in a great trouble. And then it may be too late
to change anything. I want to avoid this, that's all.

What we should really do is to develop our own QA tools or use
existing free ones on our own infrastructure, thus that Gentoo
development may continue to be independent and unbiased.

Please understand that I'm grateful for all people improving
Gentoo, including Michał, for their hard work. But we should not
solely rely on third-party proprietary solutions (travis is a
github lock-in) because of convenience.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Peter Stuge]

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

Andrew Savchenko wrote:
> we should not solely rely on third-party proprietary solutions
> (travis is a github lock-in) because of convenience.

We must not.


//Peter

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Andrew Savchenko]

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

On Sat, 11 Apr 2015 21:57:13 -0500 Gordon Pettey wrote:
> On Sat, Apr 11, 2015 at 5:47 PM, Andrew Savchenko <bircoph@gentoo.org>
> wrote:
> 
> > While I must admit that travis is a quite convenient tool (thought
> > it has its limitations), I'd like to raise related software freedom
> > concern.
> >
> > Travis itself is a closed, proprietary and non-trivial-to-replace
> > solution.
> >
> 
> Looks pretty open to me... https://github.com/travis-ci/travis-ci
> Replacement may be non-trivial purely due to the large number
> of components involved, but closed and proprietary are a bit
> extreme.

Problem is not in replacement only. Travis is a GitHub lock-in:
https://github.com/travis-ci/travis-ci README.markdown

Without GitHub Travis is useless, as it can't be used with any
other solution. And GitHub itself is closed.

Do you aware of any local Travis setup out there? There are none to
my knowledge.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[William Hubbs]

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

On Sun, Apr 12, 2015 at 05:54:36PM +0300, Andrew Savchenko wrote:
> Right now there is no hard dependency on github or travis, of
> course. But present pathway worries me: with current pace at some
> point we _will_ depend on travis or github too much. Then they may
> change their terms of service or license argeement, or just shut
> down the whole service (as Google recently shut down Google Code).
> And then we will be in a great trouble. And then it may be too late
> to change anything. I want to avoid this, that's all.
 
 It may take some work, but I do not think we could reach a point where
 nothing could be changed.

 Remember that, unlike cvs, every git clone, by default, has all of the
 history of the repository, so all we would have to do is find another
 place to host the repository and push it there.

> What we should really do is to develop our own QA tools or use
> existing free ones on our own infrastructure, thus that Gentoo
> development may continue to be independent and unbiased.
 
 This is more likely once the main Gentoo ebuild repository is migrated
 to git.

> Please understand that I'm grateful for all people improving
> Gentoo, including Michał, for their hard work. But we should not
> solely rely on third-party proprietary solutions (travis is a
> github lock-in) because of convenience.
 
 wrt travis-ci, why not contribute code to it so that isn't a github
 lock-in? Have you checked to see if the authors are opposed to that
 kind of contribution?

 I think all of these extra solutions are coming up because folks are
 frustrated with the current status of our main portage tree not being
 under git.

> Best regards,
> Andrew Savchenko

William


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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Peter Stuge]

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

William Hubbs wrote:
> It may take some work, but I do not think we could reach a point
> where nothing could be changed.
> 
> Remember that, unlike cvs, every git clone, by default, has all of the
> history of the repository, so all we would have to do is find another
> place to host the repository and push it there.

I think that's too simplistic. Proprietary systems are a slippery
slope. And the problem with GitHub Inc. in particular isn't their
technology at all, but their processes and the mindset they promote,
because the processes and mindset are locked to their platform.

It sounds silly but it *is* a problem.


//Peter

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Michał Górny]

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

Dnia 2015-04-12, o godz. 01:47:43
Andrew Savchenko <bircoph@gentoo.org> napisał(a):

> On Thu, 9 Apr 2015 00:23:29 +0200 Michał Górny wrote:
> > Hello, developers.
> > 
> > We have added a new mail alias travis-ci@g.o and set up travis-ci [1]
> > to send notifications on status change there. Please seriously consider
> > adding yourself to the alias, and contributing to the quality
> > of Gentoo.
> > 
> > The mail load is low -- travis will only send notices when the state
> > changes from 'good' to 'bad', and the other way around. However, you
> > will need to manually grep the logs provided by travis for occurences
> > of 'FATAL'.
> > 
> > Please remember that keeping the repository in a broken state is
> > inconvenient both for users and other developers. In particular
> > the issues include:
> > 
> > 1. dependency resolution errors blocking @world upgrades,
> > 
> > 2. Portage unnecessarily switching packages to ~arch (and therefore
> >    reducing quality of stable systems),
> > 
> > 3. repoman refusing to commit irrelevant changes to packages.
> > 
> > Therefore, whenever possible please try to fix the issues ASAP.
> > 
> > However, if you are not the person directly responsible for
> > the dependency graph breakage, please *reliably* inform him
> > about the revert/change you're doing. Failing to do has already
> > resulted in developers repeating their mistakes because of
> > misinformation.
> > 
> > Preferably, always file a bug in such a case and make it block
> > the 'broken-depgraph' tracker [2]. When assigning/CC-ing to the bug,
> > please make sure to include both the maintainers of the broken package,
> > and the maintainers of the dependency as necessary.
> 
> While I must admit that travis is a quite convenient tool (thought
> it has its limitations), I'd like to raise related software freedom
> concern.
> 
> Travis itself is a closed, proprietary and non-trivial-to-replace
> solution. [...]

Wrong. Actually, it's trivial. Even better, deploying pcheck
on Gentoo-hosted service is likely easier than on Ubuntu container used
by travis (though it was quite a nice pkgcore learning experience).

The only reason I used travis-ci is because they are giving their
hardware for free. If someone gave me hardware on sane terms, I can
move it elsewhere. Though right now I see no point in wasting Gentoo
money on dedicated hardware when the tasks can be offloaded to
travis-ci.

> If travis will change their terms of service in future and our
> workflow/infra will depends on these checks, whole development
> process may be hampered.
> 
> So developers should think twice before depending their workflow on
> this solution. I'm refusing to sign up to the list which in my
> opinion indirectly violates Gentoo social contract.
> 
> If some other free tool (preferably deployed on Gentoo
> infrastructure) will be used for this task, I'll sign-up right away.

You can run repoman/pcheck on your hardware too, you know. You don't
have to have a dedicated remote service to do that.

That said, I have bigger plans™ if someone gives me some hardware to
handle them. Let's call it 'big Gentoo repository mirror'. The idea is
that a script would process repositories.xml, maintain checkouts of all
repositories (fetch, sync, remove as necessary), generate md5-cache
and provide the resulting repo for syncing via git & rsync. It wouldn't
hurt to run travis on all repos there as well.

In other words, something like our git mirror, though on dedicated
hardware and for all repositories :).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[William Hubbs]

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

On Sun, Apr 12, 2015 at 06:49:24PM +0200, Peter Stuge wrote:
> William Hubbs wrote:
> > It may take some work, but I do not think we could reach a point
> > where nothing could be changed.
> > 
> > Remember that, unlike cvs, every git clone, by default, has all of the
> > history of the repository, so all we would have to do is find another
> > place to host the repository and push it there.
> 
> I think that's too simplistic. Proprietary systems are a slippery
> slope. And the problem with GitHub Inc. in particular isn't their
> technology at all, but their processes and the mindset they promote,
> because the processes and mindset are locked to their platform.

The only thing locked to their platform really is the web ui or their
api. Even pull requests really aren't, because git has the
"git request-pull" command.

William


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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Erik Mackdanz]

William Hubbs <williamh@gentoo.org> writes:

> The only thing locked to their platform really is the web ui or their
> api. Even pull requests really aren't, because git has the
> "git request-pull" command.

Not true.  Github pull requests are for pulling from other Github
repos/branches only, and they store unique metadata (e.g. comments,
issues) outside of the repo.  It is truly a lock-in feature.

"git request-pull" simply formats an email template to tell someone how
they may pull from you, but Github makes no attempt to process such a
message or turn it into a Github pull request.

Any Github presence of the tree will result in Github issues being
submitted and Github pull requests coming across.  We'd have to be
prepared to chain that into our existing processes or have someone
dedicated to closing every issue/pull request with "Use bugzie".

-- 
Erik Mackdanz

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Gordon Pettey]

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

On Mon, Apr 13, 2015 at 7:59 AM, Erik Mackdanz <erikmack@gmail.com> wrote:

> William Hubbs <williamh@gentoo.org> writes:

"git request-pull" simply formats an email template to tell someone how
>
they may pull from you, but Github makes no attempt to process such a
> message or turn it into a Github pull request.
>

A pull is a pull is a pull. Please don't conflate Git and GitHub.


> Any Github presence of the tree will result in Github issues being
> submitted and Github pull requests coming across.  We'd have to be
> prepared to chain that into our existing processes or have someone
> dedicated to closing every issue/pull request with "Use bugzie".


Then turn off the issue tracker. Joe Random can't submit GitHub
issues if the repository admin hasn't enabled them.

[-- Attachment #2: Type: text/html, Size: 1596 bytes --]

[gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Robin H. Johnson]

Bircoph:
mgorny has worked with infra to get something that is suitable.
_ANY_ CI is an improvement over no CI.

Our constraints are:
- Should interoperate via a NON-GitHub-specific Webhook trigger
  - Yes, per my prior email to lists, we can send a notification to
	anything that can take incoming webhooks.
- Should NOT pollute the repository with service-specific files.
  - No .travis.yaml file
  - No wercker/ directory
  - No circle.yml file
- Should either be entirely self-contained, or use external resources.
  - Infra doesn't have the resources (manpower or hardware) to
	individually manage every single CI testsuite environment, and QA
	has a MUCH better idea of what they want to test.
  - Travis-CI etc are GOOD for this case, because it allows us to focus
	limited manpower on the content of the testcases, rather than the
	environment to run them in.
  - If you could give infra a Docker container that say runs a webserver,
	and accepts a WebHook call at http://.../webhook then does USEFUL 
    work and emails or does a HTTP POST of the result; and YOU are 
    willing to maintain the container definition, then we'll find 
    somewhere good to run it (should not be dependant on IPv4 
	connectivity, you might get a v6-only environment).
	Look at what Wercker is doing to speed up CI using containers, it shows a
    lot of promise as a concept.

> If travis will become essential for Gentoo development, it may
> undermine development freedom and Gentoo social contract, which
> states: "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)."
This argument has come up before, claiming that something one team is
doing isn't in line with the social contract. mgorny himself complained
about infra's repos being non-public.

Let's expand that section somewhat, from the original text:
"We will release our contributions to Gentoo as free software, metadata or
documentation, under the GNU General Public License version 2 or the Creative
Commons - Attribution / Share Alike version 2. ... 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."

I'm going to use the word 'libre' below, to differentiate between a
'free-as-in-freedom' license, and the 'free-as-in-beer' offering from
commerical CI providers.

Infra's repo contents are licensed libre: most scripts I've written in the
infra repos carry a BSD license, in many cases because I wrote them for dayjob
purposes first, and later modified them for Gentoo.

We can expand this, by stating that the repos we want to test with CI must
remain libre.

It says NOTHING about the CI tools themselves. Why should we not be able to
benefit from really good closed-source CI tools that are offered for free to
the open-source community? As long as we can continue to function WITHOUT those
tools, there is no direct harm [1] done in using them. They cannot force us to
change the licenses of our repos at all. 

> Travis itself is a closed, proprietary and non-trivial-to-replace
> solution. 
If our CI testsuite contents are libre licensed (QA is running pcheck, which
is again suitably licensed), and Travis-CI or whichever CI service suddenly
because Evil(TM), there is nothing stopping us from running our testsuite
elsewhere. All that remains is hooking the testsuite into the CI service.

[1] I state direct harm here. You're going to argument that it affects the
ecosystem, by discouraging other services. Jenkins, Buildbot and others are
existing libre options in this ecosystem, but aren't keeping pace with
development.


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

Re: [gentoo-dev] Please subscribe to travis-ci mail alias to get notifications on depgraph breakages

[Michał Górny]

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

Dnia 2015-04-13, o godz. 17:28:23
Gordon Pettey <petteyg359@gmail.com> napisał(a):

> On Mon, Apr 13, 2015 at 7:59 AM, Erik Mackdanz <erikmack@gmail.com> wrote:
> 
> > William Hubbs <williamh@gentoo.org> writes:
> 
> "git request-pull" simply formats an email template to tell someone how
> >
> they may pull from you, but Github makes no attempt to process such a
> > message or turn it into a Github pull request.
> >
> 
> A pull is a pull is a pull. Please don't conflate Git and GitHub.
> 
> 
> > Any Github presence of the tree will result in Github issues being
> > submitted and Github pull requests coming across.  We'd have to be
> > prepared to chain that into our existing processes or have someone
> > dedicated to closing every issue/pull request with "Use bugzie".
> 
> 
> Then turn off the issue tracker. Joe Random can't submit GitHub
> issues if the repository admin hasn't enabled them.

How about we turn off this mailing list? It certainly wastes more of my
time than the github pull requests, and unlike them doesn't benefit
Gentoo as can be seen by this post.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Andrew Savchenko]

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

Hello,

On Tue, 14 Apr 2015 01:13:02 +0000 Robin H. Johnson wrote:
> Bircoph:
> mgorny has worked with infra to get something that is suitable.
> _ANY_ CI is an improvement over no CI.

Yes and no, this depends on implications of such improvement.
 
> > If travis will become essential for Gentoo development, it may
> > undermine development freedom and Gentoo social contract, which
> > states: "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)."
> This argument has come up before, claiming that something one team is
> doing isn't in line with the social contract. mgorny himself complained
> about infra's repos being non-public.
> 
> Let's expand that section somewhat, from the original text:
> "We will release our contributions to Gentoo as free software, metadata or
> documentation, under the GNU General Public License version 2 or the Creative
> Commons - Attribution / Share Alike version 2. ... 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."
> 
> I'm going to use the word 'libre' below, to differentiate between a
> 'free-as-in-freedom' license, and the 'free-as-in-beer' offering from
> commerical CI providers.
> 
> Infra's repo contents are licensed libre: most scripts I've written in the
> infra repos carry a BSD license, in many cases because I wrote them for dayjob
> purposes first, and later modified them for Gentoo.
> 
> We can expand this, by stating that the repos we want to test with CI must
> remain libre.
> 
> It says NOTHING about the CI tools themselves. Why should we not be able to
> benefit from really good closed-source CI tools that are offered for free to
> the open-source community? As long as we can continue to function WITHOUT those
> tools, there is no direct harm [1] done in using them. They cannot force us to
> change the licenses of our repos at all. 

My primary concern lies in another plane: with time we'll depend on
github, its features and companion projects more and more. Each
dependency will likely be replaceable, but with some effort. The
more features or tools we use, the harder it will be to replace all
of them, especially at once. At some moment we will not be able to
switch to another solution in practical terms without serious
damage to our workflow, particularly if immediate change will be
required. What if github will just cease to exist one day?

Right now we use and depend (in terms of convenience) upon at least
following github features ():

1. pull requests;
2. travis ci;
3. many official overlays use github widely: repositories, issue
trackers, pull requests and more.

I bet this list will expand in future with more features.

Argument about saving Gentoo Foundation financial resources by
using hardware for CI for free is heard and taken. This is a
serious one and I can't argue here. But frankly it looks like to me
that we are just selling our freedom, slowly, bit by bit.

Best regards,
Andrew Savchenko

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

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Rich Freeman]

On Wed, Apr 15, 2015 at 5:56 AM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> Argument about saving Gentoo Foundation financial resources by
> using hardware for CI for free is heard and taken. This is a
> serious one and I can't argue here. But frankly it looks like to me
> that we are just selling our freedom, slowly, bit by bit.
>

Well, then buy it back!  I'm sure everybody would prefer to use
something which is FOSS.  Somebody just has to build it.

The only thing the Council/Trustees/etc can do is say "no, you're not
allowed to build that."  The Trustees do have some money, but not
really all that much if you want to hire somebody to build something.
So, we have to rely on somebody stepping up and doing the work.

For us to actually say "no, I'd prefer that you did nothing at all
rather than working on what you're working on right now" is a pretty
big step to take.  We'll take it over something serious, but you can
imagine that we're going to be reluctant to take it over where an
overlay gets hosted, or over an optional CI layer, and so on.

I fully accept that this isn't entirely without risk.

-- 
Rich

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Peter Stuge]

Robin H. Johnson wrote:
> Why should we not be able to benefit from really good closed-source
> CI tools that are offered for free to the open-source community?

Because it may not be in line with Gentoo politics.


> Jenkins, Buildbot and others are existing libre options in this
> ecosystem, but aren't keeping pace with development.

Politics that somehow matter usually require compromise.


The (rhetorical) question is, what is most important?


//Peter

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Rich Freeman]

On Wed, Apr 15, 2015 at 7:59 AM, Peter Stuge <peter@stuge.se> wrote:
> Robin H. Johnson wrote:
>> Why should we not be able to benefit from really good closed-source
>> CI tools that are offered for free to the open-source community?
>
> Because it may not be in line with Gentoo politics.
>
>
>> Jenkins, Buildbot and others are existing libre options in this
>> ecosystem, but aren't keeping pace with development.
>
> Politics that somehow matter usually require compromise.
>
> The (rhetorical) question is, what is most important?

Well, right now the alternative to what is set up right now is not
using anything at all, until somebody sets something else up.

The only choices we actually have in front of us are status quo, or
less-than-libre tools.  The status quo is becoming painful enough that
people are fairly desperate to get away from it.

The status quo isn't entirely libre either.  Half of our QA depends on
people running random scripts on their own private systems, which may
or may not be entirely open-source, and if they go away we certainly
don't have the ability to readily reproduce them centrally.  Given the
choice of travis-ci or a bunch of scripts running on somebody's random
tinderbox, the former is probably less likely to just disappear.  I
don't mean to criticize devs for running random tools and scripts on
their own boxes either, because without them we'd be even worse off.

If people want pure-FOSS tools, they need to make it happen.  If we
had a choice between an 85% solution that was proprietary and a 75%
solution that was FOSS, there is a good choice we'd line up behind the
latter.  The problem is that what we have is a choice between the
proprietary 85% solution that somebody has implemented, and a
theoretical FOSS alternative that nobody wants to do anything but talk
about.

So, I'm pretty hesitant to go in and say "stop!"

-- 
Rich

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Peter Stuge]

Rich Freeman wrote:
> >> Jenkins, Buildbot and others are existing libre options in this
> >> ecosystem, but aren't keeping pace with development.
> >
> > Politics that somehow matter usually require compromise.
> >
> > The (rhetorical) question is, what is most important?
..
> The only choices we actually have in front of us are status quo, or
> less-than-libre tools.

Right, that's where compromise starts.


> The status quo is becoming painful enough that people are fairly
> desperate to get away from it.

Yeah, desperate for perceived progress possibly at the cost of
possibly going against project politics. Liberty and security bla
bla, it's all old news, and "people" will always do what they have
always done. That's why I consider my question a rhetorical one.


> The status quo isn't entirely libre either.

Certainly true, but I don't think that's intentional, as with
corporations.


> If people want pure-FOSS tools, they need to make it happen.

Selfless work lives on moral support among a few other things.


//Peter

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Francesco Riosa]

Il 16/04/2015 12:41, Peter Stuge ha scritto:
> Rich Freeman wrote:
>> If people want pure-FOSS tools, they need to make it happen.
> Selfless work lives on moral support among a few other things.
>
listen:
Git is the child of bitkeeper closing it's freeware program
it gave the kernel community a good start point to clone and improve
upon. Before it was CVS.

Actually an `emerge -uDN @world` fail constantly, because of broken deps
and other stuff (given a desktop profile with a good number of packages)
this fact render gentoo very unpleasant to keep up to date, it has never
been a breeze but it was better.

combining these two things  I really could not care less, and nobody
should care less for the usage of proprietary tools to improve things,
knowing that thing can fail and could need a replacement.
In the meantime Gentoo can improve itself in other areas, manpower don't
seem too high at the moment.

also you can strive for HURD and not linux, but don't impose it on us
(at least not for now)

- Francesco R.

[gentoo-dev] Re: CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Duncan]

Francesco Riosa posted on Thu, 16 Apr 2015 14:32:56 +0200 as excerpted:

> Actually an `emerge -uDN @world` fail constantly, because of broken deps
> and other stuff (given a desktop profile with a good number of packages)
> this fact render gentoo very unpleasant to keep up to date, it has never
> been a breeze but it was better.

As a gentoo user for over a decade that takes his job as an admin (if you 
are responsible for a machine including updates and decisions what it 
will run, you're an admin, for better or worse) seriously...

I don't see emerges being much more difficult now that before.  Rather 
the reverse, as they offer more information about what's going wrong, 
now, and for someone serious about admining gentoo boxen, about how to 
fix the problems, since they stay informed on how their tools work, just 
as a skilled carpenter knows well how /his/ tools work.

Of course, that's why I subscribe here, too, because as an admin serious 
about the job, I appreciate the value of the heads-up I get from this 
list on most big changes.

OTOH, I run ~arch and always have, so what deps look like on sta(b)le I 
couldn't say.  To a large extent, gentoo depends on the people running 
stable to care about it and report problems (with the same applying to 
~arch, of course).  Tools only go so far... it still takes someone 
skilled in using them to produce anything of value.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] CI services for Gentoo & Social Contract meanings of "dependant" notifications on depgraph breakages

[Alexander Berntsen]

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

On 15/04/15 11:56, Andrew Savchenko wrote:
> frankly it looks like to me that we are just selling our freedom, 
> slowly, bit by bit.
Sadly, I think most Gentoo devs are way past the point of caring.

But, for what it's worth, I agree with you completely.
- -- 
Alexander
bernalex@gentoo.org
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlUw4AsACgkQRtClrXBQc7VL5AD/QufBCKH5f0nLpziZqlJy6pKY
W4sF97+kPojZ4JYqDhgA/2Eya8HtDExc2Yjr/56IYmZe9BZ0cr3As0VNQ2KPC2Jm
=C2HQ
-----END PGP SIGNATURE-----