Re: [gentoo-portage-dev] portage-2.3.2 stable request?

["Manuel Rüger" <mrueg@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3036 bytes --]

On 05.11.2016 00:15, Zac Medico wrote:
> On 11/04/2016 03:55 PM, Zac Medico wrote:
>> On 11/04/2016 03:47 PM, Brian Dolbec wrote:
>>> On Fri, 4 Nov 2016 13:53:02 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>
>>>> On 11/04/2016 01:43 PM, Michał Górny wrote:
>>>>> On Fri, 4 Nov 2016 13:19:39 -0700
>>>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>>>   
>>>>>> On 11/04/2016 01:14 PM, Brian Dolbec wrote:  
>>>>>>> On Thu, 3 Nov 2016 15:55:23 -0700
>>>>>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>>>>>     
>>>>>>>> In about a week, portage-2.3.2 will be eligible for a stable
>>>>>>>> request.
>>>>>>>>
>>>>>>>> The only potential problem that I've noticed is the complaint
>>>>>>>> about changes from bug 552814 causing issues for people using
>>>>>>>> git sync with overlay filesystems, but setting sync-depth = 0
>>>>>>>> gives those users a workaround. There's also bug 597838, about
>>>>>>>> the sync-depth setting being ineffective, but I only know of a
>>>>>>>> couple of people that have been able to reproduce that.
>>>>>>>>
>>>>>>>> So, do we want to do a stable request portage-2.3.2 when the time
>>>>>>>> comes?    
>>>>>>>
>>>>>>> I'm not sure.  Do we -r1 it adding a patch or two and ask it be
>>>>>>> stabled? 
>>>>>>
>>>>>> There are just 4 commits since 2.3.2, and they all look good.
>>>>>> Maybe we should just cut a 2.3.3 release and wait another 30 days
>>>>>> (we also need to stabilize app-crypt/gkeys since it's needed by
>>>>>> emerge-webrsync now).  
>>>>>
>>>>> Wouldn't it be better to have a really working version of gkeys
>>>>> before it's stabilized? Like one that could be used without having
>>>>> to create custom configuration files and/or run it as root?  
>>>>
>>>> Well, gkeys stabilization is not really mandatory, since
>>>> emerge-webrsync has a --insecure option.
>>>
>>> Why don't I/we work on whatever changes are needed to merge the
>>> meta-manifest code to both portage and gkeys.  I'll push out another
>>> release.  I also had some initial code that added gkeys use to verify
>>> the pkg Manifest file, but I don't know if that is needed still, the
>>> meta-manifest system will need to run a verify at the end of the sync.
>>>
>>> We'll have to poke Robin some more to get some new infra keys setup.
>>>
>>> If I have to, maybe I'll create some ansible scripts to run the dev
>>> seeds update on vulture, transfer it to my system to push --sign to
>>> api.g.o or break down and get Kristian to help me get key forwarding
>>> better setup so I can do it from vulture.
>>
>> Sounds good, but I think we should cut a portage 2.3.3 release before we
>> make any more changes. Maybe do a release branch that includes
>> everything except the emerge-webrsync change.
> 
> Let's just revert the emerge-webrsync patch, so we can tag a 2.3.3
> release on the master branch.
> 

Will repoman be released with the same tag as well or is the portage and
repoman version not going to be syncronized?

Cheers,

Manuel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 603 bytes --]