reflecting on 4.10

[Aaron J. Seigo]

On Saturday, January 12, 2013 17:01:40 Alex Fiestas wrote:
> This is my opinion now (no longer what I remember from the sprint).
> 
> On Saturday 12 January 2013 15:54:39 Aaron J. Seigo wrote:
> > On Saturday, January 12, 2013 14:08:44 Alex Fiestas wrote:
> > > -Master
> > > -Integration
> > 
> > this is what we are doing now in plasma-mobile. it has taken a bit to get
> > used to (mostly for me doing the integration branch; we were already using
> > branches heavily). i think it is working pretty well. i blogged about this
> > recently, in fact :)
> > 
> > it should come as no surprise but i'm very much in favour of this model
> > and
> > would love to see it tried in kde-workspace as well.
> > 
> > this would require buy-in from kwin, plasma, system settings, powerdevil,
> > etc. developers. but i think we can get that with a bit of communication.
> > 
> > the only way this works, however, (in addition to the communication you
> > covered in your email) is if someone is actively managing the integration
> > branch and if we developers use that branch on a regular basis.
> 
> Imho there should be a group of people managing integration we should not
> depend on a single person in almost anything.

what i've found in practice is that having more than one person doing the 
actual merges would be rather difficult. it's much, much easier if one person at 
a time is looking after it.

that does mean we could (and should, i agree) have multiple people who are 
marked as "the integration branch maintainers". but probably only one at a 
time should be active (they can certainly hand the "merge token" between 
themselves")

what i've ended up doing for plasma-mobile is:

* have a small text file listing all branches currently being merged and any 
cherry-picked commits (ran into the need for this once already with a critical 
fix, without which integration branch wasn't very usable)
* branch merge requests are made on the mailing list (would like a nicer tool 
for this, tbh)
* merges are updated at least every monday (more often for a given branch on 
request)
* when branches are merged into master (because they've passed whatever 
testing set out as required) i send an email to the list noting what has been 
merged into master and what is still being merged into integration

as we don't have force pushes available to us, i have to occassionally delete 
the integration branch and re-branch it from master. this is fine, though, as 
no work is ever done directly in this branch. it's just a merge target.

some variation on the above, along with some tools to improve certain aspects 
of it (esp the integration branch merge requests) would be good.

i find it only takes a small amount of time each week to actually do the 
merging and such. obviously testing and oversight of feature applicability is 
what takes most of the time, but that is split amongst all the developers, not 
just the integration branch maintainer.

> Also, the branch should be stable enough so all distros can have a repo with
> daily packages of it and promote their usage (not just saying oh look we
> have snapshots but it may kill kitties).

absoultely. before branches are merged into integration they have to be deemed 
"possibly ready for shipping" by the developer. so integration can be broken, 
but it should only be a bit broken. master should represent current 
development status, but should never have any serious breakage in it.

-- 
Aaron J. Seigo
-------------- 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/plasma-devel/attachments/20130112/33b2acd9/attachment.sig>