openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

On Fri, 2012-05-04 at 17:11 -0700, Chris Wright wrote:

> * Mark McLoughlin (markmc@xxxxxxxxxx) wrote:

> >   - Subsystem branches would not rebase unless the project dictator 
> >     outright rejects a merge request from the subsystem branch (i.e.
> >     "I'm not merging commit abcdef0! Fix it and rebase!"). This means 
> >     the subsystem maintainer will need to regularly (probably only when 
> >     there are conflicts to be dealt with) merge master back into the
> >     subsystem branch.
> 
> Any branch that has a downstream user (someone who's cloned that branch)
> should not rebase.

There are lots of public branches which do rebase though, right? As in,
no matter what the theory is about "never rebase a public branch",
people do make their stuff available in public git branches before those
commits make the transition into the never-rebase phase.

The way I think about it is that it's as valid to publish a commit in a
public git repo as it is to send a patch to a mailing list. Indeed, the
former is more useful because you have the context of the parent commit.

What I don't fully understand is how folks make it clear to others
exactly which of their public branches can be expected to never rebase.
Convention? Tribal knowledge?

> If the subsystem->master merge prop is rejected, the subsystem should
> generate a new branch, re-apply the relevant changes (dropping,
> rearranging, etc as necessary), and start a new merge prop.

And anyone who had based their work on the subsystem branch would have
to rebase it on to the new subsystem branch.

> I'm unclear on where gerrit fits on that rebase step?

A subsystem maintainer would accept changes into the subsytem branch
through gerrit but also propose merges into master using gerrit. If the
master merge prop was rejected, you'd need to create a new subsystem
branch and re-propose everything again.

> Regular merging master back is one culprit in your "screaming for the
> hills" review of kernel git history.  In fact, it's discouraged there.
> The workflow is helped by the merge windows which makes for discrete
> merge points.

Yeah, you don't merge master back at arbitrary times, or where your
branch will conflict with master. But you would merge back at regular
checkpoints (e.g. milestone releases every 6 weeks) but also if there
was something new in master needed by new stuff in the subsystem.

> >     Should there be a "DB" subsystem? Probably not, because that would 
> >     mean every new feature needs to come through this branch or, 
> >     alternatively, the DB maintainer would need to accept DB schema 
> >     additions without the context of how it's being used higher up the 
> >     stack.
> 
> This does touch on the reality that some changes will span subsystems
> which will require coordination between subsystems.  Having a mechanism
> for this coordination ahead of time is helpful.  In Linux it's one job
> of the linux-next tree, but that doesn't address jenkins side.

Could you talk through a complicated example of co-ordination and how
linux-net solves that?

e.g. some new feature added to the x86 subsystem for KVM. The stuff gets
accepted into Ingo's x86 tree first, then Avi merges that into his tree,
bases the new KVM stuff on it and waits for Ingo to propose his tree
before proposing the KVM tree?

Hmm, where does linux-net fit in there? Or is linux-net just good for
finding unintentional conflicts between stuff in different subsystem
trees? How are those conflicts then resolved?

> >   - When a feature branch is ready to be merged into a subsystem 
> >     branch, the patch series is submitted for review. The subsystem 
> >     maintainer will likely require changes to individual patches and 
> >     these changes would be made on the feature branch and squashed back 
> >     into the appropriate individual patch.
> >
> >     (Ideally gerrit's "topic review" feature will get upstream and 
> >     we'll use that. This would mean that a patch series could be 
> >     proposed for review as a single logical unit while still keeping 
> >     individual patches as separate commits)
> 
> One topic that came up at the design summit that I think you mean by the
> above is the "to squash or not to squash?" question.
> 
> The series may need rework (rebase, fix+internal squash, etc) while
> it's a feature branch, but it gets merge prop'd as a real stand alone,
> bisectable patchset (minus the true work-in-progress fiuxps/changes,
> of course).  Put another way... 'git rebase -i' is your friend ;)

Yes, what I was referring to is that gerrit will hopefully gain a
proposed "topic reviews" feature which will make it easier for reviewers
to review a patch series - i.e. rather than appearing in gerrit as
individual patch reviews with a fairly obscure "dependencies" widget in
each review, you'd actually be able to go to a review page representing
the entire series of patches and go through each one in order.

Cheers,
Mark.