<br><br><div class="gmail_quote">On Tue, Jun 7, 2011 at 10:07 AM, Jeff Licquia <span dir="ltr">&lt;<a href="mailto:jeff@licquia.org">jeff@licquia.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thoughts?</blockquote><div><br></div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div>When would I not have thoughts?  :)</div><div><br></div><div> I think you mostly teased out the issues, so I&#39;ll just restate a point in</div>
<div>my own terms.  LSB, although it involves lots of software, isn&#39;t really</div><div>like a software release; all the software supports the specification.</div><div>The specification describes the state of a set of features available to</div>
<div>software developers, and if that state isn&#39;t advanced by making a release,</div><div>then there&#39;s no point in making the release. For most software projects,</div><div>there&#39;s some value to getting out the work that&#39;s been done so people</div>
<div>can make use of it, even if there are features you wanted that aren&#39;t</div><div>ready.   So I will never favor really calling a release time-based: &quot;we</div><div>got very little done, but we&#39;re releasing that as LSB 5.0 anyway&quot;. </div>
<div><br></div><div>But you said &quot;sorta&quot; - and it&#39;s all about priorities; we need to be clear</div><div>on what /must/ be in the next LSB, or not even bother releasing it,</div><div>and the rest can be on a &quot;if we got to it in time&quot; basis if you like.</div>
</span><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Then you can build the plan around that.  </span> </div></div>