New development model check-in.

Peter Hutterer peter.hutterer at who-t.net
Mon Nov 23 20:04:21 PST 2009


On Tue, Oct 27, 2009 at 11:55:27PM -0700, Keith Packard wrote:
> So, this is just a quick status check on the new development
> model. I'd like to hear from anyone with an opinion on how it's
> working for them.
> 
> Obviously we're seeing a bit more delay in getting patches into
> master, but I think that's been mostly positive, with a bit more
> discussion happening on various patch sets about the best way to do
> things.

question about the preferred modus operandi:
what are the conditions to applying a patch from the list straight to
master?

I thought it was you as CC but that's not always the case, in fact I noticed
that some patches sent for general review get applied directly to master.
So in preparing a patchset with several patches, some of them are already
there by the time I'm ready to send a pull request.

In two concrete cases:
- my pull request was reduced to a single patch. That feels a bit meager to
  send a pull request for.
- a patch was applied to master and then a day later reviews come in that
  require changes to this patch. Pull requests tend to be a bit delayed, so
  that can be caught by those.

IMO sometimes patches don't need to go to the list beforehand (e.g. comment
fixes, etc.). That's why accumulating a few patches, some reviewed, some
not, for a pull request makes sense to me.

Add on on top of that your habit of cherry-picking patches from a pull request
which makes it harder to have a fast-forward branch.

So right now I'm confused about what's the best way to go about it.
My preferred mode would be:
- send patches to list for review, only merge into master if asked for
- send pull requests
- patches in pull requests that aren't suitable should get reverted with an
  explanation.

I think this might suit Michel a bit better as well, since he could replace
'git push origin master' with 'git push fdo master' and the occasional pull
request. He doesn't need to wait for you applying patches, he needs to keep
track of public review himself which I think isn't largely different to the
old "push to master" model.
Of course, that doesn't change the delay in getting patches to master.

heers,
  Peter


More information about the xorg-devel mailing list