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.org >>>>/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 >>>> >>>> >>>> >>>> >>> >>
