Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
Mark Howard <mh@debian.org> writes:
> BTS Support for tracking when bugs were changed
> - AFAIK, already been worked on
> This will be more important when there are a large number of
> users/testers using different distributions - sid and experimental.
changed? The time since the last message was send to that bug?
patch for debbugs in BTS. (see rfc822 feature)
> Automatic builds
> - I want galeon to be built on all architectures automatically.
> Having a simple email interface would be nice, but automatic for every
> upload would be better. The changes I'm proposing here would move
> packages from sid to experimental - they are automatically built
> for sid already, so this won't incurr much build time.
> We would need more disk space than currently used - e.g. so that the
> exp.-gnome section could be built in a chroot with sid and exp.-gnome;
> exp-.gnome-woody could be built with woody and exp-gnome-woody.
> Obviously it would require some more processor time, but IMHO
> this is well worth it.
> If buildd machines are falling behind, why don't we spend some of the
> money Debian has? Is there any real data as to which buildds are
> struggling?
> One other useful idea to reduce load would be to have some option on the
> buildds for don't attempt a rebuild (of any version) until bug x has
> been fixed.
You would have to provide different apt sources.list per build or make
a dedicated buildd per section. The later of cause is not feasable.
It shouldn't be to hard to have the normal sid chroot and add a line
for the experimental-whatever section on each build. The chroot would
have to be purged whenever the section is changed but that shouldn't
be too much of a strain.
Also you could add priorities to packages. wanna-build would choose
the highes priority first. Aging would raise the priority and packages
outside experimental get a big bonus. That way anything important (sid
) gets build first but expermintal packages won't starve eigther. For
archs that fall behind a package might skip several versions till it
gets build. Oh, skipping a version should raise the priority so
packages get build once in a while even if they do a daily release.
> In summary, changes like these would mean:
> - more people use experimental
> - sid has fewer experimental packages
> + it is broken less often (perhaps the 'unstable' name should be
> changed?)
> + testing is kept recent more often
> - It would make it possible to have official support for things like
> gnome backports
Where does that come from?
> - It may make it easier to experiment with things like having separate
> server and desktop releases. (In terms of applying the separate
> sections idea to the whole of Debian)
I would like to have sections for stable/testing/unstable too. Many
users have testing but want the more uptodate desktops. Setting pins
for anything desktop related isn't easy. Setting a pin for
testing-desktops is trivial.
Also a core section would be nice for building/developing
boot-floppies and debian-installer. A local mirror of just core
packages could be setup in a minute. At the moment its a constant
struggle to keep the right set of files current.
> Does anybody have any additions for thses ideas, or any ideas for other
> changes to aid sarge+1 development?
A remark to the implementation of sections. We already had that before
pools remember, sort of, till it broke down.
Now, instead of having packages in different directories, we would
make subdirs with Packages/Sources files. Also the current full files
could be kept in its place (keeping everything old working) and
sectionized Packages files generated from the full files by filtering
for Sections. Alternatively the full files could be made by merging
the section files, doesn't realy matter.
Should be a small impact to the mirrors to add sections. Just the
buildd changes for experimental look like needing work.
MfG
Goswin
Reply to: