> The mistake was to freeze the 6x branch in the first place. The release branch is the one which should be frozen.
I certainly agree with this. However, over a week ago there was a request to hold off on creating the 6_0 branch until Jenkins settled with a 6x. I received no push back on this suggestion so this was the plan that was executed (several days after that request was sent). > I specifically asked the RM to cut the branch to let others progress I received no replies -- which is why I was forced to do it myself. Your email was sent to me yesterday and I was on travel so didn't see it until today (right when the branch was created in fact). Because of time zones and other jobs I usually like to give people > 24 hours to reply. That being said, if the collective needs to move forward I'm certainly not insulted if someone else cuts a branch. I don't think any RM should be. > The rest of the problem was because I am new to Git I am not new to git so I had no problem creating the 6_0 branch, it just seems I didn't get online soon enough. I think Mike is suggesting, and I agree with this, there needs to be a reasonable amount of time given for someone to respond. - Nick On Thu, Mar 3, 2016 at 10:30 AM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > Mike, > > I'll fix the TestBackwardsCompatibility. The mistake was to freeze the > 6x branch in the first place. The release branch is the one which > should be frozen. I specifically asked the RM to cut the branch to let > others progress but I received no replies -- which is why I was forced > to do it myself. In future, the RM should keep this in mind and not > block others. The rest of the problem was because I am new to Git -- > in subversion a release branch is always copied from the server so > pulling latest changes locally before creating the branch did not > cross my mind. > > On Thu, Mar 3, 2016 at 9:46 PM, Michael McCandless > <luc...@mikemccandless.com> wrote: > > Shalin, > > > > In the future please don't jump the gun like this? > > > > It has caused a lot of unnecessary chaos. It should be the RM, and > > only the RM, that is doing things like creating release branches, > > bumping versions, etc., at release time. > > > > Also, your changes to bump the version on 6.x seem to be causing > > TestBackwardsCompatibility to be failing. Can you please fix that? > > In the future, when you are RM, please run tests when bumping versions > > before pushing. > > > > A major release is hard enough with only one chef. > > > > Mike McCandless > > > > http://blog.mikemccandless.com > > > > > > On Thu, Mar 3, 2016 at 8:52 AM, Shalin Shekhar Mangar > > <shalinman...@gmail.com> wrote: > >> Hmm I think I created the branch without pulling the latest code. I'll > fix. > >> > >> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir <rcm...@gmail.com> wrote: > >>> This is missing a bunch of yesterday's branch_6x changes. Some of > >>> david smiley's spatial work, at least one of my commits. > >>> > >>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar > >>> <shalinman...@gmail.com> wrote: > >>>> FYI, I have created the branch_6_0 so that we can continue to commit > >>>> stuff intended for 6.1 on master and branch_6x. I have also added the > >>>> 6.1.0 version on branch_6x and master. > >>>> > >>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey <apa...@elyograg.org> > wrote: > >>>>> On 3/2/2016 4:19 AM, Alan Woodward wrote: > >>>>>> Should we create a separate branch_6_0 branch for the > feature-freeze? > >>>>>> I have stuff to push into master and that should eventually make it > >>>>>> into 6.1, and it will be easy to forget to backport stuff if > there's a > >>>>>> week before I can do that… > >>>>> > >>>>> +1 > >>>>> > >>>>> When I saw Nick's email about branch_6x being feature frozen, my > first > >>>>> thought was that we don't (and really can't) feature freeze the > stable > >>>>> branch -- isn't new feature development (for the next minor release > in > >>>>> the current major version) the entire purpose of branch_Nx? > >>>>> > >>>>> A feature freeze on a specific minor version does make sense. I've > seen > >>>>> a couple of people say that we have, but there are also a few > messages > >>>>> from people saying that they want to include new functionality in > 6.0. > >>>>> I expect that backporting almost anything from branch_6x to > branch_6_0 > >>>>> will be relatively easy, so it may be a good idea to just create the > new > >>>>> branch. > >>>>> > >>>>> Thanks, > >>>>> Shawn > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Regards, > >>>> Shalin Shekhar Mangar. > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > >> > >> > >> -- > >> Regards, > >> Shalin Shekhar Mangar. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > -- > Regards, > Shalin Shekhar Mangar. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
