Tom Lane <t...@sss.pgh.pa.us> writes: > Topic branches defined that way seem like a pretty bad idea from here. > They would save no effort at all for committers, because if you're not > allowed to object to something after it's gone into a topic branch, then > it's just like master in terms of having to keep up with changes as they > happen. Moreover, we'd have to keep them in pretty close sync with > master --- otherwise what happens when you discover that some long-ago > change on master breaks the topic branch? So AFAICS this would just > increase the amount of keeping-branches-in-sync dogwork without any > offsetting advantage.
The only advantage I can think about is twofold: - publish what feature set you want to have complete to consider merge - have more than one person able to partake into making it happen Maybe it's just me, but it seems like some people sent in patches to solve a partial set of the partitioning-for-real work and those have been rejected on the grounds that it's not complete. This topic branches idea is all about being able to review and apply the patches, and say "we still need this and that stuff to get done someday before we consider a merge". Do you prefer this all to happen externally and without commiters helping in the incremental effort? I can see the burden if we include such topic branch in our existing processes, but also the advantages. You call that a judgement call, right? It's surely not mine to make. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
