I created the samples and modules directory under contrib, as I have need for the samples directory and it's clear from this thread that we have consensus on needing a samples and a modules directory. I only found one reference to having the tests folder under contrib, so I refrained from adding that at the moment, a small point but I thought I'd just check that's whats wanted before going ahead and doing it.
Kelvin. On Thu, Jul 1, 2010 at 3:46 PM, Raymond Feng <[email protected]> wrote: > +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 >> >
