[vtk-developers] Git hierarchy formalization

[David Thompson]

On Mar 31, 2010, at 14:20 , Wilson, Andrew T wrote:
> On 3/30/10 5:14 PM, "David Doria" <daviddoria+vtk at gmail.com> wrote:
>> It seems to me for the git structure to work effectively a more  
>> formal
>> hierarchy must be setup.
>
> This raises the question of how changes are going to propagate into  
> the
> trunk.  Right now we've got a "push" workflow in place: I commit  
> into the
> trunk and everyone gets it on the next cvs update. ...
> Linux differs from this in that they had a "pull" workflow and a  
> defined
> hierarchy in place long before git and even bitkeeper.  I'm  
> paraphrasing
> loosely so please forgive a bit of inaccuracy.  Various people owned  
> various
> (large) parts of the tree.  Linus got patchsets from them.  They got
> patchsets from people working for them and so on.

I don't think it's a question of push or pull; git allows both. I also  
don't think it is (or needs to be) quite as structured as that.  
Certainly the hierarchy of kernel developers exists and that is good  
for scaling. But I don't think the ownership of the tree is so rigid,  
at least for things like documentation and simple bug fixes,

For people who have push authority, there is a decision to make about  
whether to push or have someone (perhaps your Kitware "buddy") pull  
code. I suspect that will depend on the magnitude of the change (push  
bug fixes or small, backwards-compatible feature enhancements; have  
Kitware pull large changes or changes to subsystems with which you are  
not familiar).

For people without push authority, now there is a formal path (beyond  
attaching a patch to the bug tracker) for creating and maintaining a  
patch against the trunk or a release branch.

> If we're going to have a hierarchy like that, how will we delineate  
> areas of
> responsibility?  How big should they be?

Although one *may* introduce more formality to the process by  
assigning managers to specific pieces of code (e.g., the pipeline  
executives or vtkAbstractArray subclasses) and forcing more pulls to  
occur, I don't see a need for it at the moment. We haven't even  
starting using git yet, so it's unclear how the new tools will help/ 
hinder code review and patch submission. If it does happen, I'm  
guessing the ARB will publish guidelines on the wiki?

> I take no position on whether it's something we should do except to  
> agree
> that it would be great to be better able to pull in changes and  
> enhancements
> from people who don't have write access to the trunk.

Isn't this what the gitorious merge request feature is for? (I'm  
assuming Kitware will be serving their repo with gitorious, but github  
has a similar thing.) If you haven't seen it, take a look at
   http://gitorious.org/gitorious/mainline/merge_requests
for example. It provides a nice way to submit a patch for review,  
allow people with push authority to suggest changes to it, allow the  
patch to be rebased and resubmitted, and so forth.

	David