Fwd: Build discussion

[C. Scott Ananian]

---------- Forwarded message ----------
From: C. Scott Ananian <cscott at laptop.org>
Date: Oct 31, 2007 1:07 PM
Subject: Re: Build discussion and Wed mtgs
To: jg at laptop.org

On 10/31/07, Jim Gettys <jg at laptop.org> wrote:
> If we go via the "build up from 623" strategy (over which I do have
> qualms, but not a strongly held opinion, having missed the discussions),
> I have a some major comments and concerns:
>
> a) I hope the notes are correct, and that we plan a serial
> reintegration, for reasons b) and c) below.
>
> b) it is vital that we get back to a single primary stream ASAP: we do
> not have enough testing resources to run parallel for very long.  We
> need developers and a larger community as well what little explicit
> testing resources we have testing what we are planning to ship.
> c) Additionally, as 620/621/622 shows, its very easy to get confused and
> forget something along the way.  How do we ensure nothing gets lost?
> Otherwise we'll debug and fix the same bugs multiple times, as happened
> with 622/623 and the JFFS2 bug.

The fundamental question is: do we plan to end up with something close
to 623, or something close to current joyride.  There were differences
of opinion there.  Going with something close to 623 incurs the
forking risks you accurately describe.  I think the consensus was that
we will be shipping something close to the current joyride as
update-1; I don't hold a strong opinion on this point.


That said, it was felt that Kim doesn't have enough insight into why
things break in current joyride builds.  Having separate builds based
on 623 with only certain subsystems enabled was a proposed debugging
aid.  The current joyride build system trivially gives you this, as I
demonstrated in under an hour last night; you can also make these
builds with pilgrim directly.  We will want to regenerate the
debugging builds continuously -- when dilinger adds a kernel patch
(say) we need to rebuild the "kernel + 623", "kernel, glibc, and X +
623", etc images, so that we can discover new regressions and their
causes.

My proposal is to reify the current joyride package set as our
"update-1" candidate on Friday.
A testing plan was proposed that started with verifying correctness of
the "kernel+623" build and working one's way up to enumerating bugs in
the full update-1, but I believe that Kim expressed a preference for
testing the full update-1 from the beginning, and using the
incremental builds only as a debugging aid to help narrow the source
of each bug they discover.  The larger developer community should not
be exposed to, or confused by, the existence of these debugging tools.

> d) explaining this in a way that is easy for the larger community to
> understand.....  We've already confused them pretty well over the last
> week.  There being yet more build terminology and/or changes in process
> yet again is asking for trouble, if not done carefully (or maybe even
> when done carefully).

Joyride will be forked to update-1 for public consumption.  Joyride,
like Debian's sid, is the name of the 'unstable' branch, which is
forked for releases.  For most of November, joyride will be closed and
there will be only update-1.

How exactly the update-1 builds get made is an internal issue between
J5, Dennis, and I; nothing I wrote above implies using a specific
build platform, build server, or build maintainer.
  --scott

--
                         ( http://cscott.net/ )