on the impending gittness of our source code

[Aaron J. Seigo]

On Monday, December 13, 2010, Ben Cooksley wrote:
> On Tue, Dec 14, 2010 at 2:21 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > * have a staging repository where bug fixes land and feature branches are
> > merged into. this is what most of us will use for day-to-day testing and
> > usage
> 
> Sysadmin has not reached an internal decision on how to handle team
> clones at this time. If you do decide that you want to follow this
> path, please let us know so that we can agree internally on how to
> handle them.

will do. how much of a pain is it for sysadmin to support team clones?

> > * use the "main" repository in git.kde.org for release only; staging will
> > get merged in on a regular basis (e.g. when we are happy with the
> > results)
> 
> How regular will the merging be? 

no merges from staging during feature / string freezes (for obvious reasons :)

otherwise, the merges will happen fairly regularly. worst case scenario would 
be once a month, but i'm hoping to do these merges either weekly or bi-weekly. 
we're still working out workflow issues as you can see :)
 
> Also, will this allow normal KDE developers to pickup the latest bug
> fixes, features, etc as usual?

they can either follow the staging branch which will have fewer guarantees of 
being "always releasable" or stable which will lag by a bit but generally be 
more suitable for daily use.

an alternative is to copy what we're doing now with svn and have mainline be 
"staging for next release" and a branch for each past release. however, this 
makes it almost impossible to ensure an "always releasable" branch, since past 
release branches can't have new features or strings added and it is impossible 
to guarantee that the staging (or, if you prefer, integration) branch is 
stable.

the idea is to cater to two use cases:

* those who would like to follow devel for testing, but need a production 
system; right now svn trunk is still too unpredictable. the past release 
branches don't actually let them test new features.

* devices, where our release schedule is going to matter a hell of a lot less 
to them. :)

> How will this approach handle fixes
> done by non-Plasma developers which are trivial into main Plasma
> codebase (that which is released)?

i'd really prefer commits not be made directly into the release branch. it 
makes it rather difficult to ensure that it's always release quality. 
preferably, people will commit to the devel branch/repo.

that said, commits that aren't a result of a merge will be fairly obvious from 
the commit log :)

> > * a bug fix branch on the staging branch which would follow staging
> > (probably through regular rebasing) where bug fixes would go. these
> > would then be merged into staging and when that's proven itself, merged
> > into the release branch. alternatively, bug fixes could be done in
> > branches on release and when ready, merged into release and then into
> > staging? another alternative would be to do with cherrypicking bug fix
> > commits? my main goal is to make merging of bugfixes (which may be
> > several commits in total) easy and trouble-free. mixing them with
> > features is going to make life harder.
> 
> Rebasing involves force push, which is disabled on git.kde.org for
> obvious reasons... 

we could do bug branches like we do feature branches. which will result in a 
large number of branches; though i suppose those could be pruned after merged 
into release and staging? it would require some discipline in naming of the 
branches so they are easily identifiable, but that's not a big deal.

or we could have another team repository that clones release and use pulls to 
keep it in sync. but that seems like massive overkill.

i'm just very keen on keeping commits directly to the release branch _out_ of 
there.

-- 
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: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101213/fd7c17e1/attachment.sig