At this point, I am not really sure. We can always easily move them around.
If you have or can envision a lot of CLI tests, we can create a separate testsuite for it. This separate testsuite won't have to start/stop selenium server too since it is cmdline. If you want to drop it under deployment-testsuite for now, that's fine too. Cheers Prasad On 8/14/07, Donald Woods <[EMAIL PROTECTED]> wrote: > > Where were you thinking? Should we start a new subdirectory for cmdline > tests? Or could it go under deployment-testsuite? > > -Donald > > > Prasad Kashyap wrote: > > Good catch Donald. Can you please throw in a small test(s) in our > > testsuite framework so that we can catch things like this ? There are > > a lot of tests there already that can act as a template/example and > > help you with your testcase. > > > > Let me know if you need more help. > > > > Cheers > > Prasad > > > > On 8/13/07, Donald Woods <[EMAIL PROTECTED]> wrote: > >> > >> Matt Hogstrom wrote: > >>> All, > >>> > >>> Earlier today one of the Geronimo committers discovered a bug in the > >>> command line deployer where a null user / password on the deployer > >>> command line will allow a user to deploy modules to a 2.0 server. This > >>> is an unacceptable security exposure and as such we have abandoned the > >>> release of Geronimo 2.0. > >>> > >>> Donald Woods is going to open a JIRA for this issue and Hernan will > >>> create a news item on our web page. > >> GERONIMO-3404 was opened for this. > >> > >>> At this point we need to discuss how to move forward with a 2.0 release. > >>> > >>> I think we should delete the tags/2.0.0 entry and replace it with a text > >>> file that notes the svn rev of the tree before deletion. The purpose of > >>> this is to avoid anyone from picking up that source tree and using it to > >>> build a server with a known security exposure. Unless there is > >>> disagreement I'd like to do that tomorrow allowing some time for > >>> discussion. We can always put it back. > >>> > >>> There are several options for the 2.0 release: > >>> > >>> 1. Use the branches/2.0 to spin up a new release as 2.0.1. > >>> If we do this there are a number of fixes that need to be verified, > >>> We'd need to close out the SNAPSHOT releases again, or at least revisit > >>> them. > >>> Respin and re-tck a new release. > >>> > >>> 2. Take the tags/2.0.0 to create a branches/2.0.1 > >>> This would mean that we need to update branches/2.0 to 2.0.2-SNAPSHOT > >>> Copy the existing tag over and apply the security fixes. Repsin and > >>> release. > >>> > >>> Personally, I vote for option 2. Based on my experience, closing out > >>> the SNAPSHOTs is and introducing little changes will cause us to restart > >>> the release process. > >> +1 on option #2. > >> > >> > >>> I'd like to hear other people's input but having done the release > >>> several times option 2 is the fastest. I think option 1 will cause us > >>> to not release until September. > >>> > >>> > >> > > > > > >
