-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

Oh I know!  Actually applying software engineering principles to a large
 software project is just stupid. ;)

We either want code reviews or we don't.  There is no option of wanting
code reviews without the effort of reviewing code.  This is, literally,
one of those "you can't have your cake and eat it too" situations.
We've used "understaffed" as a justification for seat-of-the-pants
development for way, way too long.  Applying controls to a stable
release branch is just common sense.  For a project this size, Mesa is
alone in not applying such controls.

>> This seems like a fine plan for stable release branches.  There are
>> several tools available to which patches have been sent to a mailing
>> list but not applied.  Using one of those should fix the problem where
>> patches would not get cherry-picked back to stable branches.  The X
>> server is trying this method, and it seems to be working.
> 
> Really? I see patches re-re-re-sent and forgotten all the time.

That has been a (big) problem in the past.  I think most of the problems
that people saw with that were from before the patch tracking tool was
used.  If it's still a problem now, I blame Keith, and I doubt he would
disagree. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktgm8UACgkQX1gOwKyEAw9EdQCgl9S/Sl5mYcnx9Mjw9YdRVDSl
dSAAn0TX5HlsM8rRfXcmLrUMOtkb9iYs
=3leL
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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