> -----Original Message-----
> From: Simon Kitching [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 30, 2005 7:54 PM
> To: Jakarta Commons Developers List
> Subject: Re: Removing Graduated Components from trunks-sandbox
>
> On Sun, 2005-01-30 at 15:10 -0500, Tim O'Brien wrote:
> > I agree with this commit.
> >
> > I think once a component has graduated it should no longer
> be a part
> > of the sandbox, but we might need to make some exceptions
> for things
> > like CLI. I believe CLI2 was developed in the sandbox
> eventhough CLI
> > was in proper.
> >
> > Anyone else have any strong feelings here?
> >
> > Someone had mentioned that it would be valuable to preserve
> history by
> > copying sandbox tags and branches to an "archives"
> directory for each
> > component at the same level as branches and tags? Anyone?
>
> Hmm.. you are proposing that when something gets promoted
> from sandbox, that the original sandbox code for {project}
> should be moved into this dir?
> commons/proper/{project}/archives
>
> Well, I do agree that code that has been promoted from
> sandbox should be removed from the sandbox, leaving the
> sandbox with only "active"
> projects. However I can't see what else would ever live in
> that "archives" directory; if there is to be a directory
> whose only contents will be the old sandbox stuff (including
> its own tags, branches, etc), then perhaps
> "commons/proper/{project}/sandbox-promoted" might be a better
> name than 'archive'?
>
I'd imagine that a promotion from sandbox to proper would be
accomplished with an svn mv (component "disappears" from sandbox,
history moves to proper). History from the sandbox is preserved in this
case, trunks, tags, and branches. I think what we're trying to find an
answer for what happens to the components currently in the sandbox - for
promotions that happened prior to the SVN migration,
"commons/proper/{project}/sandbox-promoted" sounds like a good solution.
> Alternatively, archives of promoted stuff could be stored
> externally to the related projects, eg
> "commons/sandbox-promoted/{project}" or
> "commons/sandbox/promoted/{project}.
I'd be -0.50 to creating another sibling to "sandbox" or "proper".
Because I'm assuming all new promotions would happen with an svn mv.
>
> If a sandbox project should be declared "dead", then I think
> it also should be moved, to commons/sandbox-dormant (or
> commons/sandbox/dormant) or similar. Given this, it might
> make more sense to put promoted projects in
> "commons/sandbox-promoted/{project}" than to put them under
> the standard project dir.
I'm for "commons/sandbox/dormant" - some dormant projects have been
revived and have proven useful, but I also think that it is wise to
differentiate between projects actively in the sandbox and projects
suffering from persistent lack of interest. Maybe now that it is so
much easier to just move stuff around we could formalize this with
something like: sandbox projects lacking sufficient interest may be
moved to a dormant directory "commons/sandbox/dormant" (not linked from
trunks-sandbox). Projects in "commons/sandbox/dormant" showing a
persistence lack of interest will be "svn rm" after n months.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
