Git Worflow, branch creation.

[Aaron J. Seigo]

On Thursday, May 19, 2011 10:05:27 Cornelius Schumacher wrote:
> On Thursday 19 May 2011 Aaron J. Seigo wrote:
> > http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Wo
> > rkf low
> 
> Wow. This is a pretty complex workflow, and it's breaking with quite some
> practices KDE used to use for a very long time. We have to make sure that we
> don't leave developers behind with such a drastic change.

this is why we need to have work on it together. while a few of us have taken 
first steps in terms of drafting something, basically because someone has to 
otherwise we all stay in limbo with nothing being done, this is more of a 
provocative call to participate than anything even close to a final proposal.

if we don't participate as if we care about this, we will get a workflow that 
doesn't serve us very well. which is what we have now. ;) so consider this a 
process in creating our shared future workflow with everything on the table to 
be modified, changed and improved as we see fit.

note that there wasn't unanimous agreement on this workflow at Tokamak, but it 
at least gave us a starting point. we've openly documented it, brought the 
discussion to k-c-d and want input. there's a reason for that: we don't want 
to leave anyone behind and we want a workflow that, well, works. :) with a few 
iterations of this approach, i think we can have something pretty damn good 
put together.

> The approach of having one central repository and all committers being equal
> has served us well.

i don't think that will change much. what is likely to change is that we won't 
be developing in a one mainline branch that we expect to become stable. it's 
nearly magical thinking that this is possible, in fact. in the goal of 
increasing the predictability of master, we can (and should) all still be 
equal in our interactions.

> Maybe it's time to move forward to a different model,
> but I think this should be done with care, and without changing more than
> needed. 

yes, hopefully we change only what is needed and no more. :)

> A lot of this is about semantics and how to name things, not
> necessarily about technical processes. For example, if master is the stable
> branch or a release branch doesn't make a big difference technically, but
> it might affect our development culture quite a bit.

agreed; note that the suggestion is not to make master _the_ stable branch 
(release branches would still maintain that position) but to make master as 
stable as possible over any given period of time.

right now we have unpredictable levels of stability in master depending on the 
phase of the moon and where in the release cycle we are. this makes many 
things more difficult (including making time based releases) than it probably 
needs to be. at times it results in us shipping releases with more defects 
than we ought to.

increasing the day-to-day stability and predictability of master by using 
git's strength in merging could probably do wonders for our releases. not to 
mention it would be very welcome by people working on device targets for which 
the release date of a given KDE SC event is less important compared to always 
having a place to pull from that is reasonably safe and not feature-stale.

> This needs to be discussed. I'm looking forward to the upcoming face-to-face
> meetings, but we should also have a wider discussion, as this is affecting
> many more people than those who will have the opportunity to be at these
> meetings.

let's just be careful with the definition of "wider". we need a representative 
sampling of people from across KDE's community in terms of skill levels, needs 
and perspectives (e.g. casual developer, core developer, sys admin, writers of 
the commit digest ..). we don't need every possible individual involved, 
however. as such, if we do these discussions at Platform 11 and then again at 
BDS, and document results as we go, we probably will reach that level of 
coverage.

we don't need everyone involved, we just need the various points of view and 
needs represented. as such, i do think the F2F meetings are likely to suffice.

-- 
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/20110519/3bb68a00/attachment.sig>