On Fri, Jun 8, 2012 at 6:43 PM, sebb <[email protected]> wrote: > On 8 June 2012 17:23, Guillaume Nodet <[email protected]> wrote: >> On Fri, Jun 8, 2012 at 6:09 PM, sebb <[email protected]> wrote: >>> On 8 June 2012 17:00, Guillaume Nodet <[email protected]> wrote: >>>> On Fri, Jun 8, 2012 at 5:48 PM, sebb <[email protected]> wrote: >>>>> On 8 June 2012 10:37, Guillaume Nodet <[email protected]> wrote: >>>>>> On Fri, Jun 8, 2012 at 11:25 AM, sebb <[email protected]> wrote: >>>>>>> On 7 June 2012 16:10, Guillaume Nodet <[email protected]> wrote: >>>>>>>> I've uploaded a release at >>>>>>>> https://repository.apache.org/content/repositories/orgapachemina-201/ >>>>>>>> >>>>>>>> The release notes are available at >>>>>>>> >>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310849&version=12317953 >>>>>>>> >>>>>>>> The vote will be opened for at least 72 hours. Please review and vote. >>>>>>> >>>>>>> Where is the SVN tag? >>>>>> >>>>>> http://svn.apache.org/repos/asf/mina/sshd/tags/sshd-0.7.0/ >>>>> >>>>> Ideally that should have an RC suffix in case the RC fails and has to be >>>>> redone. >>>>> Otherwise the tag is not immutable. >>>>> >>>> >>>> That's up to the project to decide. Over the 6 releases I've done on >>>> sshd, this had not happened. >>> >>> In that case, it's best to include the tag and revision in RC votes. >>> Otherwise one cannot trace provenance easily. >>> >>>> When it did happened in mina was mostly pre-major releases. SSHD is >>>> still in < 1.0 and I don't think we need to cut RC for minor releases. >>>> Immutable tags means no one should ever change those. But that's only >>>> true after the release has been voted. >>>> At least, that's what I've seen on the number of releases I did or >>>> voted on at the ASF over the 10 projects and last 7 years. >>>> And in all cases, each PMC has its own rules, and it does not seem to >>>> be the case here. >>>> >>>> Also, when using maven, you can't just rename a version. It just does >>>> not work for several reasons, one of them being that the version is >>>> actually inside the jars at several places. >>> >>> It's perfectly possible to use RCn suffices with Maven projects. >>> Commons (and HttpComponents) do that all the time. >> >> I didn't say it's not possible, but you can't just rename the jars, > > No need to rename the jar. > The jar does not need to have the RC suffix, just the tag. >
Well we release like that since year in MINA, I don't think a tag RC prefix worth a veto. You plan to remove your veto if the NOTICE file and the licence header are fixed ? >> you'll have to the release again when you want to get rid of the >> So I don't really see the benefit since you have to two at least 2 >> releases each time. >> Usually, when a release fail (such as this one, as I need to cancel it >> to add the missing headers), I delete the tag, drop the staging repo, >> and try again. > >>> >>>>>>> >>>>>>> KEYS file? >>>>>> >>>>>> http://svn.apache.org/repos/asf/mina/KEYS >>>>>> >>>>>>> >>>>>>> -1 >>>>>>> >>>>>>> The NOTICE file in the source archive references code that is not >>>>>>> actually included. >>>>>> >>>>>> Those are notices on the main dependencies, especially those inside >>>>>> the binary distribution. This is slightly over protective, but erring >>>>>> on the good side is better. >>>>> >>>>> It's not good to claim that a release contains code when it does not. >>>>> >>>>> The NOTICE file is for *required* notices only. >>>>> The dependency entries are obviously not required if they are not present. >>>>> >>>>> The contents of NOTICE files are generally transitive, so it's vital >>>>> that they are accurate. >>>> >>>> >>>> Yeah, that's not ideal I agree, but I'm not even sure how easily we >>>> can change that atm. >>>> I mean both distributions are generated in the same maven project and >>>> they do use the same input afaik.
