Message: previous - next
Month: February 2012

Re: [trinity-devel] Plan B

From: Calvin Morrison <mutantturkey@...>
Date: Fri, 17 Feb 2012 21:15:32 -0500
On 17 February 2012 21:12, Timothy Pearson <kb9vqf@...> wrote:
>> On 17 February 2012 00:59, Timothy Pearson <kb9vqf@...>
>> wrote:
>>>>> Serghei also has commit access.  I have been waiting to
>>>>> merge patches
>>>>> until I can build test the packages, but with recent changes
>>>>> I am waiting
>>>>> on an archive rebuild for Ubuntu.
>>>> Ok, so you are waiting to start that big wooshing sound. Fair enough.
>>>> :)
>>>> But that does not address the core concern: what happens to Trinity
>>>> should
>>>> you become unavailable for a long period or forever?
>>>> Additionally, Serghei is another sharp person but is fairly busy too.
>>>> His
>>>> commit access does not change the picture of either of you being too
>>>> busy
>>>> to keep patches merging, especially build related patches.
>>>> Of the non build related patches, many are small and don't need a
>>>> rocket
>>>> scientist to decide that merging probably is safe. Should there be
>>>> others
>>>> with commit access?
>>>> Darrell
>>> Probably.  I can't enforce it with technical means, but I suppose we
>>> could
>>> use the Etherpad to review patches and if two or more non-core devs
>>> agree
>>> that the patch looks sane (and doesn't remove functionality, etc.) the
>>> patch could be pushed.
>>> That leaves the question of who to grant access to.  You and Calvin are
>>> two that come to mind, but I would need poeple to agree that they won't
>>> "go rogue" and just start pushing unreviewed patches. ;-)
>>> Tim
>> I would love to review patches. for some time I have been wanting to
>> set up a review board... but I am sure an etherpad could work just as
>> well for now!
>> again here is where git's branching features come in really really
>> handy. we could pull those changes into a testing branch and then
>> merge them right back into the mainline when everything looks well.
>> Calvin
> This still leaves someone having to pick over the patches when they are
> merged into mainline.
> Tim

Good point,

I could push sane non critical patches like CMake (which i am rather
familiar with) and things regarding renaming, branding, or some other
non-critical functions. At any point where I become confused as to the
patch, I can just defer the changes to you