Bits from the Release Team (Jessie freeze info)

[Steven Chamberlain]

Hi Niels,

This was quite interesting as it seems to tie in with some other
projects that are already being pursued...

I would love for us to have an automated system to give us a
"weather-report" on the toolchain for each architecture. It would be
nice both for us to see how ports are doing and for porters to spot and
fix problems early.

That sounds a lot like the purpose of Jenkins[0], but I'm not sure if
it's exactly suitable. It seems a little heavy, that someone could more
easily be able to script some cron jobs for a task than learn how to use it.

And Jenkins isn't available yet on all arches; some ports may not have
hardware powerful enough to run it. Maybe that doesn't matter - a
single Jenkins instance might be able to launch jobs via remote shells
to other boxes, running the actual test suite there, or maybe just to
fetch, analyse and report on the resulting log files.

Ideally I'd like to see a set of command-line scripts runnable either
from cron, or maybe someday by Jenkins jobs if someone wants to set that
up. And packaged up for people to use at home!

[0]: http://jenkins.debian.net/

Which implies "a set of packages" being "the current version of the
overwhelming part of the archive" plus all of d-i. However, that is not
something you "just build", so having a smaller set as a basic test
would probably be way more useful. I am not aware of such a "basic test
set", so feel free to propose one.

Some people have been trying to identify small sets of essential
packages already, in the context of bootstrapping an architecture[1]. I
wonder if that's likely to overlap with this? It encompasses toolchain
and essential arch-specific packages.

I imagine a healthy port should be able to bootstrap itself with only
current package versions. If this was being tested regularly it could
let porters know if circular dependencies are introduced, for example.

[1]: https://wiki.debian.org/DebianBootstrap#Toolchain

I would maybe take that a little further and say that a system is only
stable if it can bootstrap itself, install and boot into the resulting
system, and repeat the whole process again...

I like the "toolchain nightly" thing as well. I don't think it is
"required", but it sounds like the kind of thing that would help people
spot issues sooner rather than later!

And this also ties in with the reproducible-builds project[2] (not sure
if you were hinting at that before). The 'toolchain' is of particular
concern because the security of the whole system depends on it.
Differences in the output of builds needs to be avoided, or otherwise
explained. It would help greatly if there were frequent builds
happening so we could see unexpected changes occurring.

[2]: https://wiki.debian.org/ReproducibleBuilds

So if something can make something that fulfills all the above goals it
would certainly be beneficial :)

Regards,

[Steven Chamberlain]

Jenkins can have slaves on remote hosts, via SSH. It runs a small java
app there, so as long as the arch has a JVM then you're pretty right.

That may be useful to set up on some arches, for things where Jenkins
needs direct control over CPU-intensive tasks. Building and testing
d-i, for example.

But for this, I would imagine only the test suite needs to run over SSH,
and the master Jenkins instance just has to process the output?

For the proposed test suite to be as accessible as possible to a
new/upcoming port, the barrier to using it ought to be very low. A
working JVM is quite a lot to ask, the current openjdk-7 is not even
built for mipsel in more. mipsel buildds and porterboxes had only 1GB
RAM maximum until now, and that is heavily used already for their
current tasks.

Regards,

[Don Armstrong]

In this regard; I am guilty of filing some those bugs without tagging
them. Honestly, adding the tags get a bit in the way right now. If a
package FTBFS on 4 architectures, I have to dig up 3-4 different
usertags (with different "user") and associate it with the bug.

This sounds like a case where we should turn these usertags into fully
fledged tags. [Or alternatively, they should just be made usertags under
the debian-***@lists.debian.org user or similar.]

I'm OK with assisting with either, but I need to know which solution
porters would prefer.
--
Don Armstrong http://www.donarmstrong.com

"For those who understand, no explanation is necessary.
For those who do not, none is possible."