Re: Debian development and release: always releasable (essay)
On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:
> * An attitude change: we decide that releases are important, and that
> they're the job of the entire project, not just the release team.
I already believe that. I would find it quite surprising if people
actually believe that releases are solely the job of the release team.
Do you have any data about what proportion of Debian contributors
don't believe that?
Folks obviously care about stable to varying levels though, some
probably don't even use stable.
> * Keep testing free of RC bugs.
I keep packages I (co-)maintain free of RC bugs.
> * We should use automatic testing much more extensively, to find
> problems as early as possible.
I already do pay attention to that. I look at PTS pages before doing
uploads and run a bunch of automated tests before uploading or sending
a package review on debian-mentors. I also try to remember check sites
with QA/etc info that aren't yet integrated into the PTS (like the
derivatives patches).
http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
> * We should limit the number of packages we strongly care about for
> a release.
I don't agree with this.
> * Remove RC buggy packages sooner rather than later. An RC buggy
> package should be removed at soon as possible: when the bug
The release team already do this using a semi-automated method.
> We should have an explicit list of such reference installations
> and declare them as crucial for the release:
How about:
all the tasks
all the blends
> if they work, we can release, and if they don't, we can't.
How would you define "work"?
Presumably: no RC bugs, no piuparts issues?
> Use automatic testing extensively
> ---------------------------------
>
> We have some automatic testing tools specifically for Debian: lintian,
> piuparts, adequate, autopkgtest, and probably more. We should use
> these much more extensively, and let them guide the migration of
> packages into testing.
Some more automatic tests folks might like to run:
http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
> Imagine a continuous integration system for Debian: for every new
> package upload to unstable, it builds and tests all the reference
> installations. If all builds succeed, and all tests pass, the package
> can be moved into testing at once. When you, a developer, upload a
> new package, you get notified about test results, and testing migration,
> within minutes.
Different tests are more important than others. I don't think every
test is important enough to block testing migration. The only tests I
can think of that should do that are puiparts failures.
Thanks for your thoughts, hopefully the release team will be willing
to adopt some of them, especially the puiparts failures one.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: