[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-livecd-list] Fedora LiveCD build#002

On 3/16/06, J. Hartline <jasperhartline adelphia net> wrote:
> I wouldn't imagine so, not that I have heard of.
> Why not do as you are suggesting and build?
> (From todays packages, not yesterdays, yesterday being a month.)

If there infrastructure is not in place to spin up nightly builds it
still makes perfect sense to keep a defined... old...package payload..
if you are working on livecd specific features which have very little
to do with specific application versions.

The underlying concept is which I seem to be unable to communicate to
you is.. testing incremental changes. If you do not have the
infrastructure to roll nightly builds, which incorporate incremental
changes made every day, then you can force portions of the system to
be static and make incremental changes based on segregated
functionality.  You update a portion of the system with specific
functionality testing in mind... and then move on to another portion
of the system in a later build.

Jumping in and making a new build now which incorporates all package
payload changes as well as livecd customization features is NOT
incremental.  All you end up doing is building a livecd that is
completely different from the last build making it difficult to
compare behavior across builds and narrow down problems.

If too many things change between one build and the next it becomes
much more difficult to effectively track what causes regressions or
new problems. Pooping out a build that incorporates a significantly
different payload AND more livecd specific customizations compared to
the last build makes it that much harder to track the cause of new
regressions or new bugs. For test builds to be worthwhile for the
actual process of testing, the changes between builds can't be "too
big".  My desire to see nightly builds has absolutely nothing to do
with a desire to see latest packages.. my desire is to see as small a
set of incremental changes between livecd builds as possible. I
frankly do not care if the nightly builds track rawhide or track week
old rawhide.. or month old rawhide. I care about managable incremental
changes between the livecd builds to make it easier to troubleshoot
problems in the livecd itself.


In the case of this build, there are a number of LiveCD specific
customization which are not dependant on specific application payload
which need to be tested. Changing the package payload only complicates
the process of testing that functionality.  If you make too many
changes, it because harder to do any targeted testing for any

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]