commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [all] svn stuff to do and discuss
Date Fri, 28 Jan 2005 05:10:16 GMT
Quoting Henri Yandell <>:

> On Thu, 27 Jan 2005 23:31:04 -0500, Tim O'Brien <>
> wrote:
> > Some of these things need volunteers, some need discussion:
> > 
> > 1. project.xml files need to be updated to reflect the fact that
> > repositories are in SVN.

I can probably get this done in time, but if someone else is able, please check
that the format is:
(https for developerConnection)

It might be worth sharing this in commons-build.

Anything referencing commons-build will need to change it's <extend/>.

It would be worth taking notes at this point on the things that require
referencing anything via ../../ as it is likely now broken from the introduction
of trunk. It would be worth trying to get rid of these to make each module build
on their own - Maven 1.1 will contain additional facilities to enable this.

> > 
> > 2. gump project descriptors need to be updated.

Luckily there are only 2 :)
I can do this, but not before the first build breaks.

> > 
> > 3. Should we svn rm components from the sandbox which have been
> > promoted?


> > 
> > 4. Should we svn rm components from the sandbox which have become
> > inactive?

-0. Define inactive? If redundant, then sure. If they are just inactive, I think
they should be there for someone to pick up later.

I think anything that is actually active should be considering promotion anyway.

> > 
> > 5. Does svn affect the way we build the commons site?

Probably because of the directory structure. I saw a "build all" script -
shouldn't the site generation be decoupled so you have a parent site, and then
build each component's site individually? I think this is actually how it works,
but I'm not really familiar.

> > 
> > 6. Much like we have a trunks-proper and trunks-sandbox, would it make
> > any sense to also have a released-proper?  Instead of pointing to trunk,
> > svn:externals in this directory would point to the current release tag
> > for each component?

-0. Sounds like a maintenance headache that causes more confusion when it is out
of date, and I can't think of a reason to use it off the top of my head.

> > 
> > 7. I believe jakarta-commons and jakarta-commons-sandbox had different
> > entries in the avail file.  Do we want one entry for /jakarta/commons?
> > (More subversive suggestion: Do we want one avail for /jakarta ;=>)
> Answering 7:
>     We have a policy of giving anyone at Jakarta/Apache access to
> sandbox, but not to proper. So a different avail makes sense there. We
> could improve things a touch I think by saying that all people with
> access to proper have access to sandbox, if I understand svn-auth
> syntax correctly.

Definitely possible to do it this way, but since there is a possibility for any
Apache committer to request access, why not just open it up to that to start
with and save the work later? I don't see much risk in this.

> 8. Documentation on how to manage trunks-proper/trunks-sandbox
> somewhere. It's one of those rare events that will become verbal
> folklore if we let it.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message