LWN: Comments on "Alioth moving toward pagure"

Alioth moving toward pagure

JanC_ — Fri, 03 Nov 2017 22:03:57 +0000

Their experience with "enterprise" Java software is exactly why most sysadmins hate Java.

Alioth moving toward pagure

nschloe — Sun, 01 Oct 2017 12:47:21 +0000

Apparently, things have changed and Alioth will be migrated to GitLab after all [1].

[1] https://wiki.debian.org/Alioth#Deprecation_of_Alioth

Alioth moving toward pagure

anarcat — Thu, 10 Aug 2017 22:12:02 +0000

another update here: looks like gitlab is still a serious contender. it sure looks like this will be decided at the sprint directly: http://lists.alioth.debian.org/pipermail/alioth-staff-rep...

Alioth moving toward pagure

mbunkus — Thu, 03 Aug 2017 05:45:11 +0000

Can you be a bit more specific,please, so that those of us running Buildbot can take appropriate countermeasures? Thanks.

Alioth moving toward pagure

mathstuf — Thu, 03 Aug 2017 03:18:43 +0000

The web interface? You don't have to expose that if it's sending status updates to your repository. Or hacked through some other means?

Alioth moving toward pagure

rurban — Wed, 02 Aug 2017 19:20:42 +0000

-1. I used buildbot for a couple of years, until it got hacked. twisted is insecure.

Alioth moving toward pagure

yoe — Sun, 25 Jun 2017 19:38:47 +0000

Oh yeah, that's definitely possible. Buildbot allows you to run whatever you want through the shell build step. Something like 'build, run tests, if tests are successful then commit something in puppet repository so that hosts are auto-updated to install this version from the git commit id' seems very achievable, easy even. And you could limit that do that it would only try to do that for tagged commits or commits on a particular branch, for instance.

Alioth moving toward pagure

paulj — Sun, 25 Jun 2017 13:07:12 +0000

+1 on buildbot. It's relatively light-weight and easy to install. The python configuration makes it very easy to customise (and I'm not a big fan of python either). It has a clean and logical design. The documentation is pretty good. It can spin up VMs on demand.

It's a great bit of software.

Indeed, I could see it being very useful for wider system-orchestration tasks, beyond just CI.

Has Allura been explored?

michaelr — Fri, 23 Jun 2017 17:35:28 +0000

... and I forgot to check for another thread: https://lwn.net/Comments/725464/

Has Allura been explored?

michaelr — Fri, 23 Jun 2017 17:32:48 +0000

I wonder if the debian folks have considered Apache Allura (http://allura.apache.org ) as the new alioth software. It's an open-source copy of the current SourceForge software, which was rewritten in Python some time after the FusionForge fork.

AFAICT SourceForge has not moved to close their Python sources, and so Allura _is_ the SF platform and has been for about 8 years now.

I don't know whether the migration path from FusionForge to Allura would be easier than to another forge platform, but I imagine that it might be given that both originate from SF code.

It doesn't seem that there has been much if any discussion of Allura in the Debian email lists:
https://lists.debian.org/cgi-bin/search?P=allura&DEFA...

But it would be worth a look.

Alioth moving toward pagure

catalinuxboie — Fri, 23 Jun 2017 17:31:26 +0000

Hello!

(full disclosure: I am the main author of RocketGit)

Another alternative is RocketGit (https://rocketgit.com).
It is very light, the code is very easy to understand (PHP, no classes), it is fast, has very powerful rights system and offers a way to easy contribute to a hosted project (anonymous push).
It has continuous integration and deployment features (for now only KVM based), but docker is in progress.

Also, it is the only AGPL (Affero GPL) project (= nobody can steal your contributions to RocketGit to make them proprietary).

It is available online, as a virtual image (200MiB) or as a docker container.

Here is my (incomplete) comparison between RocketGit, GitLab CE, GitHut, Gitolite, Pagure and Gogs:
https://rocketgit.com/op/doc/compare

Thanks!

Alioth moving toward pagure

nim-nim — Wed, 21 Jun 2017 10:03:21 +0000

Si what? As long as they keep adding features modern software project expect. Is gforge such a bad core it's better to dump it for a new barebones one such as pagure ?

Alioth moving toward pagure

yoe — Mon, 19 Jun 2017 21:40:11 +0000

You should look at buildbot. Its master config file is a python script which gets executed, and which builds a set of objects in memory that describe the configuration. This allows for an awesome flexibility; yet at the same time, buildbot ships with a wide swath of classes to help you build that configuration that it's pretty easy to deceive yourself you're not writing python, and that this is just a declarative configuration file (which is a good thing, in case that wasn't clear). The documentation is pretty awesome, too.

Python is much more lightweight than Java is, and it's actually portable to pretty much everywhere.

I use buildbot to automatically build a particular piece of software for Windows, OSX, and various distributions through a number of libvirtd VMs on a single machine (apart from the OSX builds), and release them with version numers based on tags (but granted, my master.cfg is rather complex). I've gone on record saying that I'm not a fan of python, and I in fact have often switched away from particular pieces of software because they were written in that language. I'm very glad I haven't done that with buildbot...

Alioth moving toward pagure

mirabilos — Mon, 19 Jun 2017 14:58:30 +0000

Tuleap is just another GForge derivative.

Disclaimer: I was a developer of FusionForge for a while.

Alioth moving toward pagure

mirabilos — Mon, 19 Jun 2017 14:51:21 +0000

☹

I’m surprised though that formorer says he’s the last admin, I would have thought the FusionForge crowd to be more involved in it.

Alioth moving toward pagure

zanchey — Mon, 19 Jun 2017 08:36:45 +0000

I'm looking at options for build & deploy systems, and every comment on Jenkins seems to be along these lines - that easy bit is really easy, and the hard bit is mind-boggling hard and inflexible. I'm just not sure that there's better options...

Alioth moving toward pagure

anarcat — Sun, 18 Jun 2017 19:18:22 +0000

It seems that the Debian community may be backtracking a little on the pagure choice. Or at least Wirt has decided to hear more from the community to design a replacement: there's now an online survey to get more details from Alioth users.

Alioth moving toward pagure

nim-nim — Sun, 18 Jun 2017 13:19:21 +0000

Given this I doubt it will disappear soon
https://www.eclipsecon.org/france2017/session/new-era-alm...

Airbus has deep pockets.

The whole business model of the company developing it is to allow corps to sponsor features they need, while staying 100% free software (big corps are starting to understand what open core means and they do not like it at all).

Alioth moving toward pagure

ras — Sun, 18 Jun 2017 09:33:42 +0000

As a user of SourceForge I insisted absolutely nothing wrong with it. It has three notable features:

1. It's landing pages are designed for the user of the package, as opposed to the developer. So links to a versioned(!) download area, documentation, bugs and mailing lists are prominent. The button to fork the project is harder to find.

2. It is VCS agnostic - it supports all the common ones.

3. It can be completely scripted, by which I mean after doing the development of the next version on my laptop or whatever, a "make upload" is all that is required to update the release area, home page, and VCS on sourceforge. In fact if it weren't for responding to bug reports there would be no need for me to visit SourceForge at all after creating the project.

This apparently isn't to most people tastes. It appears that developers prefer their hosting sites to function primarily communicating channel for developers. But for me it's bliss.

This state of affairs lasted until I became so enamored with it, I decided I'd try and package it for Debian. The installation instructions of "here is a VM we've created for you" weren't encouraging, and it turned out they were like that for a reason. The Allura devs mode of operation seems to be to pull in other projects as needed, hack them into something they can use, then not contribute any of their changes upstream.

In other words, unsupportable by anyone else.

That said, it's currently a good fit for the current Aloith. It also runs on software that has never been packages for Debian, and judging by the years of unfixed bug reports and requests for help [0], is unusable by anybody who doesn't have admin rights to the machine so they can fix it when it breaks.

Maybe pagure will mark the start of a new era. Here's hoping.

[0] https://alioth.debian.org/tracker/?atid=200001&group_...

Alioth moving toward pagure

anarcat — Sat, 17 Jun 2017 15:01:30 +0000

I'd be glad to read up more on the arguments against Gitblit. What I have seen in my review of the numerous mailing list posts is merely the mention of Gitblit as an alternative, and no explicit rebuttal. The quote here is from an IRC discussion where I explicitly asked Wirt why Gitblit was rejected, and this was literally his response. Notice how, in the article, I do not take a stance regarding the validity of that statement.

With the new Stretch release out the door, it is, however, interesting to note the various programming language stats: Java is the fourth most popular language after C, C++ and... XML! (Next up are Python, SH and Perl.) I myself, do not dislike Java as a language so much, but I have found it difficult to manage Java applications quite often as a sysadmin, as the frameworks can be quite heavy on resources, so I believe I understand where Wirt is coming from.

Everything, of course, should be written in my $current_language_of_choice. ;)

Alioth moving toward pagure

k8to — Fri, 16 Jun 2017 21:12:33 +0000

Jenkinsfiles are horrifyingly awful.

The declarative version of them is extremely under-documented and you can easily find yourself in a situation where you can no longer do what you need using the declarative version of them. Also if you make any sort of syntactical error you get a completely incomprehensible java stack trace where you have to guess what you did wrong.

The imperative version is only fairly under-documented, and while you can almost certainly do what you need, you have to do it using the magic subset of Groovy that happens to work. There's so many undocumented assumptions in how they assume you'll wire your code together, that you spend your time wondering what the next stack trace means for days on end until you get something that works.

Jenkins also is awful independent of jenkinsfiles. In order to get the functionality you want, you'll have to install a number of plugins, and different projects will need different plugins, and they all mutate global logic, breaking each other and Jenkins overall. Unless you want to go through the process of providing a jenkins service per project, you'll be dealing with either the pain of an unreliable service, or the pain of a very hamstrung and degenerate service that doesn't do what the projects need.

If you choose to go down this road anyway because it's "the default", then good luck for you and I hope you don't experience what I deal with every day.

Alioth moving toward pagure

bavay — Fri, 16 Jun 2017 13:46:41 +0000

Actually, as a current Indefero admin, I am looking at moving to another system at some point... Does anybody has some feedback on Tuleap? It seems very nice, but I obviously do not want to migrate to another forge that would end up unmaintained...

Alioth moving toward pagure

guillemj — Fri, 16 Jun 2017 11:54:26 +0000

There are already at least two such services in Debian that I'm aware of (but there might be more, in Debian with this things you never know :):

<https://ci.debian.net/>
<https://jenkins.debian.net/>

Well, there's also <http://travis.debian.net/>, which is strictly speaking not a service on its own, and will (I'd assume) never be made official.

Alioth moving toward pagure

meyert — Fri, 16 Jun 2017 10:53:52 +0000

Yeah, "is Java" is not a technical reason to not use the software but an opinion. The JVM is very powerful and much more advanced than the Python world. Much more battle tested in heavy load enterprise world. But in some circles a Java bashing became trendy, but as often those people have little knowledge about the topic.

Alioth moving toward pagure

nhippi — Fri, 16 Jun 2017 07:01:26 +0000

Pagure supports webhooks, so I think it's matter of just implementing? furthermore, Since Debian pagure is debian-specific, the CI could be 0-configuration - build package, run unit tests, run autopkgtests.

Alioth moving toward pagure

ssmith32 — Fri, 16 Jun 2017 04:23:26 +0000

"Jenkins is Java" ... And I guess that's a good enough reason to dismiss it out of hand??

Alioth moving toward pagure

dgm — Thu, 15 Jun 2017 13:27:37 +0000

Also, what about Apache Allura? It seems to be the natural path for *Forges.

What's wrong with it?

Alioth moving toward pagure

jond — Thu, 15 Jun 2017 09:29:53 +0000

Re "Gitblit is Java"; I can't remember (but I hope) the actual discussion (and dismissal) was a bit more nuanced. I think Java is more maligned than necessary some of the time, and there's a *lot* of F/OSS Java code out there. It's perhaps more maligned in Debian than other Linux sub-cultures, certainly I'm seeing much more of it at Red Hat than I was used to in the Debian community.

Alioth moving toward pagure

nim-nim — Thu, 15 Jun 2017 07:35:28 +0000

I wonder if someone considered TuleAp.

It's free software (GPL) and quite modern. More advanced than GitLab on some aspects.

https://www.tuleap.org/
https://www.tuleap.org/tuleap-versus-gitlab-battle-will-n...

They seem to have some happy big enterprise users (AirBus, Orange…)

Alioth moving toward pagure

lamby — Thu, 15 Jun 2017 01:51:30 +0000

With my Debian Project Leader hat on here, anyone wishing to attend the sprint mentioned in the article may apply for travel reimbursement. :)

Alioth moving toward pagure

guillemj — Wed, 14 Jun 2017 23:23:23 +0000

Actually the main mailing list service is based on smartlist + procmail + a ton of anti-spam measures + mhonarc.

Alioth moving toward pagure

jberkus — Wed, 14 Jun 2017 22:30:12 +0000

Speaking as a Fedora contributor, I am thrilled that Debian will also be using Pagure. With both projects on it, we will be able to make Pagure more mature and better-supported. Yay!

Alioth moving toward pagure

pj — Wed, 14 Jun 2017 22:11:24 +0000

I keep waiting for one of the decent open source forges to support 1) OAuth as both client and provider and 2) federation, so I could run my own node of it that would host my own projects (and forks of other people's projects, of course) and be certain that they (and all their associated issues, comments, etc) will be around independent of any other company or entity.

Alioth moving toward pagure

kfox1111 — Wed, 14 Jun 2017 20:48:08 +0000

Supposedly Jenkins supports the same kind of pipeline file now with the newest versions.

Alioth moving toward pagure

paulj — Wed, 14 Jun 2017 19:30:58 +0000

Good to see a more minimal (in terms of dependencies), easily packaged, easily self-hosted and free Git-forge getting a level of adoption that will guarantee its future.

Alioth moving toward pagure

drag — Wed, 14 Jun 2017 18:12:52 +0000

Getting CI features is a big big win. Since they are not going with GitLab it would be well worth their time to look into making a CI service that will compliment pagure.

Right now it looks like Pagure wants to work with Jenkins for CI, which is probably fine. Jenkins is widely known and used. But I really like the simple 'pipeline' style development were you have a yaml file or json file that you throw into the root directory of your git repository that describes the steps to perform when you want to test build/updates.