Re: [dna-dev] Re: Proposal: new sandbox area for DNA

An alternative, well it may be sligtly different thing, is to make a workspace area in svn where contributors put their work in progress and then they could merge/move it in trunk when it is mature. BTW It is the approach used in JBossESB. Bye S. Randall Hauch wrote on 02/12/08 20:48: > Well, I'm not sure my proposal is any different than what might be > even today (with regard to different branches). John, do you see a > difference? > > As for the long-term potential, I think as DNA matures, we'd move the > sandbox area completely out of trunk and letting the sandbox projects > each have their own life (perhaps with their own trunk/tags/branches). > If they mature into something useful, they can move officially into > DNA, or even into a separate project. If not, they remain in the sandbox. > > Best regards, > > Randall > > On Dec 2, 2008, at 12:47 PM, John Verhaeg wrote: > >> I'm not sure that answers my question. Why couldn't/shouldn't a >> project be allowed to exist in more than one branch while development >> is going on? It seems like this will be important the bigger a >> project gets. >> >> John Verhaeg >> Red Hat, Inc. >> (314) 336-2950 >> >> ----- "Randall Hauch" <rhauch(a)redhat.com <mailto:rhauch@redhat.com>> >> wrote: >> | A project either exists in the main area or in the sandbox, but not >> both. And since the "sandbox" is under "trunk" (at least for now), >> most of what we're doing stays the same (including the build process, >> our IDE workspaces, etc.). The only thing that changes that some of >> the projects would move to a different directory. >> >> | >> The main point is to segregate what's "ready" as part of the release >> vs. stuff that still isn't "ready" when a release is made. >> | >> >> | >> On Dec 2, 2008, at 11:02 AM, John Verhaeg wrote: >> >> | Wouldn't we potentially have multiple branches other than >> sandbox where ongoing work is contributed, including when >> contributors have overlapping changes in the same project? >> | >> | John Verhaeg >> | Red Hat, Inc. >> | (314) 336-2950 >> | >> | ----- "Randall Hauch" <rhauch(a)redhat.com >> <mailto:rhauch@redhat.com>> wrote: >> | | Any other comments? If not, I'll go ahead and create an >> issue to make >> | | this change at the end of the release. >> | | >> | | On Nov 25, 2008, at 4:35 PM, Serge Emmanuel Pagop wrote: >> | | >> | | > Hi all, >> | | > >> | | > I agree with that proposal with the sandbox area, then dna >> should be >> | | > release with the most stable subprojects and definition of >> stable >> | | > can only be define by the project leader depend on with >> features the >> | | > subproject has to at the least provide. >> | | > For me because of the youthfulness of DNA project, we can >> also >> | | > release all subproject, that provide a minimun upon >> functionalities, >> | | > so that we can win some contributors in the community. Of >> Course "a >> | | > minimun upon functionalities" has also to be defined. >> | | > >> | | > Best regards, >> | | > Serge. >> | | > >> | | >> Send dna-dev mailing list submissions to >> | | >> dna-dev(a)lists.jboss.org >> <mailto:dna-dev@lists.jboss.org> >> | | >> >> | | >> To subscribe or unsubscribe via the World Wide Web, visit >> | | >> https://lists.jboss.org/mailman/listinfo/dna-dev >> | | >> or, via email, send a message with subject or body 'help' to >> | | >> dna-dev-request(a)lists.jboss.org >> <mailto:dna-dev-request@lists.jboss.org> >> | | >> >> | | >> You can reach the person managing the list at >> | | >> dna-dev-owner(a)lists.jboss.org >> <mailto:dna-dev-owner@lists.jboss.org> >> | | >> >> | | >> When replying, please edit your Subject line so it is more >> specific >> | | >> than "Re: Contents of dna-dev digest..." >> | | >> >> | | >> >> | | >> Today's Topics: >> | | >> >> | | >> 1. Proposal: new sandbox area for DNA (Randall Hauch) >> | | >> >> | | >> >> | | >> >> ---------------------------------------------------------------------- >> | | >> >> | | >> Message: 1 >> | | >> Date: Sun, 23 Nov 2008 11:47:08 -0600 >> | | >> From: Randall Hauch <rhauch(a)redhat.com >> <mailto:rhauch@redhat.com>> >> | | >> Subject: [dna-dev] Proposal: new sandbox area for DNA >> | | >> To: JBoss DNA <dna-dev(a)lists.jboss.org >> <mailto:dna-dev@lists.jboss.org>> >> | | >> Message-ID: >> <00474E51-4FBF-4957-937B-B6B8AE4194CD(a)redhat.com >> <mailto:00474E51-4FBF-4957-937B-B6B8AE4194CD@redhat.com>> >> | | >> Content-Type: text/plain; charset="us-ascii" >> | | >> >> | | >> I've been wondering recently how to distinguish the (Maven) >> | | >> subprojects under trunk that are ready for use vs. those >> that are >> | | >> still under development. In fact, it's not even only the >> source >> | | >> organization, as our release binaries have included all >> projects >> | | >> (regardless of their state). I've tried to note the >> status in the >> | | >> documentation, but I think that is insufficient and we >> need something >> | | >> that is more formal, obvious, and intuitive for users. >> | | >> >> | | >> The 0.3 release included several projects that were not >> really "ready >> | | >> for use": >> | | >> dna-sequencer-cnd >> | | >> dna-sequencer-esbMessage >> | | >> dna-sequencer-jbpm-jpdl >> | | >> dna-connector-svn >> | | >> >> | | >> And since the 0.3 release we have started (or will so be >> starting) >> | | >> several new subprojects: >> | | >> dna-connector-store-jpa >> | | >> dna-connector-jdbc-metadata (soon to be created) >> | | >> >> | | >> So, here's my proposal: we'd create in SVN a new >> "sandbox" directory >> | | >> under the "trunk" directory, and in this area is generally >> where >> | | >> subprojects would live until they are "mature enough" to >> move outside >> | | >> of the "sandbox". In some cases, "mature enough" means >> that they are >> | | >> indeed complete, while in other cases they may be far >> enough along >> | | >> and >> | | >> there's commitment to finish them before the next release. >> I'd >> | | >> anticipate that we'd be flexible on what "mature enough" >> means and >> | | >> decide on a case-by-case basis as a community when a >> sandbox project >> | | >> is "mature enough" on a case-by-case basis (although >> ultimately the >> | | >> project lead would have the final say). However, sandbox >> projects >> | | >> would be excluded from the binary release assembly (but >> maybe >> | | >> included >> | | >> in the source assembly?) and would not be mentioned in the >> Getting >> | | >> Started document, and all mentions in the Reference Guide >> would be >> | | >> moved to a new chapter covering the sandbox. >> | | >> >> | | >> Also, with this proposal, I'd think we would still keep >> all of the >> | | >> sandbox projects in our development environments (unless >> other wise >> | | >> requested by a project's developers). And these sandbox >> projects >> | | >> would still included in the Maven builds and Hudson CI jobs. >> | | >> >> | | >> Here's a strawman list of existing extensions that could >> be moved >> | | >> into >> | | >> the "sandbox", based purely upon my understanding of where >> these >> | | >> projects are and the plans to complete them by 0.4: >> | | >> dna-classloader-maven (complete, but to be of any use it >> really needs >> | | >> additional components, like perhaps a Maven or SVN connector) >> | | >> dna-sequencer-cnd >> | | >> dna-sequencer-esbMessage >> | | >> dna-sequencer-jbpm-jpdl >> | | >> dna-connector-jdbc-metadata (soon to be created) >> | | >> dna-sequencer-jdbc-metadata (actually, this is to be removed) >> | | >> >> | | >> These projects would stay in "trunk", since they are >> planned to be >> | | >> completed for 0.4: >> | | >> dna-connector-svn >> | | >> dna-connector-store-jpa >> | | >> >> | | >> Forgive me if my understanding of the state of these >> projects is >> | | >> wrong. If that's the case, please speak up and correct me. >> | | >> >> | | >> So, what do you think of this proposal? Please weigh in >> with your >> | | >> thoughts and opinions about the proposal and the suggested >> list of >> | | >> "sandbox" subprojects. >> | | >> >> | | >> >> | | >> Best regards, >> | | >> >> | | >> Randall >> | | >>