Re: Automated piuparts when entering the archive (Was: Debian development and release: always releasable (essay))
On 2013-05-20 23:54, Holger Levsen wrote:
> Hi,
>
> On Montag, 20. Mai 2013, Andreas Tille wrote:
>> I vaguely remember this statement from about one year (+/-x). I wonder
>> what would it help if everybody *should* but does not? If it should be
>> done on any upload anyway (and close to nobody is really doing it) why
>> not automating this step?
>
> I am absolutly in favor of doing this, but this either needs (more hardware)
> ressources or is non-trivial. Still, I'm all for it and happy to help.
That might be possible with DPAs and if upload management is changed
generally to get less "broken" packages into unstable. E.g.
* each upload to sid gets quarantined in its own DPA
* (uploaded architecture gets rebuilt - reject on FTBFS)
* (arch all gets rebuilt - reject on FTBFS)
* package gets built by buildds
* package is being checked (one (fast, major) architecture may be
sufficient):
- lintian
- piuparts install in sid, purge
- piuparts install in testing, distupgrade to sid, purge
- piuparts install in stable, distupgrade to sid
- if any test fails, package is put on HOLD
- maybe do other checks, e.g. for hidden API/ABI changes
- maybe run autopkgtest
- certain failures could result in a REJECT
* britney either moves the package to sid, or the package is put on HOLD
- age and RC bug status are ignored (it's unlikely the just uploaded
package will introduce new RC bugs that are already filed)
- only "installability" is considered
- anything that doesn't introduce new problems is allowed into sid
immediately
- this should prevent getting uninstallable packages (dependencies in
experimental) into sid
- this should prevent getting FTBFS in new packages into sid
(but this could still introduce FTBFS in "related" packages)
- this should prevent uncoordinated transitions getting into sid, at
least if SONAME has changed and packages were renamed properly
* if a package was put on hold, the DPA is made publically available,
e.g. as DPA://$DISTRO-uploads/$UPLOADER/$SRCPKG
this contains exactly one source package, depends on sid and will be
removed once sid got the same or a never version (or on explicit
request)
There may be the case requiring several new packages to move to sid at
the same time to not break sid installability constraints, maybe
involving packages from more than one developer. One of them (or anyone
else) sets up a merge DPA (let's call it DPA://anbe/foo-bar) consisting of
- DPA://sid-uploads/alice/foo
- DPA://sid-uploads/bob/bar
- ...
and requests migration to sid (via
dcut-ng-ng migrate --to sid DPA://anbe/foo-bar)
That will first perform checks on the new package set and thereafter do
a britney run with no age or rc checking - of course this DPA can be put
on hold, too.
If a package was put on hold due to unsatisfied dependencies, there
could be dcut-ng-ng retry DPA://sid-uploads/anbe/foobar
For a regular transition (that requires binNMUs), these would be
scheduled in some transition-DPA ... and finally be checked and migrated
to sid ...
Of course there need to be possibilities to override/bypass some of
these checks and allow "broken" (or maintainer-uploaded) packages into sid.
For piuparts failures there should be possibilities to
"piuparts-recheck" and "piuparts-ignore" a certain ${package}_${version}
For britney it should be possible to force a package into sid even
though it is not yet built everywhere (where it was previously built).
The same could be done for experimental.
(That was mainly quick brainstorming without working out too many details.)
Andreas
Reply to: