On Tuesday, May 17, 2011 11:40:30 Alexis Ménard wrote: > fact that you couldn't hack features in the official trunk, people had > to use personal svn branches and now teams like plasma think about > setup integration repos. That sounds weird, you usually use these
personally, i don't care whether there is a separate repository for integration or its all done in branches in one repository. there are benefits, and challenges, to doing it either way. what we want to move away from, however, is a master branch that is open to all and any changes at any point in time. we want a branch where things are integrated and tested by the main group of people working on the software and those who follow it closely. that branch will have feature branches merged into it, bug fixes applied to it, etc. then, at regular intervals that allow for stabilization, that branch will be merged into master. we want the ability to use Feature A with Feature B without running that experiment in master. we want master to be as stable as possible at all times without removing the ability to run experiments and confirm that thing work well together, which means moving what we do today in master to another branch. the ability for developers to delete branches would also be very helpful in that regard. but the real problem goes a lot deeper here, imho. the reason for a feature freeze in master is that it assumes we're all working on features *in* master (or, previously, in trunk). we may wish to rethink that approach in general. if all new feature devel is done in branches, then a "feature freeze" would mean "no feature branches that haven't been merged by now can be merged". how to manage that process, including translatation updates and multiple merges over time from a given feature branch, is what needs planning. i don't want to start this discussion here on this mailing list as i doubt it will result in anything useful, given the constraints on bandwidth and opportunity to easily diverge into a thousand sub-topics. let's ensure this gets attention at up-coming face-to-face meetings and work out a solution there. Platform 11 in a couple of weeks could look at this for kdelibs, and as a broader community we could take it on at the Berlin Desktop Summit. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
