No subject

Tue Jun 7 16:00:01 PDT 2011

LSB spec that is useful rather than have one "on time" which isn't really g=
iving us much improvement. A major goal of the LSB is to provide a target t=
o aim at. If that target is half-baked, ISV's will ignore it and then you'd=
 have to question what the point of making the release was.

I generally agree with Robert's and Mat's comments regarding prioritisation=
. My own version of things would go something like this:

(1) Get deprecation items sorted first. Things can be added later, but not =
so easily removed later. A x.0 release is the time to do removals.
(2) Revisit all trial use modules. Any that have been part of the LSB in th=
at form for an appreciable amount of time should be either added as a first=
 class part of the LSB or removed.
(3) Identify things that "should have been in the LSB long ago". Of those, =
pick the ones that actually have a chance of getting done on a useful times=
cale. The harder/more complex ones can come in a later release. Everyone ha=
s different ideas of what "should have been in the LSB long ago", but there=
 are likely to be some that have more general agreement.
(4) Are there any things that people have requested be added to the LSB and=
 that don't have significant technical barriers? These would seem to be goo=
d candidates for inclusion in LSB 5.0. You could pick and choose based on h=
ow much time you wanted to spend on these.

I also agree with Mats view that a feature-based release would be preferabl=
e to a time-based release. Definitely have a rough delivery date in mind, b=
ut that doesn't have to be an immovable date. If it starts looking like the=
 date is going to have to shift by some non-trivial amount of time, then st=
art looking at the items from (4) and maybe (3) (okay, and if really desper=
ate, from (2) as well) that can be bumped to the next release. Items from (=
1) should be considered blockers.

Just my $0.02

On 08/06/2011, at 5:20 AM, Robert Schweikert wrote:

> On 06/07/2011 12:07 PM, Jeff Licquia wrote:
>> On the call last week, we talked very shortly about the release schedule
>> for LSB 5.0.  I proposed something like a time-based release ("work on
>> stuff until a certain date, then freeze and release").  There were some
>> concerns, but we ran out of time on the call before we could get into
>> those concerns.
>> The main concern, I think, was in understanding what things are
>> important, and making sure they get done.  Since we're at a big
>> inflection point, it's important to make sure we get the deprecations,
>> removals, and additions right; if we end up not having time to do that,
>> it's not good to just say "well, too bad, we're out of time; gotta wait
>> another few years for the rest".
>> The implication is that we won't do any kind of project planning for the
>> items on the list: prioritization, time estimates, etc.  We still need
>> to do those things, in particular for the kinds of tasks we can only do
>> at a "dot-zero" release.  Ideally, we would have a "time-based" date
>> that takes those estimates into account, just like previous releases.
> Confused, first you say "no planning" then you say "plan as in previous=20
> releases". These appear to be opposing statements.
> IMHO we should go about it the following way.
> 1.) Make our list of priority 1 items that need to be in 5.0 or it's not=
> worth releasing
> 2.) Prioritize a "nice to have list"
> 3.) Estimate the time it will take use to get all features in 1.) done=20
> plus some fudge factor to accommodate issues discovered along the way.
> After step 3 is done we have our target release date.
> From here we have 4 options.
> a.) If not everything on the list from 1.) is done by the target release=
> date we slip the date (this should not be up for discussion at that time)
> b.) I everything is done as planned we release as planned. That would be=
> a very welcome first ;)
> c.) If we get done early with everything on the list for 1 we can start=20
> on items from the item 2 list
> d.) If we get done early with everything on the list for 1 we can=20
> release early.
> Robert

Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

More information about the lsb-discuss mailing list