[lsb-discuss] Resuming LSB F2F work sessions

Wichmann, Mats D mats.d.wichmann at intel.com
Tue Dec 2 10:54:54 PST 2008

Those of you who have watched the LSB 4.0 process 
have seen a tremendous amount of work get done, and
a huge variety of topics get considered.

My own personal analysis is that we've had way too
much trouble with two areas:

- closing out issues - making the final decision,
implementing it, and closing the bug (or alternatively,
moving the bug out of the 4.0 target list or rejecting it)

- the support infrastructure - build machines, release
construction, repositories, autotesting, etc.

We've made progress on the latter, although as anyone
who's worked for a consulting/contract house will know,
infrastructure is *horribly* expensive: it takes loads of
time that you can't "bill" to the current project, or in 
our case, takes loads of time away from the current project.
So it has certainly been in the 4.0 cycle, the amount of
wasted time due to infrastructure is incalculable.

The former... my experience from the past is we need to
get together in a room in order to make certain leaps forward 
in closing out issues. Bug ballots have been a good step
forward; irc-based bug sessions have made us some progress;
normal bug-commenting activity has been high. 

So I'm going to make the proposal that in 2009 we resume
the LSB workgroup F2F sessions, that we've at various times
called things like "working meeting", "sprint", "hackfest",
etc.  These sessions - the most recent cycle of these were
run about quarterly - are only for making progress on
existing issues, not for presentations to/from other groups,
progress reports, requirements gathering or other such
worthy goals (we have the LF Collaboration Summit at the
very least for that purpose).

I know times are tough financially, and it may be concluded
that we can't afford to pull this off, or can't do as many
as three in 2009 (which would be my proposal). I'm taking 
the engineering perspective here and presenting only what I
see as a technical need in order for us to be more effective 
in our next development cycle.  If the workgroup agrees 
there's a need, then others can look at financial and other 
considerations and weight those out and see what's possible.
But let's first see if anyone agrees with me as to need.

-- mats

More information about the lsb-discuss mailing list