Yep, I’m trying to keep the branches more or less in sync. Roman made an earlier suggestion along these lines to always commit on develop and pull changes into the release branch. Once we agree on the specific changes to include in RC2 I’ll cherry-pick the commits.
Anthony > On Jan 26, 2016, at 10:51 AM, Nitin Lamba <[email protected]> wrote: > > Just noticed that three of the fixes related to LICENSE and NOTICE files have > been put in 'develop' branch so at the time of the next RC, they'll have to > be cherry-picked into the release ('1.0.0-incubating.M1' branch). > > Nitin > > ________________________________________ > From: Anilkumar Gingade <[email protected]> > Sent: Wednesday, January 20, 2016 3:04 PM > To: [email protected] > Subject: Re: [VOTE] Apache Geode (Incubating) first Milestone release - > v1.0.0-incubating.M1 > > Hi Nitin, > > Thanks for creating JIRA tickets capturing Niall's concerns/comments > regarding the RC candidate... > > (GEODE-815) RC Feedback: Fix LICENSE and NOTICE files > (GEODE-816) Source Distribution NOTICE needs updates > (GEODE-817) Binary distribution NOTICE needs update > (GEODE-818) RC Feedback: Fix Maven & pom dependencies > (GEODE-823) RC Feedback: Fix build artifacts > > -Anil. > > > > > > > > > > On Wed, Jan 20, 2016 at 1:45 PM, Nitin Lamba <[email protected]> wrote: > >> Sure. One benefit of defining subtasks is that subtasks have separate >> issue numbers for traceability, and we can track the complete feedback with >> a few JIRAs. Other mechanisms of using labels or explicit issue linking are >> additional steps with some overhead. >> >> Anyway, I've created a new version in JIRA, and created three issues >> capturing Niall's feedback [1]. If I interpret the feedback correctly, only >> the user PoV (pom dependencies) is optional; others are license-related and >> high priority to address. >> >> Best, >> Nitin >> [1] >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning >> ________________________________________ >> From: Anthony Baker <[email protected]> >> Sent: Wednesday, January 20, 2016 12:56 PM >> To: [email protected] >> Subject: Re: [VOTE] Apache Geode (Incubating) first Milestone release - >> v1.0.0-incubating.M1 >> >> I think it makes sense to capture the feedback as individual issues (and >> some have already been filed, e.g. GEODE-27 for pom correctness). Not all >> the comments are release blockers and thus can be addressed over time. >> Let’s wait for the discussion to complete so we can reach consensus around >> next steps. >> >> Anthony >> >>> On Jan 20, 2016, at 12:45 PM, Nitin Lamba <[email protected]> wrote: >>> >>> Sorry have been away from my e-mails. >>> >>> @Roman, Greg, Mike: Yes, first time miss. Didn't see a timing guideline >> but now we know! It makes sense to wait until Friday, and ask for 72 hrs on >> the next RC VOTE. >>> >>> @Niall: Thanks a lot for your feedback! NOTICE and LICENSE files was >> somewhat of a known issue given the first release (GEODE-610). Your e-mail >> capture the gaps well. We'll start working on it. >>> >>> @Anthony: we should capture the gaps on JIRA - I'll create a few >> top-level issues (Files, Build/ Gradle and Maven), and have the details >> captured as subtasks. Suggestions? >>> >>> Have a broader question: Given that most of the findings so far are >> related to license text/ config files not code or bugs, does it mean that >> we'll have another RC (#2) cut from the same (1.0.0-incubating.M1) branch? >> Will wait until end of the week to capture all the feedback. >>> >>> Thanks, >>> Nitin >>> >>> ________________________________________ >>> From: [email protected] <[email protected]> on behalf of Roman >> Shaposhnik <[email protected]> >>> Sent: Wednesday, January 20, 2016 11:13 AM >>> To: [email protected] >>> Subject: Re: [VOTE] Apache Geode (Incubating) first Milestone release - >> v1.0.0-incubating.M1 >>> >>> On Wed, Jan 20, 2016 at 9:23 AM, Michael Stolz <[email protected]> >> wrote: >>>> What caused it to have such a short deadline? Did we do something to >> cause >>>> it to be so short or is that the default and we just didn't know to >>>> override it somehow? >>> >>> That's a good question for a release manager. Nitin? >>> >>> Thanks, >>> Roman. >>> >>> P.S. If I were to make a guess I'd say this is just because everybody's >>> so excited to get the first set of bits out ;-)
signature.asc
Description: Message signed with OpenPGP using GPGMail
