no ... *really* ... any ETA for updated beta?

Jef Spaleta jspaleta at princeton.edu
Wed Aug 27 16:13:07 UTC 2003


Robert P. J. Day:
>IMHO, if RH is going to make these promises, they should at least
>try to keep them.  if not, then just go with "when it's ready."
>but please -- let's not waffle back and forth.

Its more like "when its ready, but here is our best guess at when that
will be...feel free to hold yer breath while you wait"

And as rhl's development structure moves towards rhlp, you sure as hell
better expect some waffling on policy decisions....changing from an
in-house development process to a more open community process is not
going to be a linear progression...policy changes red hat initiates,
will garner feedback, to impact that initial policy change red hat
decided to make. I'd rather have feedback and waffling now and even long
stretches of time when red hat's policies have seem to regressed back to
a fully closed development state...then have to deal with unpopular
policy decisions down the road when rhlp is in full swing.
 
Estimates are not promises.....estimates are best guesses....frankly
I'm shocked Red Hat made such a bold estimate and wrote it
down...because by doing so it open themselves up to exactly this sort of
attack. Get a grip..its a beta...even the release schedule is buggy..you
shouldn't expect otherwise.

If Red Hat continues to publish "estimates" on release schedules...they
should come with a confidence rating or Vegas odds, so that spectators
don't make the mistake of thinking they are "promises". 

And maybe...just maybe...those estimates were based on estimated release
schedules for components...and if a components release schedule slips a
bit...maybe the beta release schedule slips a bit too? Maybe there are
specific engineering goals in mind for each beta iso set? Maybe its not
just a matter of throwing the current rawhide snapshot together as an
iso. Maybe there is  different development focus during each stage of
the beta?  Maybe you don't have a clear enough picture of what the
internal drivers/priorities are to make a comment about the importance
of keeping the estimate beta release schedule in tact? Maybe it really
is in your best interest to wait till its ready? The interior timepoints
during a beta cycle should be considered far more fluid than the
beginning and end timepoints.

-jef"how about we publish a detailed minute by minute schedule for each
red hat developer...so when mharris fails to finish breakfast
on-time...we can specifically harsh him for holding up the entire beta
cycle"spaleta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20030827/bea18d64/attachment.bin 


More information about the test mailing list