I agree with this sentiment -- and it was never my intention to put any pressure on the Seaside project to rush the beta.  People who know me well know that I will always choose quality over schedule -- schedules are meant to be changed :-)<div>
<br clear="all">John O&#39;Keefe [|], Principal Smalltalk Architect, Instantiations Inc.<br>
<br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 6:49 PM, Conrad Taylor <span dir="ltr">&lt;<a href="mailto:conradwt@gmail.com">conradwt@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Julian, I would recommend doing what&#39;s best for the project.  Thus, I wouldn&#39;t rush anything out to meet vendor timelines because they can simply download/import Seaside Beta when it&#39;s ready.  I say this because it would be a disservice to the quality of the project.  Some may be able to work around the issues but some may not.  In short, your decision(s) should benefit the project.<br>

<br>
Just my 2 cents,<br>
<br>
-Conrad<br>
<br>
Sent from my iPhone<div><div></div><div class="h5"><br>
<br>
On Sep 21, 2009, at 2:49 PM, Julian Fitzell &lt;<a href="mailto:jfitzell@gmail.com" target="_blank">jfitzell@gmail.com</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, Sep 19, 2009 at 11:45 AM, Lukas Renggli &lt;<a href="mailto:renggli@gmail.com" target="_blank">renggli@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How does everyone else who is using/developing 3.0 feel? What&#39;s still missing?<br>
</blockquote>
<br>
I think the remaining issues for beta1 are not that critical (mostly<br>
configuration UI related).<br>
<br>
  <a href="http://code.google.com/p/seaside/issues/list?can=2&amp;q=milestone%3A3.0b1" target="_blank">http://code.google.com/p/seaside/issues/list?can=2&amp;q=milestone%3A3.0b1</a><br>
<br>
I noticed that the debugger is beta2, is that correct? I personally<br>
find that more important than any of the other bugs tagged as beta1.<br>
<br>
Personally I don&#39;t have much time to work on Seaside the coming<br>
months, but I don&#39;t mind going beta. After all it is just a name tag.<br>
</blockquote>
<br>
Well, ok, I looked at the list of issues. First of all, I can&#39;t see<br>
anything that is *not* tagged for b1 that should be, so that&#39;s good. I<br>
moved one issue from b1 to b2.<br>
<br>
I do think the debugger can wait until b2 because I doubt fixing it<br>
will make it hard for people to update their images. It is a &quot;known<br>
issue&quot; for the release.<br>
<br>
Issue 405 would be nice to have done and isn&#39;t a huge amount of work,<br>
but it&#39;s probably not the end of the world if we punt to b2.<br>
<br>
The remaining two issues are the sticky ones.<br>
<br>
Issue 454 (about entry point, parent, etc) really should be resolved<br>
because it will make changes to a key hierarchy. I think the answer is<br>
to merge entry point and request handler and I can do this in the next<br>
few days if people agree.<br>
<br>
Issue 263, which is kind of a catch all for a whole bunch of<br>
configuration woes is nasty. On the one hand, we probably could just<br>
about punt on this until b2; but on the other hand, I have horrible<br>
visions of people deciding to finally try the new version once it hits<br>
beta and getting hit by that config UI, not knowing how to add<br>
filters, etc. It seems like a terrible first impression.<br>
<br>
So I&#39;m open to opinions on that. Do we rush out a beta to meet the<br>
vendor timelines even if it leaves a worse first impression for users?<br>
I&#39;m leaning one way but I&#39;ll wait to hear what others say before<br>
skewing the discussion.<br>
<br>
Finally, if we do go beta, there are two other issues:<br>
<br>
a) what are we holding ourselves to (ie. what are we promising not to<br>
change/break/do)? We should define this so we have a firm response for<br>
why certain changes will not happen until the next release.<br>
<br>
b) what do we actually need to do to make a beta? Just a builder<br>
release and an updated one-click? Some of the class comments on key<br>
classes seem pretty out of data... are we ok with that?<br>
<br>
Julian<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</blockquote>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org" target="_blank">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</div></div></blockquote></div><br></div>