[vtk-developers] ANN: All VTK commits through the topic stage

Jim Peterson jimcp at cox.net
Tue Oct 12 21:55:08 EDT 2010


I just wanted to make a comment in full support of Dr. Marcus, any time 
you have a software product that has customers, there is no such thing 
as a small bug fix. All changes must be tested and validated as at least 
"does no harm" with whatever test suite is available, otherwise the 
"small bug fix" will explode into a flurry of follow-up changes tangled 
amidst the feature and customer reported error patches to the product. I 
have seen this error pattern happen even in private company commercial 
software when the project is closed source updated only by company 
programmers when there are insufficient quality checkpoints in the 
source update and publication path. When the project is open source, 
effective quality controls are even more important. The software vendor 
companies I have worked for generally feel a full time tester is 
required per software developer. Finding a way to make progress toward 
that kind of quality coverage on a open source project is commendable.

Thank you Marcus Hanwell.

Jim Peterson



Marcus D. Hanwell wrote:
> On Tuesday 12 October 2010 18:16:15 David Doria wrote:
>   
>> On Tue, Oct 12, 2010 at 4:17 PM, Marcus D. Hanwell <
>>
>> marcus.hanwell at kitware.com> wrote:
>>     
>>> Hi,
>>>
>>> As previously announced on September 23, the VTK topic stage is available
>>> to
>>> merge in topic branches. From Thursday October 14 all commits to VTK will
>>> need
>>> to be made through the topic stage, and direct pushes to the VTK
>>> repository will be disabled.
>>>       
>> Should directly pushing to master be removed all together? What about
>> little bug fixes? It seems crazy to make a topic branch just to push a one
>> line change.
>>
>>     
> If you think like a CVS user then yes, but topic branches are just named 
> pointers to a hash. Also, consider the case where you fixed your bug, you 
> pushed, and then realized you had not accounted for how it works on Windows, 
> then you push another commit and we now have no way of connecting those two 
> commits together.
>
> Further, consider we want to backport your fix to the next VTK bug fix release, 
> but we only spot the first commit (not the next one you made a week later). Or, 
> we only spot the second and miss the first. Both of these cases have happened 
> in VTK with the bug fix releases and caused lots of headaches.
>
> It gets people used to using the stage, and where it is really required is 
> when we switch to using master *and* next. In order to merge a change into 
> next, see if it works, and then merge the same change into master, the only 
> viable workflow is the branchy workflow we have discussed. Merge commits are 
> necessary to show the point at which the commit was merged into next, and 
> later master.
>
> http://public.kitware.com/Wiki/Git/Workflow/Stage
>
> That wiki page details some of the motivation behind this. We want to move to 
> a workflow where people land complete features. It also allows us to use code 
> review tools such as Gerrit if we wish, and have all of the commit objects 
> resolve to being the same thing without the rebasing necessary in a linear 
> workflow.
>
> Hopefully this clears up some of the motivation for you. As I said to you in a 
> private email, there is a Source article in the upcoming October issue, along 
> with several wiki pages. Reading 'man gitworkflows' might also be useful.
>
> Marcus
>   




More information about the vtk-developers mailing list