On Wed, Jun 1, 2011 at 2:17 AM, sebb <[email protected]> wrote: > On 1 June 2011 00:49, Emmanuel Lecharny <[email protected]> wrote: >> On 6/1/11 1:39 AM, sebb wrote: >>> >>> On 1 June 2011 00:24, Emmanuel Lecharny<[email protected]> wrote: >>>> >>>> On 5/31/11 7:31 PM, sebb wrote: >>>>> >>>>> On 30 May 2011 09:21, Julien Vermillard<[email protected]> wrote: >>>>>> >>>>>> This is a bug fix release. >>>>>> >>>>>> Fixed issues : >>>>>> >>>>>> https://issues.apache.org/jira/browse/DIRMINA-832 >>>>>> NullPointerException logged by ExceptionMonitor while invoking a >>>>>> NioSocketConnector.connect() that fails >>>>>> >>>>>> https://issues.apache.org/jira/browse/DIRMINA-830 >>>>>> DIRMINA-830 Unconditional wait() in Read- and WriteWorker of >>>>>> SerialSessionImpl >>>>>> >>>>>> A temporary tag has been created (it can be removed if the vote is not >>>>>> approved): http://svn.apache.org/viewvc/mina/tags/2.0.4/ >>>>> >>>>> Maybe next time consider creating an RC1 tag. >>>> >>>> It's not necessary, as we are just fixing bugs in such versions. >>> >>> Does not matter if you are only correcting a typo; it's important that >>> what is being voted on is uniquely identified. >>> >>> IMO, tags should be immutable. Much simpler in the long run. >> >> They are. if we can't vote a tag, then it's deleted, until we can get a >> positive vote. >> >> But I see where you are heading to. > > If a tag is deleted and later recreated, then by definition it's not > immutable. > >> This can be discussed. > > So long as the tag is uniquely identified it's OK by me. > > That means providing either: > - immutable tag (revision is optional) > - mutable tag with revision > >>>>> If the vote does not succeed, create a new tag (RC2) and repeat. >>>>> If the vote succeeds, rename the RCn tag as the release tag. >>>>> That way, the release tag is immutable. >>>>> Failed RCn tags can be removed after the voting has finished. >>>>> >>>>> If release tags can be deleted and re-created, how can one know which >>>>> version of the tag was reviewed? >>>> >>>> because we provide the svn revision number. Hmmm, has it been provided ? >>>> if >>>> not, that's a mistake. >>> >>> AFAICT it has not been provided. >> >> bad... > > It's not too late to provide one. > >> Frankly, I do think now that it may be better to stop the vote and fix some >> of the issues we have (the latest you created, plus a new one). > > The SVN properties are not a blocker, but should be fixed before > creating a new release candidate. > >> We can then start a discussion about the best way to vote a dedicated >> version, before moving it to an immutable tag. >> >> Let's see what Julien will say...
Let's cancel the vote and provide an SVN revision next time (my bad). Julien
