On 9 April 2012 18:03, Raminderjeet Singh <[email protected]> wrote:
> Thanks Jasha. I appended CHANGELOG file with Jira's from 0.10.1 and 0.10. > > Another thing to careful about release is you may face a failure while > release (like i faced out of memory even MAVEN_OPTS). Please follow > http://rave.apache.org/release-process.html RECOVERING FROM A VETOED > RELEASE and delete the tag. > Did you get the OOM when doing release:prepare or release:perform? If it happens during release:perform there's no need to delete the tag in svn. release:prepare creates the tag, release:perform makes the artifacts from that tag. > > > On Apr 9, 2012, at 11:39 AM, Jasha Joachimsthal wrote: > > > On 9 April 2012 17:24, Franklin, Matthew B. <[email protected]> wrote: > > > >> On 4/9/12 11:10 AM, "Jasha Joachimsthal" <[email protected]> > >> wrote: > >> > >>> On 9 April 2012 15:51, Franklin, Matthew B. <[email protected]> > wrote: > >>> > >>>> > >>>> On 4/9/12 9:46 AM, "Raminderjeet Singh" <[email protected]> > >>>> wrote: > >>>> > >>>>> As the fix is already part of trunk and we did not create any branch > so > >>>>> what should i do to create build. Shall i create a tag 0.10.1 from > >>>> trunk > >>>>> and create the release. As the trunk pom's are already at > >>>> 0.11-snaphot, i > >>>>> need to careful not to update them again i release process. > >>>> > >>>> Since the fix is in place in trunk, IMO we no longer need to branch. > >>>> You > >>>> could release 0.10.1 right now out of trunk without any need to change > >>>> poms. Just make sure you set the development version to 0.11-SNAPSHOT > >>>> when prompted by the release plugin... > >>>> > >>> > >>> Should we create a 0.10.1 version in Jira as well? > >> > >> +1 > >> > > > > Created and added it as fix version for RAVE-541, RAVE-542 and RAVE-553. > > > > > >> > >>> > >>> > >>>> > >>>>> > >>>>> > >>>>> Thanks > >>>>> Raminder > >>>>> > >>>>> > >>>>> On Apr 9, 2012, at 6:46 AM, Jasha Joachimsthal wrote: > >>>>> > >>>>>> Tested the portal and it works again. Thanks for fixing it. > >>>>>> > >>>>>> > >>>>>> On 6 April 2012 20:37, Mahadevan, Venkat <[email protected]> wrote: > >>>>>> > >>>>>>> Fixed the issue. Please let me know otherwise. > >>>>>>> > >>>>>>> > >>>>>>> Venkat > >>>>>>> > >>>>>>> > >>>>>>> On 4/6/12 9:19 AM, "Mahadevan, Venkat" <[email protected]> wrote: > >>>>>>> > >>>>>>>> Jasha, I will work on RAVE-541 and fix the issue > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 4/6/12 6:26 AM, "Jasha Joachimsthal" > >>>> <[email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> On 6 April 2012 10:46, Ate Douma <[email protected]> wrote: > >>>>>>>>> > >>>>>>>>>> On 04/06/2012 10:41 AM, Ate Douma wrote: > >>>>>>>>>> > >>>>>>>>>>> I've got two remarks so far: > >>>>>>>>>>> > >>>>>>>>>>> a) This release candidate is dependent on the non-yet released > >>>>>>>>>>> rave-master-0.10, > >>>>>>>>>>> which I don't like much. > >>>>>>>>>>> > >>>>>>>>>>> IMO it would have been better to wait another day until the > >>>>>>>>>>> rave-master > >>>>>>>>>>> was > >>>>>>>>>>> formally released. Although the rave-master release most > >>>> certainly > >>>>>>>>>>> will > >>>>>>>>>>> commence, in theory if we find a last minute blocker issue with > >>>> it > >>>>>>>>>>> causing its > >>>>>>>>>>> release to be failed, it would cause *this* release candidate > >>>> then > >>>>>>>>>>> to > >>>>>>>>>>> fail > >>>>>>>>>>> automatically as well... > >>>>>>>>>>> > >>>>>>>>>>> b) Issue RAVE-553 just reported by Jasha and also confirmed by > >>>>>>>>>>> myself > >>>>>>>>>>> makes the > >>>>>>>>>>> release useless for all practical use-cases and most certainly > >>>>>>>>>>> should > >>>>>>>>>>> have been > >>>>>>>>>>> easily tested/found before the release. We should look into > >>>>>>>>>>> improving > >>>>>>>>>>> our > >>>>>>>>>>> quality assurance and add some minimal but sensible > >>>> (interaction) > >>>>>>>>>>> testing > >>>>>>>>>>> plan > >>>>>>>>>>> which should pass before we cut a release candidate because > >>>> this is > >>>>>>>>>>> quite > >>>>>>>>>>> annoying. > >>>>>>>>>>> > >>>>>>>>>>> For b) I'm inclined to vote -1 or at least -0. As I haven't had > >>>>>>>>>>> time > >>>>>>>>>>> to > >>>>>>>>>>> further > >>>>>>>>>>> review I'll postpone casting my vote for now but it doesn't > look > >>>>>>>>>>> rosy > >>>>>>>>>>> to > >>>>>>>>>>> me. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> BTW: just want to make clear, especially for Raminder, I > >>>> consider b) > >>>>>>>>>> and > >>>>>>>>>> the need for improving on our quality assurance a responsibility > >>>> of > >>>>>>>>>> the > >>>>>>>>>> team, including myself, not one of the release-manager who but > >>>> must > >>>>>>>>>> execute > >>>>>>>>>> and ascertain this. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> If I revert the commit in > >>>>>>>>> https://issues.apache.org/jira/browse/RAVE-541 > >>>>>>>>> I > >>>>>>>>> can create new users again. I don't know what the intention of > >>>> this > >>>>>>>>> feature > >>>>>>>>> was, but the result is that it creates a new PROFILE page instead > >>>> of > >>>>>>>>> a > >>>>>>>>> new > >>>>>>>>> USER page. The portal cannot handle a user without a user page. > >>>> The > >>>>>>>>> portal > >>>>>>>>> can however render a profile page if no profile page is present > >>>> yet > >>>>>>>>> for > >>>>>>>>> that user. > >>>>>>>>> > >>>>>>>>> We have multiple options: > >>>>>>>>> 0. accept the 0.10 release, but I also doubt between -0 and -1 > >>>>>>>>> 1. reject the 0.10 release, fix or revert the issue, no new > >>>> release > >>>>>>>>> until > >>>>>>>>> the end of the month > >>>>>>>>> 2. reject the 0.10 release, revert the commit done for RAVE-541 > >>>> and > >>>>>>>>> create > >>>>>>>>> a new 0.10.1 release after the rave-master pom has been released > >>>>>>>>> 3. reject the 0.10 release, fix the RAVE-541 issue and create a > >>>> new > >>>>>>>>> 0.10.1 > >>>>>>>>> release after the rave-master pom has been released > >>>>>>>>> > >>>>>>>>> For option 2 & 3 we don't want other new features in the 0.10.1 > >>>>>>>>> release > >>>>>>>>> so > >>>>>>>>> either > >>>>>>>>> a. hold all commits until the issue RAVE-541 has been resolved or > >>>>>>>>> reverted. > >>>>>>>>> Create a release from trunk (0.11-SNAPSHOT -> 0.10.1 -> > >>>>>>>>> 0.11-SNAPSHOT) > >>>>>>>>> b. create a branch from 0.10 tag (0.10.1-SNAPSHOT), fix or revert > >>>>>>>>> RAVE-541, > >>>>>>>>> release from the branch (0.10.1-SNAPSHOT -> 0.10.1 -> > >>>>>>>>> 0.10.2-SNAPSHOT). > >>>>>>>>> Merge the fix into trunk (0.11-SNAPSHOT) > >>>>>>>>> > >>>>>>>>> @Venkat (or whoever can fix the issue and knows what the > intention > >>>>>>>>> was): > >>>>>>>>> in > >>>>>>>>> case we want a 0.10.1 release, do you think you can fix this > issue > >>>>>>>>> soon, > >>>>>>>>> shall we first revert your commit and give you more time to solve > >>>> it? > >>>>>>>>> > >>>>>>>>> Jasha > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Ate > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 04/06/2012 02:51 AM, Raminderjeet Singh wrote: > >>>>>>>>>>> > >>>>>>>>>>>> This is discussion thread for vote on Apache Rave Project 0.10 > >>>>>>>>>>>> Release > >>>>>>>>>>>> Candidate > >>>>>>>>>>>> > >>>>>>>>>>>> For more information on the release process, checkout - > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> http://rave.apache.org/**release-management.html< > >>>>>>> http://rave.apache.or > >>>>>>>>>>>> g > >>>>>>>>>>>> /release-management.html> > >>>>>>>>>>>> > >>>>>>>>>>>> Some of the things to check before voting are: > >>>>>>>>>>>> - can you run the demo binaries > >>>>>>>>>>>> - can you build the contents of source-release.zip and svn tag > >>>>>>>>>>>> - do all of the staged jars/zips contain the required LICENSE, > >>>>>>>>>>>> NOTICE > >>>>>>>>>>>> and > >>>>>>>>>>>> DISCLAIMER files > >>>>>>>>>>>> - are all of the staged jars signed and the signature > >>>> verifiable > >>>>>>>>>>>> - is the signing key in the project's KEYS file and on a > public > >>>>>>>>>>>> server > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>> > >> > >> > >
