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

[Chitlesh GOORAH]

On 3/16/06, J. Hartline <jasperhartline(a)adelphia.net&gt; wrote:
>  Fedora Core 5 final is going to be released on the targeted March
> 20th date.
>  Why not try to build a FC5 ISO, rather than a FC5 test 3 ISO with buggy
>  packages that have updates? 
I don't have FC5 iso yet.
This iso I have built on sunday.
but due to certain difficulties encountered with the upload , Filip
managed to make it possible for me to upload the iso last night.


--
http://clunixchit.blogspot.com

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

[Nicu Buculei]

Chitlesh GOORAH wrote:
>  On 3/16/06, J. Hartline <jasperhartline(a)adelphia.net&gt; wrote:
>  
> >Fedora Core 5 final is going to be released on the targeted March 20th date.
> >Why not try to build a FC5 ISO, rather than a FC5 test 3 ISO with buggy
> >packages that have updates?
>  
>  
>  I don't have FC5 iso yet.
>  This iso I have built on sunday.
>  but due to certain difficulties encountered with the upload , Filip
>  managed to make it possible for me to upload the iso last night. 
I do not want do dismiss by any means your great work in producing this 
so much needed LiveCD, but leave me outline what will happen in practice 
and why I think releasing now a LiveCD of Test3 is unfortunate:
- the release of FC5 is due in 4 days from now, this mean it will start 
to propagate to mirrors a few days in advance;
- it *will* hit torrent sites immediately after the propagation start, 
which effectively will be at the same time with the availability of the 
LiveCD;
- a large people will confuse the two, considering the LiveCD to 
represent the final FC5, due to the apparent simultaneous release.

You can't limit the spread of the LiveCD and a tag on it stating "Test3" 
will not be enough.

-- 
nicu
my hats collection: http://fedora.nicubunu.ro/hats/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro

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

[Jef Spaleta]

On 3/16/06, Nicu Buculei <nicu_fedora(a)nicubunu.ro&gt; wrote:
>  You can't limit the spread of the LiveCD and a tag on it stating
> "Test3"
>  will not be enough. 
I absolutely agree that labeling a release of anything a test release
will never be enough to prevent a segment of the userbase from
downloading it mistakenly. But i very strongly disagree that this is a
problem worth worrying about. I think its more important to move
forward with livecd development as quickly as possible then to protect
those users who are so stupid they miss the fact that its a test
release.

Document its test status, make it visually obvious at install time
that its a test release... use a different mechanism for releasing
than the official releases (ie not on the offcial fedora torrent
server)....and let the buyer beware.

This isn't a particularly dissimilar situation have happened in the
past when the 64bit and ppc versions of fedora was in "beta." when
core cut an official release.  You have to remember that the 64bit and
ppc trees started as unofficial release trees which had their own
development timeline before finally becoming an official tree with a
synced release.

-jef"I'm the pope of the fedora religion, and I like wearing funny
hats"spaleta

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

[J. Hartline]

Jeff Spaleta wrote:

> I absolutely agree that labeling a release of anything a test release
> will never be enough to prevent a segment of the userbase from
> downloading it mistakenly. But i very strongly disagree that this is a
> problem worth worrying about.
>  
Well, that isn't the only thing that sticks out as a problem.
I'm fairly sure many would agree that a Live media of a test release 
that was
issued many many days ago, the packages are now obsolete.
 
I'm not sure if you know, but you can't just "yum update" LiveCDs.

J. Hartline.

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

[Rahul Sundaram]

J. Hartline wrote:

>  Jeff Spaleta wrote:
>
> > I absolutely agree that labeling a release of anything a test release
> > will never be enough to prevent a segment of the userbase from
> > downloading it mistakenly. But i very strongly disagree that this is a
> > problem worth worrying about.
> >
>  Well, that isn't the only thing that sticks out as a problem.
>  I'm fairly sure many would agree that a Live media of a test release 
>  that was
>  issued many many days ago, the packages are now obsolete. 
Then we will have a new version later. Fedora gets updated pretty 
frequently and this is always going to be an issue.

>  I'm not sure if you know, but you can't just "yum update" LiveCDs.
>
>  J. Hartline.
>  
Everybody knows about live CD's and updates.


-- 
Rahul

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

[Jef Spaleta]

On 3/16/06, J. Hartline <jasperhartline(a)adelphia.net&gt; wrote:
>  Well, that isn't the only thing that sticks out as a problem.
>  I'm fairly sure many would agree that a Live media of a test release
>  that was issued many many days ago, the packages are now obsolete. 
what the specific package payload looks like in a TEST of the livecd
is a function of the engineering goals which the TEST release of the
livecd needs to achieve. If the developer pushing the developerment
forward needs to spin a test release to test factors that need to be
worked out which do not require the final package payload...then it
makes absolutely perfect sense.

>  I'm not sure if you know, but you can't just "yum
> update" LiveCDs. 
Who gives a crap, its a test release.  If there are technical issues
with livecds which have absolute nothing to do with which versions of
which applications are available that need testing, the developer
pushing things forward should spin a test release and provide those of
us who are willing to help test the specific guidance to focus our
efforts. Noone forces anyone to be involved in every round of testing.
If you don't want to participate in this round of testing.. then
don't.. get the hell out of the way and wait till the next test
release.

I'm personally in favor of as many incremental test release isos as
possible to work out bugs in as much livecd specific behavior as
possible for the very reason that you CANT yum update later on to
solve problems in the final release. The more incremental livecd betas
I can eat now, with specific guidance as to what features need testing
between releases, the more likely a bug won't slip through to screw up
the final release. If you don't have the bandwidth or the time to be a
part of every release in the test process, then skip some.

Hell, in my ideal world Chitlesh would be able to automate nightly
timestamped livecd iso which incorporated daily changes, so I could
track specific issues on a daily basis. More testable releases not
fewer.... release early release often.

-jef

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

[J. Hartline]

Jeff Spaleta wrote:

> Hell, in my ideal world Chitlesh would be able to automate nightly
> timestamped livecd iso which incorporated daily changes, so I could
> track specific issues on a daily basis. More testable releases not
> fewer.... release early release often.
>
> -jef
>
>   
>  
My primary argument wasn't about how many, it was about age.
Test 3 packages from the 4.92 tree are already: 16-Feb-2006 14:55 exactly
1 month old. I am positive this is unclear in my messages.

I think what is ideal is not using month old release packages from a 
test release
when Fedora Core 5 final targeted release date is in 4 days.
Did anyone consider building these daily CDs yet?
Has anyone actually considered people filing bugs that are already fixed?

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.)

J. Hartline

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

[Jef Spaleta]

On 3/16/06, J. Hartline <jasperhartline(a)adelphia.net&gt; 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-livecd-list] Fedora LiveCD build#002

[J. Hartline]

Jeff Spaleta wrote:

> 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.
>
>   
>  
Ok. Let's make sure users getting these Live discs know the Fedora Core 
LiveCD is a component
in bugzilla at the least, it can be found under "Fedora Core" as 
component "LiveCD".

> 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.
>   
>  
I'll admit, I have been grossly uninformed about the Fedora LiveCD for 
some time.
It wasn't until just a few days ago that it was brought to my attention 
all of this discussion
was happenning on the fedora-marketing-list rather than fedora-livecd-list.

I'm subscribed now, so.. hello!
Thanks.

J. Hartline

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

[Chitlesh GOORAH]

I appreciate that you are sharing some ideas.

Nevertheless I don't have a server to upload my builds.

Filip offered me the chance to upload, so from here you can download it

http://alphonsebrown.no-ip.org/free/fedora-livecd/

--
http://clunixchit.blogspot.com

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

[Filip Tsachev]

On 16/03/06, Chitlesh GOORAH <chitlesh(a)fedoraproject.org&gt; wrote:
>  I appreciate that you are sharing some ideas.
>  Nevertheless I don't have a server to upload my builds.
>  Filip offered me the chance to upload, so from here you can download it
>  http://alphonsebrown.no-ip.org/free/fedora-livecd/ 
I'm currently including a
DO_README stating this is a test build which
is old, and that I'll be  releasing an "PreFC5_test3_20060317" version
(let some time to finish updating repo & createrepo)

Cheers,
Filip