Git Worflow, branch creation.

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110518/55a0588a/attachment.sig>