Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages
-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 berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlUw4AsACgkQRtClrXBQc7VL5AD/QufBCKH5f0nLpziZqlJy6pKY W4sF97+kPojZ4JYqDhgA/2Eya8HtDExc2Yjr/56IYmZe9BZ0cr3As0VNQ2KPC2Jm =C2HQ -END PGP SIGNATURE-
Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages
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.
Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages
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
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
On Wed, Apr 15, 2015 at 7:59 AM, Peter Stuge pe...@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
Hello, On Tue, 14 Apr 2015 01:13:02 + 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 pgpvC4Ajpr1Et.pgp Description: PGP signature
Re: [gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages
On Wed, Apr 15, 2015 at 5:56 AM, Andrew Savchenko birc...@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
[gentoo-dev] CI services for Gentoo Social Contract meanings of dependant notifications on depgraph breakages
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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
