José Fonseca wrote:
> On Wed, 2010-01-27 at 00:59 -0800, Keith Whitwell wrote:
>> On Tue, 2010-01-26 at 16:26 -0800, Brian Paul wrote:
>>> Stephane Marchesin wrote:
>>>> On Tue, Jan 26, 2010 at 15:13, Ian Romanick <i...@freedesktop.org> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> José Fonseca wrote:
>>>>>> mesa_7_7_branch and master are becoming quite different, because of all
>>>>>> the gallium interface changes that have been going into master, so
>>>>>> merging fixes from mesa_7_7_branch into master is becoming less and less
>>>>>> of a trivial exercise.
>>>>>>
>>>>>> This is aggravated by the fact we are basing a release from the
>>>>>> mesa_7_7_branch, so it's likely that we'll need to have temporary
>>>>>> non-invasive bugfixes that should not go into master (which should
>>>>>> receive instead the proper and potentially invasive fix).
>>>>>>
>>>>>> I see a few alternatives here:
>>>>>>
>>>>>> a) stop merging mesa_7_7_branch -> master. bugfixes should be applied to
>>>>>> both branches. preferably by the person that wrote the patch.
>>>>>>
>>>>>> b) when applying a non-trivial bugfix to mesa_7_7_branch, the same
>>>>>> person should do the merge into master, and undo any undesired change,
>>>>>> or update for interface changes in master. Note however that it's better
>>>>>> to give a few days between applying to mesa_7_7_branch and merging into
>>>>>> master, to allow for wider testing, otherwise we'll be merging like
>>>>>> crazy.
>>>>>>
>>>>>> c) do not apply any non trivial bugfix to mesa_7_7_branch anymore, and
>>>>>> use a separate branch for those.
>>>>>>
>>>>>> I don't feel strongly about any of these alternatives for now. We'll
>>>>>> eventually need to setup a private branch for our release so c) is bound
>>>>>> to happen anyway. But I also think we can't keep merging mesa_7_7_branch
>>>>>> into master like this forever -- after so much thought was put into the
>>>>>> gallium interface changes (feature branches, peer review, etc) but
>>>>>> whenever a mesa_7_7_branch -> master happens all sort of wrong code is
>>>>>> merged automatically.
>>>>> This was my primary argument *against* our current commit / merge model.
>>>>>
>>>>>> The ideal would be to peer-review the merges before committing, but it
>>>>>> seems difficult to do that with git, while preserving merge history and
>>>>>> not redoing merges.
>>>>> It sounds like we want to copy the Linux kernel model:
>>>>>
>>>>> - - Each developer has a local tree.
>>>>> - - Each developer sends out:
>>>>>   - A patch series
>>>>>   - A pull request
>>>>>   - A list of commit IDs to cherry-pick
>>>>> - - Based on review comments, the maintainer applies the patches / pulls
>>>>> the tree.
>>>> More bureaucracy. Just what we need in our understaffed world.
>>> I'm not too crazy about this either.  We can barely keep up with the 
>>> patches submitted for review now.  I certainly don't have time to 
>>> review everything that comes along and very few other people are 
>>> reviewing/testing/committing patches either.
>>>
>>> My plate is already full.
>> One thing worth noting is how well the branch->master merges have been
>> working.  We've *never* managed to put so many fixes into the stable
>> branch and successfully propagate them to master.  Think of the hundreds
>> of commits Vinson has made fixing errors from static analysis.
>>
>> The system has worked better than anything else before, but is now
>> starting to reach its limits.  That seems to me to call for a minor
>> adjustment rather than a total overhaul.
> 
> Yes. I agree.
> 
> Indeed reviews only work if there are enough reviewers, and the review
> traffic is pretty overwhelming as it is. I should have thought of that
> before mentioning it.
> 
> BTW, Brian thanks for all the hard work you've been doing on taking
> patches. I should and will try to do more on this subject.
> 
>> Maybe the approach should be to minimise now the amount of stuff going
>> into the stable branch - ask Vinson to do his work on master now, for
>> instance, and let the stable branch only take fixes for user-visible
>> bugs, which are hopefully smaller in volume.
> 
> Yes, that's probably a good compromise.

I've already asked Vinson to switch over to master for his clean-ups.

-Brian

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to