Quoting Henri Yandell <[EMAIL PROTECTED]>: > On Thu, 27 Jan 2005 23:31:04 -0500, Tim O'Brien <[EMAIL PROTECTED]> > 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: scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/${pom.artifactId.substring(8)}/trunk (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? +1 > > > > 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. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
