On 3/16/06, J. Hartline <jasperhartline@xxxxxxxxxxxx> 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. -jef 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 functionality. -- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list
