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> 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> 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
| | >>
| | >> 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
| | >>
| | >> You can reach the person managing the list at
| | >> dna-dev-owner(a)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>
| | >> Subject: [dna-dev] Proposal: new sandbox area for DNA
| | >> To: JBoss DNA <dna-dev(a)lists.jboss.org>
| | >> Message-ID: <00474E51-4FBF-4957-937B-B6B8AE4194CD(a)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
| | >> -------------- next part --------------
| | >> An HTML attachment was scrubbed...
| | >> URL:
http://lists.jboss.org/pipermail/dna-dev/attachments/20081123/20577752/at...
| | >>
| | >> ------------------------------
| | >>
| | >> _______________________________________________
| | >> dna-dev mailing list
| | >> dna-dev(a)lists.jboss.org
| | >>
https://lists.jboss.org/mailman/listinfo/dna-dev
| | >>
| | >>
| | >> End of dna-dev Digest, Vol 8, Issue 17
| | >> **************************************
| | >>
| | >
| | > _______________________________________________
| | > dna-dev mailing list
| | > dna-dev(a)lists.jboss.org
| | >
https://lists.jboss.org/mailman/listinfo/dna-dev
| |
| | _______________________________________________
| | dna-dev mailing list
| | dna-dev(a)lists.jboss.org
| |
https://lists.jboss.org/mailman/listinfo/dna-dev
| |
|
| _______________________________________________ dna-dev mailing
list dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev