Inftrastructural Changes revisited

Our fortnightly Core-Team Meeting last night was again dedicated solely to the planned structural changes to improve our workflow and make it easier for our users to participate.

As mentioned in my last blogpost, we wanted to simplify the package lists in our buildsystem pyfll. It took a few weeks of discussion to settle on a compromise. People interested in this or the ones who use our buildsystem privately might follow the changes ahead in the log starting at [21:08:57]. The 2nd topic last night was on repository structure and new repository names. This is interesting for all users, because it’s in regard of their sources.list.d/siduction.list. First of all: don’t panic. We made some changes already to test if old and new denotations work at the same time. They do, so now we can set up links from old to new. You as user need not do any changes now, things will just work. But of course you can if you want to be safe for the future. New installs will of course use the new notation.

Here is the revised structure:

  • base was formerly called siduction. It holds all official siduction packages.
  • community iis gone, it was never used (please remove it from your list if you have it in there)
  • extra is new and holds all packages not in base or users. (packages we build for enhancement of siduction, packages which are not in debian (yet) and aren’t essential part of siduction)
  • user is for packages from experienced users / team members who want to distribute their packages (like towo’s inkscape and gimp packages)
  • fixes temporarily holds packages that are broken in Debian, if we have a quick fix for them. The future goal is to send those patches upstream.
  • razorqt will dissolve into base as soon as we add Razor-Qt to our official release cycle
  • experimental is quite self explanatory
  • experimental-snapshots is just a proxy for team needs. (users should not have this in their list)

The repository website has the right lines for you to add or change.

The next topic was also about repositories, trying to define where to keep the package sources in a most meaningfull way. For the base and extra repositories this is clearly our own infrastructure (chili/git). The sources from the user repository should be separated from our infrastructure. The reasoning behind that is that anyone should be able to fork these in a simple fashion, package and distribute them in other projects. Github seems to be the way to go here. It’s layed out to be forked, Any changes to forked packages are just a merge away from being backported to the original source.

The last topic for last night was Jenkins. It needs more time and testing. We all agree it is not urgent and has to be the last in line of our improvements. If we have it set up in a useful way and fully understand how it works, it can save us a lot of time by automating a lot of the processes we do manualy now.

On a different topic, time has come to think about a name for our next release, because the art-team needs time to develop a release-art for it. The process we have in place for choosing a name (users submitting their favourites, team choosing the winner by vote) is not really flawless or satisfactory as far as I am concerned.. If anyone has a better idea for this reoccuring routine, we’d be happy to hear it. Other than that, if nothing great comes up, we will use the old method once more. So be prepared for a wiki page to be announced soon on behalf of this.

Leave a Reply

Your email address will not be published. Required fields are marked *