<div dir="ltr">On Sat, Mar 16, 2013 at 9:16 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> I think the model of long-running development, which is also the model<br>
> being used by the integrator (Jed) to master, is not suitable for a<br>
> community nor scalable.<br>
<br>
</div>Any of us can integrate.<br>
<div class="im"><br>
> I am developing in knepley/pylith, which is the branch I tell PyLith people<br>
> to look at. I know I need to keep up-to-date with other changes because I<br>
> eventually want to get into the release, and don't want one big hairy<br>
> merge. However, I can't merge with 'next' because that stuff is not going<br>
> in the release. The current model says that I know about what everyone else<br>
> is doing in all other branches, and pull those branches which interact with<br>
> my changes in. That is a huge load on an individual developer, and<br>
> impossible to know everything that will matter. And how will I know which<br>
> of these is going to make it master?<br>
<br>
</div>Why do you want to depend on all that stuff? If a topic is not in<br>
'master' yet, then by definition, we're not confident that it is (a)<br>
complete enough to be useful and (b) stable and portable.<br>
<br>
You will find out about any potential conflicts when you merge your work<br>
into 'next'. It is not helpful to make your topic depend on theirs just<br>
to find out if it conflicts.<br>
<div class="im"><br>
> This is exactly how merges to master will also happen. Someone with control<br>
> issues will find every branch that should be merged in and will do that. It<br>
> sounds totally unscalable, and would fall apart if that person is not<br>
> there. Linus likes making himself indispensible. This sounds like that.<br>
<br>
</div>Anyone can integrate, typically either the author of a branch or the<br>
reviewer of a pull request. The branching model does not imply hierarchy<br>
of _people_, just that branches have distinct purposes.<br>
<br>
'next': test and disseminate in-progress stuff to interested users and<br>
    see how topics interact<br>
<br>
'master': starting point for new features, integration point for<br>
    releases, and stable combination of recently-completed features<br>
<br>
topic branches:<br>
    fix bugs and develop new features to a point that is stable enough<br>
    to graduate to 'master'<br>
<br>
<br>
The philosophy of not constantly merging other features into your branch<br>
is that you don't know what you're getting, and it needlessly makes your<br>
topic depend on theirs (you can't graduate until they do).<br>
<br>
In our old model, with constant merging/rebasing to a single shared<br>
branch, everything depended on everything else *by default*. That is<br>
fundamentally non-scalable, made development hard to follow, and<br>
explained the relative instability of petsc-dev. With topic branches,<br>
your topic depends on *nothing else* by default, but is still tested in<br>
combination with everything else (by merging to 'next').<br>
</blockquote></div><br>Okay, so that way I make sure that stuff is not breaking is always to merge</div><div class="gmail_extra">into next.</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>However, it  still appears that the model for publishing features has the costs</div>
<div class="gmail_extra" style>above. Maybe I do not see how you want it to go. Here is my situation:</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>  I have a knepley/pylith branch. I have this branch because I anticipate that</div>
<div class="gmail_extra" style>  new things required by PyLith will not come out in 'master' fast enough. However,</div><div class="gmail_extra" style>  all things in here should eventually go into master.</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>If master was integrated frequently, I have no problem. I will just use that, but</div><div class="gmail_extra" style>that was not my impression. The alternative seems to be to pull in each branch</div>
<div class="gmail_extra" style>individually that went into 'next', and which we think will go to master. But what if</div><div class="gmail_extra" style>I am wrong and merge something that does not go into master?</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>I did not have this problem with the old PETSc model. I could just pull petsc-dev</div><div class="gmail_extra" style>and be alright.</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>   Matt</div><div class="gmail_extra"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>