<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>As long as we're thinking that fluidly, then no problem.<br><br>John Verhaeg<br>Red Hat, Inc.<br>(314) 336-2950<br><br>----- "Randall Hauch" <rhauch@redhat.com> wrote:
<br>| <link href="/zimbra/css/msgview.css?v=080814121557" rel="stylesheet"><div>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?</div><div><br>| </div><div>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.</div><div><br>| </div><div>Best regards,</div><div><br>| </div><div>Randall</div><br>| <div><div>On Dec 2, 2008, at 12:47 PM, John Verhaeg wrote:</div><br class="Apple-interchange-newline"><blockquote><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><div><div style="font-family: 'Times New Roman'; font-size: 12pt; color: rgb(0, 0, 0);">| 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.<br>| <br>| John Verhaeg<br>| Red Hat, Inc.<br>| (314) 336-2950<br>| <br>| ----- "Randall Hauch" <<a href="mailto:rhauch@redhat.com" target="_blank">rhauch@redhat.com</a>> wrote:<span class="Apple-converted-space"> </span><br>| | 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.<div><br>| |</div><div>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.<br>| |<div><div><div><br>| |<div><div>On Dec 2, 2008, at 11:02 AM, John Verhaeg wrote:</div><br class="Apple-interchange-newline"><blockquote><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><div><div style="font-family: 'Times New Roman'; font-size: 12pt; color: rgb(0, 0, 0);">| | 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?<br>| |<span class="Apple-converted-space"> </span><br>| | John Verhaeg<br>| | Red Hat, Inc.<br>| | (314) 336-2950<br>| |<span class="Apple-converted-space"> </span><br>| | ----- "Randall Hauch" <<a href="mailto:rhauch@redhat.com" target="_blank">rhauch@redhat.com</a>> wrote:<span class="Apple-converted-space"> </span><br>| | | Any other comments? If not, I'll go ahead and create an issue to make <br>| | | this change at the end of the release.<br>| | |<span class="Apple-converted-space"> </span><br>| | | On Nov 25, 2008, at 4:35 PM, Serge Emmanuel Pagop wrote:<br>| | |<span class="Apple-converted-space"> </span><br>| | | > Hi all,<br>| | | ><br>| | | > I agree with that proposal with the sandbox area, then dna should be <br>| | | > release with the most stable subprojects and definition of stable <br>| | | > can only be define by the project leader depend on with features the <br>| | | > subproject has to at the least provide.<br>| | | > For me because of the youthfulness of DNA project, we can also <br>| | | > release all subproject, that provide a minimun upon functionalities, <br>| | | > so that we can win some contributors in the community. Of Course "a <br>| | | > minimun upon functionalities" has also to be defined.<br>| | | ><br>| | | > Best regards,<br>| | | > Serge.<br>| | | ><br>| | | >> Send dna-dev mailing list submissions to<br>| | | >> <a href="mailto:dna-dev@lists.jboss.org" target="_blank">dna-dev@lists.jboss.org</a><br>| | | >><br>| | | >> To subscribe or unsubscribe via the World Wide Web, visit<br>| | | >> <a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>| | | >> or, via email, send a message with subject or body 'help' to<br>| | | >> <a href="mailto:dna-dev-request@lists.jboss.org" target="_blank">dna-dev-request@lists.jboss.org</a><br>| | | >><br>| | | >> You can reach the person managing the list at<br>| | | >> <a href="mailto:dna-dev-owner@lists.jboss.org" target="_blank">dna-dev-owner@lists.jboss.org</a><br>| | | >><br>| | | >> When replying, please edit your Subject line so it is more specific<br>| | | >> than "Re: Contents of dna-dev digest..."<br>| | | >><br>| | | >><br>| | | >> Today's Topics:<br>| | | >><br>| | | >> 1. Proposal: new sandbox area for DNA (Randall Hauch)<br>| | | >><br>| | | >><br>| | | >> ----------------------------------------------------------------------<br>| | | >><br>| | | >> Message: 1<br>| | | >> Date: Sun, 23 Nov 2008 11:47:08 -0600<br>| | | >> From: Randall Hauch <<a href="mailto:rhauch@redhat.com" target="_blank">rhauch@redhat.com</a>><br>| | | >> Subject: [dna-dev] Proposal: new sandbox area for DNA<br>| | | >> To: JBoss DNA <<a href="mailto:dna-dev@lists.jboss.org" target="_blank">dna-dev@lists.jboss.org</a>><br>| | | >> Message-ID: <<a href="mailto:00474E51-4FBF-4957-937B-B6B8AE4194CD@redhat.com" target="_blank">00474E51-4FBF-4957-937B-B6B8AE4194CD@redhat.com</a>><br>| | | >> Content-Type: text/plain; charset="us-ascii"<br>| | | >><br>| | | >> I've been wondering recently how to distinguish the (Maven)<br>| | | >> subprojects under trunk that are ready for use vs. those that are<br>| | | >> still under development. In fact, it's not even only the source<br>| | | >> organization, as our release binaries have included all projects<br>| | | >> (regardless of their state). I've tried to note the status in the<br>| | | >> documentation, but I think that is insufficient and we need something<br>| | | >> that is more formal, obvious, and intuitive for users.<br>| | | >><br>| | | >> The 0.3 release included several projects that were not really "ready<br>| | | >> for use":<br>| | | >> dna-sequencer-cnd<br>| | | >> dna-sequencer-esbMessage<br>| | | >> dna-sequencer-jbpm-jpdl<br>| | | >> dna-connector-svn<br>| | | >><br>| | | >> And since the 0.3 release we have started (or will so be starting)<br>| | | >> several new subprojects:<br>| | | >> dna-connector-store-jpa<br>| | | >> dna-connector-jdbc-metadata (soon to be created)<br>| | | >><br>| | | >> So, here's my proposal: we'd create in SVN a new "sandbox" directory<br>| | | >> under the "trunk" directory, and in this area is generally where<br>| | | >> subprojects would live until they are "mature enough" to move outside<br>| | | >> of the "sandbox". In some cases, "mature enough" means that they are<br>| | | >> indeed complete, while in other cases they may be far enough along <br>| | | >> and<br>| | | >> there's commitment to finish them before the next release. I'd<br>| | | >> anticipate that we'd be flexible on what "mature enough" means and<br>| | | >> decide on a case-by-case basis as a community when a sandbox project<br>| | | >> is "mature enough" on a case-by-case basis (although ultimately the<br>| | | >> project lead would have the final say). However, sandbox projects<br>| | | >> would be excluded from the binary release assembly (but maybe <br>| | | >> included<br>| | | >> in the source assembly?) and would not be mentioned in the Getting<br>| | | >> Started document, and all mentions in the Reference Guide would be<br>| | | >> moved to a new chapter covering the sandbox.<br>| | | >><br>| | | >> Also, with this proposal, I'd think we would still keep all of the<br>| | | >> sandbox projects in our development environments (unless other wise<br>| | | >> requested by a project's developers). And these sandbox projects<br>| | | >> would still included in the Maven builds and Hudson CI jobs.<br>| | | >><br>| | | >> Here's a strawman list of existing extensions that could be moved <br>| | | >> into<br>| | | >> the "sandbox", based purely upon my understanding of where these<br>| | | >> projects are and the plans to complete them by 0.4:<br>| | | >> dna-classloader-maven (complete, but to be of any use it really needs<br>| | | >> additional components, like perhaps a Maven or SVN connector)<br>| | | >> dna-sequencer-cnd<br>| | | >> dna-sequencer-esbMessage<br>| | | >> dna-sequencer-jbpm-jpdl<br>| | | >> dna-connector-jdbc-metadata (soon to be created)<br>| | | >> dna-sequencer-jdbc-metadata (actually, this is to be removed)<br>| | | >><br>| | | >> These projects would stay in "trunk", since they are planned to be<br>| | | >> completed for 0.4:<br>| | | >> dna-connector-svn<br>| | | >> dna-connector-store-jpa<br>| | | >><br>| | | >> Forgive me if my understanding of the state of these projects is<br>| | | >> wrong. If that's the case, please speak up and correct me.<br>| | | >><br>| | | >> So, what do you think of this proposal? Please weigh in with your<br>| | | >> thoughts and opinions about the proposal and the suggested list of<br>| | | >> "sandbox" subprojects.<br>| | | >><br>| | | >><br>| | | >> Best regards,<br>| | | >><br>| | | >> Randall<br>| | | >> -------------- next part --------------<br>| | | >> An HTML attachment was scrubbed...<br>| | | >> URL:<span class="Apple-converted-space"> </span><a href="http://lists.jboss.org/pipermail/dna-dev/attachments/20081123/20577752/attachment-0001.html" target="_blank">http://lists.jboss.org/pipermail/dna-dev/attachments/20081123/20577752/attachment-0001.html</a><br>| | | >><br>| | | >> ------------------------------<br>| | | >><br>| | | >> _______________________________________________<br>| | | >> dna-dev mailing list<br>| | | >><span class="Apple-converted-space"> </span><a href="mailto:dna-dev@lists.jboss.org" target="_blank">dna-dev@lists.jboss.org</a><br>| | | >><span class="Apple-converted-space"> </span><a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>| | | >><br>| | | >><br>| | | >> End of dna-dev Digest, Vol 8, Issue 17<br>| | | >> **************************************<br>| | | >><br>| | | ><br>| | | > _______________________________________________<br>| | | > dna-dev mailing list<br>| | | ><span class="Apple-converted-space"> </span><a href="mailto:dna-dev@lists.jboss.org" target="_blank">dna-dev@lists.jboss.org</a><br>| | | ><span class="Apple-converted-space"> </span><a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>| | |<span class="Apple-converted-space"> </span><br>| | | _______________________________________________<br>| | | dna-dev mailing list<br>| | |<span class="Apple-converted-space"> </span><a href="mailto:dna-dev@lists.jboss.org" target="_blank">dna-dev@lists.jboss.org</a><br>| | |<span class="Apple-converted-space"> </span><a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a><br>| | |</div></div></span></blockquote></div><br>| |</div></div></div></div><br>| | _______________________________________________ dna-dev mailing list<span class="Apple-converted-space"> </span><a href="mailto:dna-dev@lists.jboss.org" target="_blank">dna-dev@lists.jboss.org</a><span class="Apple-converted-space"> </span><a href="https://lists.jboss.org/mailman/listinfo/dna-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/dna-dev</a></div></div></span></blockquote></div><br>| </div></body></html>