[vtk-developers] Git hierarchy formalization

[Berk Geveci]

Just a quick note. I am sure we will discuss this more soon.

We have no plans to establish a formal hierarchy (like that of Linux).
Those that currently have write access will have push access to the
main repo (if they want it and if give us their public ssh key). We
will probably use a combination of merge requests and patches on the
mailing list and/or bug tracker to accept contributions.

We are going to setup a workflow for the developers to follow that
involves multiple published branches and corresponding CDash
categories. More on that later.

-berk


On Wed, Mar 31, 2010 at 5:56 PM, David Thompson <dcthomp at sandia.gov> wrote:
> 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
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>