Cool, thanks!

> On Apr 15, 2019, at 12:12 AM, Adrien Grand <[email protected]> wrote:
> 
> This has been implemented: https://issues.apache.org/jira/browse/INFRA-18192.
> 
> On Wed, Apr 10, 2019 at 2:41 PM Gus Heck <[email protected]> wrote:
>> 
>> Slightly behind on mails, but I'd like to Echo Erik ... +1 for protection -1 
>> for removal.
>> 
>> On Fri, Apr 5, 2019 at 11:22 AM Erick Erickson <[email protected]> 
>> wrote:
>>> 
>>> Protecting those branches would answer the question “If we were to change 
>>> the 6.6 branch in order to release a 6.6.7, should I put the changes in 6x 
>>> too” question with “no” ;).
>>> 
>>> Also, if anyone really wanted to re-open 6x they’d have a known state. 
>>> Well, not 6x since I’m certain some things have been committed there that 
>>> haven’t been committed to 6_6… Er… See what I mean? But going forward….
>>> 
>>> In some weird case where we wanted to release a 6.7 (which I don’t see 
>>> happening frankly), we could open up the 6x branch again and bump the 
>>> branch on a case-by-case basis. After “frank and open" discussions about 
>>> how that’s not our policy....
>>> 
>>> In general I’m in favor of being unable to screw something up so protecting 
>>> all the branches we shouldn’t modify  from writes is a +1.
>>> 
>>> I’m -1 for removing branches.
>>> 
>>> Erick
>>> 
>>> P.S. And I do note that you carefully did _not_ include 6_6 or 7_7 so we 
>>> can still do the point releases.
>>> 
>>> 
>>>> On Apr 5, 2019, at 7:47 AM, Adrien Grand <[email protected]> wrote:
>>>> 
>>>> Removing branches proved a bit controversial in the past, 
>>>> seehttps://markmail.org/message/6ah3m6zd6v3ik3ie for instance.
>>>> 
>>>> On Fri, Apr 5, 2019 at 3:24 PM Shawn Heisey <[email protected]> wrote:
>>>>> 
>>>>> On 4/5/2019 3:19 AM, Adrien Grand wrote:
>>>>>> Apparently it is possible to ask INFRA to mark branches as
>>>>>> protected[1]. Should we do it for branches that are not expecting new
>>>>>> releases anymore? I think it would make things less trappy. For
>>>>>> instance, backporting to branch_7x is almost for sure a mistake since
>>>>>> we are not going to release lucene/solr 7.8.
>>>>>> 
>>>>>> [1] https://issues.apache.org/jira/browse/INFRA-18109
>>>>>> 
>>>>>> What would you think of protecting the following branches:
>>>>>>  branch_3x
>>>>>>  branch_4x
>>>>>>  branch_5_4
>>>>>>  branch_5_5
>>>>>>  branch_5x
>>>>>>  branch_6_0
>>>>>>  branch_6_1
>>>>>>  branch_6_2
>>>>>>  branch_6_3
>>>>>>  branch_6_4
>>>>>>  branch_6_5
>>>>>>  branch_6x
>>>>>>  branch_7_0
>>>>>>  branch_7_1
>>>>>>  branch_7_2
>>>>>>  branch_7_3
>>>>>>  branch_7_4
>>>>>>  branch_7_5
>>>>>>  branch_7_6
>>>>>>  branch_7x
>>>>> 
>>>>> In the SVN days, branches were simply deleted when we were through
>>>>> cutting releases from them.  Deleted branches all came back when we
>>>>> converted to git.
>>>>> 
>>>>> Is protecting them the only way to maintain the history?  If so, then
>>>>> I'm +1.  Does deleting them like we did on SVN make it impossible to "go
>>>>> back in time" in the repo?
>>>>> 
>>>>> Thanks,
>>>>> Shawn
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Adrien
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>> 
>> 
>> 
>> --
>> http://www.the111shift.com
> 
> 
> 
> -- 
> Adrien
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to