+1. Good catch for samples and tests. Sent from my iPhone
On Jul 1, 2010, at 4:10 AM, Simon Nash <[email protected]> wrote: > I'm OK with all of this. I believe the implication (not stated explicitly) > is that everything in "modules" needs to be included in the main build. > I think this should be a requirement, and anything that isn't ready for this > should be under "contrib". > > Also, I'm not sure how this affects the contents of "samples". I just > came across two recently added 1.x samples that aren't in the build, and > one of these can't be added to the build because it isn't buildable. > I think we should treat "samples" in the same way as "modules", which > would suggest the following structure: > > trunk > modules (for release, all in the build) > samples (for release, all in the build) > etc. > contrib (excluded from release profile) > modules (not for release, some in the build) > samples (not for release, some in the build) > etc. > > Simon > > Simon Laws wrote: >> Good ideas Raymond. Small comments in-line >> On Thu, Jul 1, 2010 at 8:11 AM, Raymond Feng <[email protected]> wrote: >>> IMO, we could have the following categories: >>> 1) Sandbox: crazy ideas or something that don't have consensus yet in the >>> community (You can do whatever you want here :-) >> +1 >>> 2) Trunk/contrib: experimental features that are not ready to be included in >>> the next release >>> a) If the code can be built, the module should be included in the main >>> build >> +1 at the discretion of those working on the module. I.e. if it builds >> but you want to exclude it then no problem. >>> b) if the code cannot be built, the module won't be included in the >>> main build >> +1 >>> 3) Trunk/modules: stable features that are ready for the next release >> +1 >>> Developers can adjust things between 2.a and 2.b. >> +1 >>> We should promote things >>> from 2 into 3 when the features are ready. >> What does "we" mean here. Presumably developers working on modules can >> do this when they feel ready. >>> We should always try to ensure the features included in the build passing no >>> matter if they are from "contrib" (2.a) or "modules" (3). The default maven >>> build profile should include both "contrib" and "modules". The release >>> profile will exclude "contrib". When we cut a release, the "contrib" will be >>> excluded from the distro. >> +1 >>> Mostly, I prefer to have a "SOFT" separation between the experimental and >>> ready-for-release features. >> Me too.This kind of approach at least gives the developer the ability >> to develop in the trunk while giving the RM a clear steer on what is >> in the distro. >>> Sent from my iPhone >>> On Jun 30, 2010, at 10:47 AM, Simon Laws <[email protected]> wrote: >>> >> Simon >
