IMHO, the real problem is not having the contrib folder inside trunk but the fact that we've got multiple folders named contrib which have different purposes. Making a clean separation between them more evident will reduce confusion (through means like for instance suggestive names) and misuse. After reading this thread, i'd rename the folder to something like "unreleased".
As a further clarification, is the trunk/contrib folder included in the Hudson build at the moment? The idea of the "trunk/contrib" folder looks really nice but for some reason it seems to have some flaws in the current format. As a conclusion, the contrib/, trunk/contrib and trunk simulate different types of environments during the code lifecycle (e.g. test/acceptance/production environments). Looking at it this way we can clearly see (from Simon Nash's scheme as well) that the second phase is considered as embedded in the 3rd one when in reality it is an independent phase... We're making this compromise just because trunk gets built automatically. Can't Hudson be set to build other things than trunk as well? Following the above logic, we might need to consider having an intermediary folder if we feel the need for such an environment. Something like: contrib/ modules/ samples/ ... unreleased/ (included in Hudson build) modules/ samples/ ... trunk/ (included in Hudson build) modules/ samples/ ... "unreleased" is not the best name but expresses the point until we find a better one :) On Sat, Oct 2, 2010 at 12:04 AM, Luciano Resende <[email protected]>wrote: > On Fri, Oct 1, 2010 at 6:42 AM, Simon Laws <[email protected]> > wrote: > > > > It's more convenient for me personally to have them under > > trunk/contrib which means that I can check trunk out and get the > > contrib stuff too. At the higher level I have to check two separate > > trees out or pull down all the tags and branches also. > > > > Simon > > +1, Having inside trunk/contrib is helpful, as you can easily get them > in Eclipse or Building in one shot; and as long as it's not part of > the release, it shouldn't be a big deal for others that are not > interested in them. > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
