Distributions

Pagure and Fedora

There are a fair number of options for project hosting these days, from the largely moribund SourceForge to the ever-popular GitHub, but many of these sites either do not release their software or are largely company-run projects, without much in the way of an external development community. A relatively new entrant in the "forge" scene (where "forge" hearkens back to SourceForge, which was one of the earliest) is pagure. It is gaining a bit of traction as the Fedora project has started using it for some of its projects. One of its headline features, that distinguishes it from some other project-hosting tools, is that the discussion metadata for bugs and pull requests is also available, which allows projects to easily move or to keep multiple pagure instances in sync.

Python and Git

Pagure is written in Python and uses Git for its repositories. It includes the usual set of features that projects have come to expect from this type of package, like issue tracking, repository forking, pull requests, and so on. Its genesis is in the Fedora infrastructure project and it was originally called "progit" by its creator Pierre-Yves Chibon.

As would be expected, the project itself is hosted within pagure, which easily allows those interested to browse its documentation and issues (bugs and feature requests). On the main page for a repository, there are the expected URLs for the source code Git repository and (a bit hidden behind a "more" link on the project page) a Git repository for the documentation. While the issues and pull-request information is also stored in Git repositories, URLs for those are not apparent (or at least obvious) in the web interface. There is also scant mention of those repositories in the documentation, which is a little bit sparse at this point.

One of the big complaints about GitHub is that much of the metadata that a project accumulates is not easily retrieved should the project want to move elsewhere. Making that easier, while also allowing other use cases such as synchronization between multiple project sites, is one of the more interesting features of pagure.

Installation and workflow

Installation from source into a Python virtual environment is fairly straightforward as described on the main project page. Installing on Fedora or RHEL/CentOS can be done using RPMs or, for other distributions, setup.py can be used. There are some fairly lengthy instructions on configuring the web server, setting up repository directories, and creating the database once pagure itself has been installed.

By default, pagure uses SQLite, but that is not sufficient for running a production instance, so either PostgreSQL, MySQL, or MariaDB need to be available for those types of systems. For managing updates to the database tables, the Alembic "lightweight database migration tool" is used. It works with the SQLAlchemy database toolkit for Python to allow the database schema to evolve relatively painlessly as pagure adds new features.

The workflow in pagure is fairly easy to pick up as it should be familiar to those who have used GitHub or similar sites. Repositories are forked and modified, then submitted back to the project as pull requests. In addition, pull requests can be created from forks that are hosted elsewhere and changes pushed into a branch that a pull request was created from will automatically update the request with the new changes.

Architecture

The architecture of the tool is based on a number of cooperating processes. The main application is a Flask-based web application that provides a user interface to the Git repositories, issues, and pull requests. Gitolite is used to control SSH access to the repositories. The documentation server is a separate web application that can (and probably should) be hosted on its own system:

Beyond that, there is a "milter" (mail filter) that allows people receiving comments on issues or pull requests to reply directly in email and have their message be added—alleviating the need to call up the web page before replying. There is an "EventSource" server that handles live refreshing of web page contents (such as comments on an issue being viewed). The "web-hook" server handles third-party notifications, such as to Fedora infrastructure's fedmsg message bus.

Releases for pagure are coming at a fairly quick pace. The project appears to be a little more than a year old and, unlike many projects that languish with 0.x releases for years, is up to version 2.1.1. The 1.0 release was made back in January; Fedora Magazine reviewed at that time, noting that the name comes from the French word for "hermit crab". In his post announcing that the project was being renamed, Chibon explained the connection: "This little crab moves from shell to shell as it grows up. I found it was a nice analogy with this forge where [a] project can move from place to place."

As with many projects these days, pagure has a list of easy fixes for those who want to get involved. A look through the issue tracker will provide a sense for where things may be headed. For example, Python 3 support is in the plans, and there is a "py3_work" branch where that work is going on, though, at this point, running pagure on Python 3 is a bit of a "bumpy ride", Chibon said.

Overall, it seems like an interesting project that fills an important niche, though it is not the only project of that sort. For example, Kallithea is a free-software, Python-based forge with both Git and Mercurial support. It is GPLv3-licensed, rather than the GPLv2 chosen by pagure, but the goals of the projects are similar. Some may question the need for both.

In some sense, Fedora project leader Matthew Miller touched on that with an issue (tagged "wishful") he posted about integrating pagure with the Taiga project management platform. He was concerned that pagure was not getting enough traction to attract a development community outside of the Fedora world, not to mention that it was adding yet another bug tracker for Fedora.

While pagure certainly seems like a nice tool, there is a risk of "too many" efforts like these. A major part of GitHub's appeal is the network effects that come from many developers already having an account with the service and the knowledge of how to use it. Splitting the free-software community's attention into multiple different platforms, each with its own idiosyncrasies, accounts, and so on, may not lead to a freedom-focused alternative and, instead, continue the fractured landscape we see today. On the other hand, there may be ways to link up pagure, Kallithea, and others to create some kind of federated, free meta-forge for hosting projects—one that is large enough to benefit from network effects of its own.

[ Thanks to Bruno Wolff III for suggesting the topic. ]

Comments (24 posted)

Distribution quotes of the week

-- Greg Kroah-Hartman

-- Rich Freeman

Comments (4 posted)

GNU Hurd 0.8, GNU Mach 1.7, GNU MIG 1.7 released

The GNU Hurd kernel 0.8, the GNU Mach micro-kernel 1.7, and GNU MIG (the GNU distribution of the Mach 3.0 Interface Generator) 1.7 have been released. See the announcement for details.

Full Story (comments: none)

Bits from the DPL -- April-May 2016

Debian Project Leader Mehdi Dogguy presents his first report since the elections. To begin, thanks are due to everyone involved in the elections and to Neil McGovern for his work as a DPL. Other topics include ZFS On Linux, Newmaint team call for help, communication about technical work, Debian Sun Camp, and more.

Full Story (comments: none)

Debian Project thanks Mythic Beasts for loaned hardware

Mythic Beasts loaned the Debian project a large build machine configured with 12 cores, 256 GB RAM, multiple disks, SSDs and NVMe storage. This was used to evaluate various possible configurations for a new central build machine for image production. "Several weeks of benchmarking told us that the best option was simple: using SSD for the working filesystem. Pre-caching in RAM didn't make a noticeable difference; the Linux VM system is clearly already very effective for using RAM cache here. The effect of the output filesystem was almost negligible in all the tests; tests using SSD here were no faster than disk, suggesting the input data was the limiting factor."

Full Story (comments: none)

Imagination accelerates Debian development for 64-bit MIPS CPUs

Imagination Technologies recently donated several high-performance SDNA-7130 appliances to the Debian Project for the development and maintenance of the MIPS ports. "The SDNA-7130 (Software Defined Network Appliance) platforms are developed by Rhino Labs, a leading provider of high-performance data security, networking, and data infrastructure solutions."

Comments (none posted)

Announcing the release of Fedora 24 Beta for Power64

Fedora 24 Beta for Power64 has been released in server and cloud editions.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 661 (May 16)
• 5 things in Fedora this week (May 12)
• Lunar Linux weekly news (May 13)
• openSUSE Tumbleweed – Review of the Week (May 14)
• Tails report (April)
• Ubuntu Kernel Team newsletter (May 17)
• Ubuntu Weekly Newsletter, Issue 465 (May 15)

Comments (none posted)

Forked Debian Beta Is Rough Around the Edges (LinuxInsider)

LinuxInsider provides a user's look at Devuan Linux Jessie 1.0 beta. "The init process is under the hood. It does not get in the way. Devuan Jessie 1.0 beta installed and worked out of the box. Because it's a beta release, of course the developers have more work to do. As a user, however, I am pleased with Devuan's performance and await the kind of improvements and polishing I would expect of any Linux distro."

Comments (2 posted)

Linux Mint 18 (Linux Journal)

Linux Journal takes a look at the upcoming Linux Mint 18 release, based on Ubuntu 16.04 LTS. "Besides the changes in the installation experience, Mint 18 also will introduce the Xapps suite. Xapps is a collection of four GNOME-based applications, which are designed to provide a consistent experience on different platforms and desktops. These basic apps will replace several other apps that are included in the current version of Mint. Xapps includes the Totem-based Xplayer media player, which will be familiar to Mint 17 users. There's also a new text editor called Xed, which is forked from Pluma. Xapps includes the Xviewer image viewer as well, which is derived from eog (Eye of GNOME). Finally, there is an Atril-based document reader called Xreader, which is replacing Evince on Cinnamon and MATE versions of Mint 18."

Comments (1 posted)