[birt-pmc] Can we discuss at today's meeting if we have time

[Michael Fox <foxm@xxxxxxxxxx>]

Sorry about the short notice.

        Mike

----- Forwarded by Michael
Fox/Lexington/IBM on 04/03/2006 12:50 PM -----

Cheng-Yee Lin/Beaverton/IBM

04/02/2006 01:31 PM

To	wli@xxxxxxxxxxx
cc	Cheng-Yee Lin/Beaverton/IBM@IBMUS, Michael Fox/Lexington/IBM@IBMUS
Subject	Nightly builds for BIRT

Wenfeng,

At this stage of the Callisto release,
the IBM Eclipse SDK (IES) build is trying to pick up the nightly builds
from each of the components to create its weekly integration build.  This
will give the IES consumers better chances to adopt (or react to) the changes
in those components more quickly, and identify potential issues earlier,
and hopefully make the road to the GA release much more smoothly.

One thing that we observed last week
was that -- BIRT posted 3 nightly builds (N20060328, N20060329, and N20060330)
with green checkmarks on all their download zip files.  However,
the daily build status communicated through the birt-dev list indicated
that all of them have some blockers during the smoke tests, and when we
downloaded and installed their zip files, sure enough, we ran into those
problems (e.g. (a) no report design perspective or any BIRT menus, (b)
cannot create a report design successfully, (c) cannot data the sample
data source/set properly).

Here are some of my thoughts:

. The status on the download pages (e.g.
the link for N20060328 build)
should display the actual state more accurately.  It seems to me that
if there is a blocker, it is likely that something major is not functioning
properly, and that should be known by the consumers (most of the consumers
are not on the birt-dev list as I would imagine).  (I apologize if
this status is used in a different way than I thought.) 
. It is important to be able to consistently
create "usable" builds.  As BIRT is going through the massive
scale of code reorganization (e.g. upgrading the plugin bundle manifests,
creating single jar files for plugins, adding Eclipse features), it is
expected that there would be some days when the builds cannot be created
correctly.  However, it would start causing adoption issues for the
consumers if the time without good builds is stretching longer.  (We
do run into issues like that our own code development at times.  When
that happens, creating a good build with usable functionality would certainly
become the highest priority, and only the check-ins that fix the build/major
regression are allowed until a good, usable build can be built.) 

Please let me know if you would like
to further discuss the issue.  Also, let us know how we can help on
this.

Thanks,
-- Cheng-Yee