On Sun, Dec 5, 2010 at 12:41 PM, Andrew Dunstan <and...@dunslane.net> wrote: > Well, ISTM that amounts to not having "official topic branches" :-) I agree > that this is supposed to be one of git's strengths (or more exactly a > strength of distributed SCM's generally). I don't really see any great > value in sanctifying a particular topic branch with some official status.
I think the value in an official topic branch would be to allow formal incremental commit of large patches. In other words, we could decide that a commit to the official topic branch must meet the same standards of quality normally applied to a commit to the master branch, and must go through the same process. It would be understood that the topic branch would eventually be merged (with or without squash) back into the master branch, but that objections were to be raised as pieces were committed to the topic branch, not at merge time. The merge itself would require consensus as to timing, but we'd agree to take a dim view of "I haven't reviewed anything that's been going on here for the last six months but now hate all of it". I think that this sort of approach could be useful either for really big projects, like perhaps SQL/MED; or possibly for certain categories of changes (things we want to include the next time we do a libpq version bump). Although, the trouble with the latter is that we do compatibility breaks so rarely that the effort involved in maintaining the branch might well exceed the value we'd get out of having it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
