Re: Bits from the Release Team (Jessie freeze info)

2013-10-22 Thread Steven Chamberlain
Hi Niels,

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

On 21/10/13 16:42, Niels Thykier wrote:
 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
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5266df9d.9040...@pyro.eu.org



Re: Bits from the Release Team (Jessie freeze info)

2013-10-22 Thread Stewart Smith
Steven Chamberlain ste...@pyro.eu.org writes:
 On 21/10/13 16:42, Niels Thykier wrote:
 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.

It's actually a pretty low barrier to entry, if you know what commands
you need to run, it's pretty easy to get started with jenkins (create
job, have it execute shell commands, write shell in box, hit build).

I'd say that it's about 10 times more likely you'll get it right in
Jenkins before you get it right in cron.

 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.

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.

-- 
Stewart Smith


pgpSPPoXYNAvp.pgp
Description: PGP signature