Re: Re: [Cooker] The Weekly Cooker -- idea.

2001-06-05 Thread Kyle Jacobs

The idea wasn't about saving bandwidth, but about increasing the testing time 
available for cooker.

I mean 24 hours is just not enough time to give a distro any kind of full 
rigours of testing.

A weekly ISO image, sanctioned by Mandrakesoft of the cooker distro would give 
a full week to testers to hack, as well as give those who like the hemoraging 
edge (downloading via. network every day) what they like as well.





 On Tue, 05 Jun 2001, Blue Lizard ([EMAIL PROTECTED]) wrote:

 Eaon wrote:
 
 That seems a wee bit daft.  In exactly what way does it save bandwidth
 to
 have someone download 1 Gig of individual RPMs versus 1 Gig of ISOs? 
 It's
 still 1 Gig.
 
 Anyway, I'm seeing ISOs there.  They're kind of scattered - some in
 Mandrake-iso (SNF, freq, corpo) and some in Mandrake/iso (8.0) - but
 they
 are there.
 
 Eaon
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of Blue Lizard
 Sent: Monday, June 04, 2001 5:15 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [Cooker] The Weekly Cooker -- idea.
 
 
 The big guy at rpmfind got real mad and took off ALL isos cuz it took
 up
 so much bandwidth.  See the note he left in the directory.  Dont think
 he ever put em back up.
 This was one day after i was downloading them both at same time
 amounting to 600kbs.
 
 
 
 
 
 
 Dont ask me.
 And i saw some isos and figured the move-around would confuse the 
 mirroring process enough to get em on there :)
 
 
 
 
 





Re: Re: [Cooker] The Weekly Cooker -- idea.

2001-06-04 Thread Kyle Jacobs

If these weekly files were auto-generated on a weekly basis (on the mirrors 
themselves), AND Bugzilla had a weekly entry for the weekly cooker (dated, of 
course), then this would be a perfectly viable alternative.





 On Mon, 4 Jun 2001, pablito ([EMAIL PROTECTED]) wrote:

 on the Weekly Cooker idea -- wouldn't  it be possible to write a script
 that
 automatically builds iso files of the current cooker every week, and
 stick
 it on the mirror sites?  The script would run at a certain time every
 week.
 That way, you could have a daily cooker,  and those who have troubles
 making
 these iso files could download weekly iso files.
 
 although maybe the mirrors wouldn't be happy running scripts.  --
 
 -Original Message-
 From: Kyle Jacobs [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Date: Wednesday, May 30, 2001 7:48 PM
 Subject: [Cooker] The Weekly Cooker
 
 
 I think itÂ’s time we all took a look at the cooker release policy.
 
 What we appear to be doing now is releasing daily cookers.  Each day, a
 new
 Distro for public testing, tinkering and revision.
 
 
 
 
 
 





Re: Re: [Cooker] The Weekly Cooker

2001-05-31 Thread Kyle Jacobs

If the cooker releases were reduced to just 1 or 2 a week, then the 
Mandrakesoft staff would actually have time to test, before releasing a cooker 
to ensure the minimal functionality of installing, and booting.

I just think that a majority of problems that weren't addressed in the 8.0 
release came because of the philosohy of the gaurenteed daily releases.  24 
hours isn't enough time for people to do a good job until the next release.





 On Wed, 30 May 2001, Tim ([EMAIL PROTECTED]) wrote:

 This idea has one flaw that I forsee as a fatal one. What if that one
 release is a complete dud? There have been times in the past when a
 cooker
 release was a complete no go for some people. They needed the daily
 updates
 to get back to testing. Perhaps personally you could just upgrade files
 from
 time to time and then do a complete install once a week for testing
 purposes? Personally I like my hourly cron job running the rsync script
 to
 update my local tree.
 
 Just my 2 cents.
 
 -Tim
  And a weekly cooker doesn't mean a featureless one.  We can throw all
 the
 new,
  bleeding and hemorrhaging edge technology we want into the weeks
 cooker,
 and
  spend the week not only addressing the regular components, but also
 the
 new-
  technology ones.
 
  If a weekly cooker sounds too sparse, how about two weekly cookers? 
 One
 at the
  beginning of the week, one at the end?
 
  Just thought this might be a good idea.
 
 
 
 





Re: Re: [Cooker] The Weekly Cooker

2001-05-31 Thread michael

What makes a new cooker? Some days I update and it's 25 megs. Today, after a 
few days wait, it was 330 megs. Maybe a better approach would be to wait as a 
user a week between updates...I am sure that as the daily changes are made, 
the people working on the packages appreciate the feedback and would prefer 
not to have to wait a whole week.
My $.02 (US)
--
On Thursday 31 May 2001 17:57, you wrote:
 If the cooker releases were reduced to just 1 or 2 a week, then the
 Mandrakesoft staff would actually have time to test, before releasing a
 cooker to ensure the minimal functionality of installing, and booting.

 I just think that a majority of problems that weren't addressed in the 8.0
 release came because of the philosohy of the gaurenteed daily releases.  24
 hours isn't enough time for people to do a good job until the next release.

  On Wed, 30 May 2001, Tim ([EMAIL PROTECTED]) wrote:
  This idea has one flaw that I forsee as a fatal one. What if that one
  release is a complete dud? There have been times in the past when a
  cooker
  release was a complete no go for some people. They needed the daily
  updates
  to get back to testing. Perhaps personally you could just upgrade files
  from
  time to time and then do a complete install once a week for testing
  purposes? Personally I like my hourly cron job running the rsync script
  to
  update my local tree.
 
  Just my 2 cents.
 
  -Tim
 
   And a weekly cooker doesn't mean a featureless one.  We can throw all
 
  the
  new,
 
   bleeding and hemorrhaging edge technology we want into the weeks
 
  cooker,
  and
 
   spend the week not only addressing the regular components, but also
 
  the
  new-
 
   technology ones.
  
   If a weekly cooker sounds too sparse, how about two weekly cookers?
 
  One
  at the
 
   beginning of the week, one at the end?
  
   Just thought this might be a good idea.




Re: Re: [Cooker] The Weekly Cooker

2001-05-31 Thread Vincent Meyer

I thought the testing was OUR job!  We find the bugs, they squash the bugs, 
no?

V.

On Thursday 31 May 2001 04:57 pm, you wrote:
 If the cooker releases were reduced to just 1 or 2 a week, then the
 Mandrakesoft staff would actually have time to test, before releasing a
 cooker to ensure the minimal functionality of installing, and booting.




Re: Re: [Cooker] The Weekly Cooker

2001-05-31 Thread Kyle Jacobs

My comment was to the idea that a weekly release could be tested to ensure 
minimal functionality before being release for one weeks worth of testing.

The originial idea is that only one or two cookers a week could not only 
simplify the development process, but also streamline it.

Instead of having to file bug reports (That end up in the cooker mailing list) 
every day with every release, a single weekly release would give testers five 
whole days to throughly document AND test their bugs for things (like 
reoccourance), and five days to submit that info.  

The results could then go into the next weeks cooker, which could feature the 
fixes and the results from the previous weeks bug reports.

One complaint is that some cookers don't function AT ALL, and that the next 
days cooker could be required to resume testing.

My proposal was that the Mandrakesoft staff test at minimum the installer and 
boot process before releasing the weekly cooker, all other problems (including 
installation and boot problems not addressed already) could be submitted 
through Bugzilla by the public.








 On Thu, 31 May 2001, Vincent Meyer ([EMAIL PROTECTED]) wrote:

 I thought the testing was OUR job!  We find the bugs, they squash the
 bugs, 
 no?
 
 V.
 
 On Thursday 31 May 2001 04:57 pm, you wrote:
  If the cooker releases were reduced to just 1 or 2 a week, then the
  Mandrakesoft staff would actually have time to test, before releasing
 a
  cooker to ensure the minimal functionality of installing, and booting.