Re: [wtp-dev] Integration build process

[David M Williams <david_williams@xxxxxxxxxx>]

I agree with everyone's thought's on
the need for more testing .... but not sure we're "closed" in
the process part of Tim's original post. (If I missed that, let me know,
but assuming we're not ....)

I think a formal process of reporting
results and "go/no-go" results for I-builds is probably too much
bureaucracy for a weekly I-build (though definitively needed for M-builds).
[But, I'm sure,  component leads that repeatedly allow bad I-builds
(that either fail, or do not run well) will not go unnoticed].

For I-builds, since, in my view, one
of their main purposes is to serve as a PDE target for other developers
I think its fine to simply assume everyone's done some testing before the
I-build, (and eventually we'll have better JUnit testing to catch obvious
errors) so if it builds, it should be assumed "good" to use as
PDE target. If someone quickly (say, same day) notices a problem that really
interferes with using it as a target, then they could "request a rebuild"
(and, if they do that on wtp-dev list, everyone would know another was
coming soon). If the bad-bug isn't noticed until a day or two later, I
think its fair to simply document "use such and such version of xyz
plugin with latest I-build to work-around such and such bad bug".
(again, on wtp-dev, with reference to bugzilla bug number). 

Does this sound like a workable process
for "I-builds"? Maybe the answer to this depends on next issue
(see point '2'). 

There's another, related "process"
issue I'd like to get some common ground on. I've noticed some teams like
to version and release frequently, but others wait until "just before"
I-build before versioning and releasing plugins. I prefer the frequent
version and release approach -- often once a day, if not more -- basically,
when ever changes are made that are intended for the next I-build, that
is the time to go ahead and release that project, even if build won't take
place for days, and even if more changes are expected. I think there's
two advantages for this: 

1. Within a team, it allows more "roll-back"
and "compare" points if someone accidentally introduces some
bad bug in a component. 

2. It allows people across teams to
"load released projects" (for all map files) to get an early
look at how the I-build will behave, just using the development environment,
and possibly even PDE tools. This is especially important the day or two
before the I-build. Its really not very useful to assume what ever is in
head on Tuesday or Wednesday will be in the Thursday I-build -- since some
teams may want to "stabilize" on a particular version a day or
two before the I-build, but might commit some changes to HEAD, for the
following weeks I-build (this has already happened at least once that I'm
aware of). In other words, I think each week should see an incremental
movement to next I-build, not all at once at end. This allows some testing
to take place before the actual I-build. 

So, does "frequently release projects"
sound like an ok principle? 

Thanks all,