3:11 a.m.
I think we should leave the current CVS-style branching model and make
better use of Git.
'master' is currently two things: The development branch, and getting
in the way it's an abandonware repository: slapmodify, vc, etc.
Maybe that's harsh, but if it is not abandonware, why are the authors
not finishing it so it can be released? Some of it is years old.
The justification for keeping a bunch of features under development in
master instead of feature branches was to get more eyes and testers for
them. Well, OK, if the features were underway to be finished and
released. But that's not working out.
So I suggest we reclassify such code as abandonware and throw it out of
master. Maybe except code behind #ifdef LDAP_DEVEL which is safe to
include in releases. If this prompts someone to finish some code so it
can be released, great. Otherwise the reclassification is correct.
The code is still in the repo. Someone can recreate it as a feature
branch if they care. If some is for RE25, let's make a RE25 branch.
If we are going to keep avoiding feature branches and put unfinished
stuff in the devel branch, well OK, limited to code which _will_ get
released soon and code behind #ifdef LDAP_DEVEL which can be in releases
anyway. Otherwise after a while send the author a nastygram, revert the
code, maybe re-revert it into a feature branch so it's not forgotten.
We can still have a branch with all such unfinished code: See the 'pu'
branch in the gitworkflows(7) manpage. It merges the feature branches.
RE25 above could be another such branch of merged features.
Another issue is that we sometimes want a quick release - normally for a
regression in last release - but OPENLDAP_REL_ENG_2_4 is not in shape to
be released. So we wait, or end up with a quicka release wich is a
bugfix release with some other hopefully-OK code.
So, something like the following:
- 'maint' branch: Planned releases, like today's OPENLDAP_REL_ENG_2_4.
- Temporary 'hotfix' or 'itsNNNN' branches, branched off last release:
Quick unplanned releases, when 'maint' is not in shape to be released
quickly. After release, merge the branch into 'maint' and delete it.
- Some sort of 'devel' branch, branched off 'maint' and current
'master', merging 'maint' after releases.
Like to today's 'master' but without unfinished features other than
code behind #ifdef LDAP_DEVEL. That way it can be merged into maint
now and then (like before a release), which has to be easier than
cherry-picking all the time.
- Feature branches for long-lived unfinished features. Merged into 'pu'
below, and hopefully eventually into the other branches.
- 'pu', branching off 'devel' and merging the feature branches, so it
looks like today's 'master'. Needs to be thrown away and recreated
now and then to avoid clutter.
'maint' or 'devel' above would be named 'master'. I don't care
which.
Completed feature branches can merge into the branch they branched off.
A feature branched off devel cannot merge into maint, since it'd drag
devel features with it. So it'd be really nice to keep merging devel
into maint now and then, instead of cherry-picking.
One final issue, I'd like to get rid of the clutter of old branches and
tags from CVS which are no longer of any use. Either delete them, or
rename to refs/archive/<heads,tags>/<name>. 'git clone' without
'--mirror' will not clone these.
--
Hallvard
3:40 a.m.
I wrote:
- Some sort of 'devel' branch, branched off 'maint'
and current
'master', merging 'maint' after releases.
Like to today's 'master' but without unfinished features other than
code behind #ifdef LDAP_DEVEL. That way it can be merged into
maint
now and then (like before a release), which has to be easier than
cherry-picking all the time.
Er, s/before/after/ a release:-)
--
Hallvard
10:47 a.m.
--On Tuesday, January 31, 2012 12:11 PM +0100 Hallvard Breien Furuseth
<h.b.furuseth(a)usit.uio.no> wrote:
I think we should leave the current CVS-style branching model and
make
better use of Git.
'master' is currently two things: The development branch, and getting
in the way it's an abandonware repository: slapmodify, vc, etc.
Maybe that's harsh, but if it is not abandonware, why are the authors
not finishing it so it can be released? Some of it is years old.
Abandonware? What are you talking about? Both of those, AFAIK, are 2.5
features, which is why they haven't been released. Some things have been
in there for years because 2.4 has been the release branch for years (2007)
and there has been very little 2.5 development that necessitates a 2.5
release. Last I checked the roadmap for 2.5, it hadn't been updated in
ages, and there has been very little development of the features listed on
it in any case.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
2:59 p.m.
Quanah Gibson-Mount wrote:
--On Tuesday, January 31, 2012 12:11 PM +0100 Hallvard Breien
Furuseth
<h.b.furuseth(a)usit.uio.no> wrote:
> I think we should leave the current CVS-style branching model and
> make better use of Git. 'master' is currently two things: The
> development branch, and getting in the way it's an abandonware
> repository: slapmodify, vc, etc. Maybe that's harsh, but if it is not
> abandonware, why are the authors not finishing it so it can be released?
> Some of it is years old.
Abandonware? What are you talking about? Both of those, AFAIK, are 2.5
features, which is why they haven't been released.
Aha, I hadn't caught that. I remember slapmodify (or the companion LDIF
api?) is buggy and had the distinct impression that this is well known.
I may have been thinking of contrib:ucn rather than contrib:vc.
<grepping...> a note from hyc @ irc: "ITSs against it [usn] should be
discarded since we already know it's not meant to be used". WTF...
Anyway, why can't slapmodify, <libldif replacement>, vc be finished and
go in RE24? contrib/ stuff does not get in the way, but companion
libldap/slapd differences beween master and RE24 do. They get in the
way of testing, cherry-picking etc.
Some things have
been in there for years because 2.4 has been the release branch for
years (2007) and there has been very little 2.5 development that
necessitates a 2.5 release. Last I checked the roadmap for 2.5, it
hadn't been updated in ages, and there has been very little development
of the features listed on it in any case.
People have been mentioning a switch to RE25 now and then, but does this
mean Re25 is not happening soon anyway? Even if it does though, I
suspect it'll be a while before RE25 reaches Stable level. So these
RE24 vs master diffs will still be sitting there in the repo.
--
Hallvard
3:22 p.m.
--On Tuesday, January 31, 2012 11:59 PM +0100 Hallvard Breien Furuseth
<h.b.furuseth(a)usit.uio.no> wrote:
Quanah Gibson-Mount wrote:
> --On Tuesday, January 31, 2012 12:11 PM +0100 Hallvard Breien Furuseth
> <h.b.furuseth(a)usit.uio.no> wrote:
>
>> I think we should leave the current CVS-style branching model and
>> make better use of Git. 'master' is currently two things: The
>> development branch, and getting in the way it's an abandonware
>> repository: slapmodify, vc, etc. Maybe that's harsh, but if it is not
>> abandonware, why are the authors not finishing it so it can be released?
>> Some of it is years old.
>
> Abandonware? What are you talking about? Both of those, AFAIK, are 2.5
> features, which is why they haven't been released.
Aha, I hadn't caught that. I remember slapmodify (or the companion LDIF
api?) is buggy and had the distinct impression that this is well known.
I may have been thinking of contrib:ucn rather than contrib:vc.
<grepping...> a note from hyc @ irc: "ITSs against it [usn] should be
discarded since we already know it's not meant to be used". WTF...
Anyway, why can't slapmodify, <libldif replacement>, vc be finished and
go in RE24? contrib/ stuff does not get in the way, but companion
libldap/slapd differences beween master and RE24 do. They get in the
way of testing, cherry-picking etc.
There's a point at which a release tree is "feature frozen", and generally,
new features are not to get added into it, although we certainly break this
rule fairly regularly (delta-syncrepl, back-mdb both immediately come to
mind). But if we pulled everything we've done in the master branch to
RE24, then we'd have nothing to show for RE25 so far. ;)
In any case, whether or not to pull those things into RE24 from the master
repository is generally Howard's call as Chief Architect.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
3:54 p.m.
Hallvard Breien Furuseth wrote:
Aha, I hadn't caught that. I remember slapmodify (or the
companion LDIF
api?) is buggy and had the distinct impression that this is well known.
I may have been thinking of contrib:ucn rather than contrib:vc.
<grepping...> a note from hyc @ irc: "ITSs against it [usn] should be
discarded since we already know it's not meant to be used". WTF...
The usn overlay was committed as-is but was not completed; at the time of
writing we had no complete spec for usn behavior. I think complete specs have
turned up since then, but it hasn't been a high enough priority for me to go
back and finish it, and no one else has bothered to look at completing it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:26 a.m.
Oh well, sorry about the abandonware stuff. Getting back to the
more prosaic subject, I do think it'd be better to do more coding
in a branch off RE24 than off master - except stuff intended for
RE25 in the first place. Or code which starts intended for RE24
but ends up waiting for RE25, which is maybe what I remember as
abandonware:-(
Once everything intended for RE24 is in the RE24 branch, we can
merge that branch (or its descendant maintenance branch) to
master but not the other way around, and the code can hopefully
be merged instead of cherry-picked into RE24.
Also holding the door open for 'hotfix' branches should help, and
killing old CVS branches, like mentioned in the original mail.
--
Hallvard
5:18 a.m.
On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:
Oh well, sorry about the abandonware stuff. Getting back to the
more prosaic subject,
First, whether to use a back-port or a forward-port model has nothing to do with git(1) v.
cvs(1). Both revision control systems support both models.
Back-port is basically: apply to trunk and back port to releases as needed. (If a bug is
only in X and older releases, then apply to X branch and back port from there.) You never
forward port in the back-port model.
Forward-port is any model which requires forward porting. There's variants here, some
of which also require back-porting.
I do think it'd be better to do more coding
in a branch off RE24 than off master - except stuff intended for
RE25 in the first place.
The back-port model is generally better in my opinion. It effectively eliminates the risk
of regression that is high in any forward port model.
Your suggestion will lead to regressions and hence, IMO, bad. It's also messy, time
consuming, and error prone from a release engineering stand-point.
It is important for the release engineer to control what goes into release branches. If
you code off the release branch, then the release engineer has to be involved early and
frequently. It is far easier to do "batched" release engineering but forward
porting models are incompatible with "batched" release engineering.
As far as branching is concerned, my only recommendation is to avoid 'feature'
specific development branches in the main repo. Instead, personal (but shared) repos can
be used. If appropriate, we can even host these on openldap.org. But even these
don't really cause any release engineering issue and hence shouldn't be a big
concern. It might be nice to archive these (and the old non-release CVS branches) once
they are no longer in use, just to reduce the noise. Personally, I prefer not to archive
old release branches (as I find them useful long after they are closed).
But, in general, I advocate leaving well enough alone... especially if it not helping our
release engineers (or worse, will cause release engineering pain).
-- Kurt
Or code which starts intended for RE24
but ends up waiting for RE25, which is maybe what I remember as
abandonware:-(
Once everything intended for RE24 is in the RE24 branch, we can
merge that branch (or its descendant maintenance branch) to
master but not the other way around, and the code can hopefully
be merged instead of cherry-picked into RE24.
Also holding the door open for 'hotfix' branches should help, and
killing old CVS branches, like mentioned in the original mail.
--
Hallvard
7:18 a.m.
On Fri, 10 Feb 2012 05:18:58 -0800, Kurt Zeilenga <kurt(a)OpenLDAP.org>
wrote:
On Feb 1, 2012, at 9:26 AM, Hallvard B Furuseth wrote:
> Oh well, sorry about the abandonware stuff. Getting back to the
> more prosaic subject,
First, whether to use a back-port or a forward-port model has nothing
to do with git(1) v. cvs(1). Both revision control systems support
both models.
Yesno. The difference is partly that Git supports consistent branches,
but more that it suppors sane merges. Which makes it more of a win
than
in CVS to arrange things so we can use merge or fast-forward instead of
cherry-picking.
(...)
> I do think it'd be better to do more coding
> in a branch off RE24 than off master - except stuff intended for
> RE25 in the first place.
The back-port model is generally better in my opinion. It
effectively eliminates the risk of regression that is high in any
forward port model.
If you say so, but why port to/from master instead of a branch off
RE24?
Porting between more different code bases introduces more risk. We
don't have an active RE25 to port back from or forward to. Currently
master is just RE24 + some code which will someday in the future be
used
after cleaning it up and maybe still porting it (and other things) to
whatever RE25 will look like.
Your suggestion will lead to regressions and hence, IMO, bad.
It's
also messy, time consuming, and error prone from a release
engineering
stand-point.
It is important for the release engineer to control what goes into
release branches. If you code off the release branch, then the
release engineer has to be involved early and frequently.
Er, I may have left out the RE24 branch itself:-( I tried to keep
excessive branches out of the suggestion, that got a bit too far.
I'd certainly prefer to code in a branch off RE24 and not in RE24
itself. An in any case to revert stuff which gets into that branch but
can not be released (yet). Or at least wrap that in #ifdef LDAP_DEVEL.
Then the release engineer can hopefully just fast-forward or merge into
RE24, but he doesn't have to. And we'd hopefully learn discipline
enough to not just throw half-finished stuff into it. That's for the
current master branch.
I don't see what's messy about that. It'd be messy if people put code
there just "get more eyes on it" as in master today, then this branch
would turn into just what master has been at times: A branch with a
bunch of as-yet unreleased code which someone someday might finish.
And having two different branches like that would indeed be messier.
As far as branching is concerned, my only recommendation is to avoid
'feature' > specific development branches in the main repo. Instead,
personal (but shared) > repos can be used. If appropriate, we can even
host these on openldap.org.
IIRC there's always been a fair amount of code in master just sitting
there unfinished. Commit messages like "this is a preliminary code
drop", and then maybe sometime later it gets finished. If people will
be content to keep such things in separate repositories, fine. That's
a lot easier with Git than with CVS.
But if the author wants to push it to the main repo to get more eyes on
testers for the code, which IIRC was one reason for keeping the current
arrangement, then I'd much rather see it in a feature branch.
(Also I assumed merging feature branches would also tend to be easier
than porting between branches, but I haven't tried that myself yet.)
In any case, two branches (maint and hotfix) off RE24 is the main
thing I'd like, feature branches seem less important.
(...) It might be nice to archive these (and the old non-release
CVS branches) once they are no longer in use, just to reduce the
noise. Personally, I prefer not to archive old release branches
(as I find them useful long after they are closed).
Renaming to refs/archive/<heads,tags>/* reduces the noise but still
keeps them in the repo. I think
git config --add remote.origin.fetch
'refs/archive/*:refs/archive/*'
will get those symbols in addition to the rest.
But, in general, I advocate leaving well enough alone... especially
if it not helping our release engineers (or worse, will cause release
engineering pain).
Actually helping out with that was one thing I hoped this would do.
--
Hallvard
8:34 a.m.
On Feb 10, 2012, at 7:18 AM, Hallvard B Furuseth wrote:
Then the release engineer can hopefully just fast-forward or merge into
RE24, but he doesn't have to.
Bullshit. If we were to follow your suggestion, the release engineer will have not only
deal with patches nominated for review, but deal with all patches, reverting those not
ready for release... and then, if subsequently nominated/approved for release,
cherry-pick them again onto the branch.
Or other such mucking. It's not 'just' fast-forward or merge.
And we'd hopefully learn discipline
enough to not just throw half-finished stuff into it.
That's likely never to happen.
Developers need a branch to collective play with stuff not yet ready for release.
That's for the
current master branch.
Master is currently that playground (unless the patch is far too playful, in which case
they should do it in another repo).
I don't see what's messy about that. It'd be messy if
people put code
there just "get more eyes on it" as in master today, then this branch
would turn into just what master has been at times: A branch with a
bunch of as-yet unreleased code which someone someday might finish.
And having two different branches like that would indeed be messier.
You are not going to magically change the development culture of any project overnight.
> As far as branching is concerned, my only recommendation is to avoid
'feature' > specific development branches in the main repo. Instead, personal
(but shared) > repos can be used. If appropriate, we can even host these on
openldap.org.
IIRC there's always been a fair amount of code in master just sitting
there unfinished. Commit messages like "this is a preliminary code
drop", and then maybe sometime later it gets finished. If people will
be content to keep such things in separate repositories, fine. That's
a lot easier with Git than with CVS.
While git certainly makes it easier for more playful patches to be kept outside the main
repo, we've otherwise tried to keep really playful stuff out of the master... whether
by just saying 'no' or putting it on dev branches.
While git makes it easier for developers to play in smaller groups. and that reduce the
need to dev branches, I don't switching to git(1) as having changed our culture one
bit. Our developers still want a common place to put changes intended for non-immediate
(or non-next minor) release. That place is the master branch.
But if the author wants to push it to the main repo to get more eyes
on
testers for the code, which IIRC was one reason for keeping the current
arrangement, then I'd much rather see it in a feature branch.
Things also get pushed onto master so the community as a whole can further develop/test
the changes.
git(1) can lead one to many different islands of code. While that has some advantages at
times, it also has its draw backs.
In general, I think our approach has been balanced and should remain balanced. Use
islands where it makes sense, use main repo when it makes sense, use master in main repo
when it makes sense.
(Also I assumed merging feature branches would also tend to be
easier
than porting between branches, but I haven't tried that myself yet.)
Merging, in my view, is a form of porting.
In any case, two branches (maint and hotfix) off RE24 is the main
thing I'd like, feature branches seem less important.
We've traditionally hot fixed on the latest branch the bug exists on. If the bug is
on RE24 but not master, you fix on RE24 directly. There's no need for a 'hotfix
branches'.
> (...) It might be nice to archive these (and the old non-release
> CVS branches) once they are no longer in use, just to reduce the
> noise. Personally, I prefer not to archive old release branches
> (as I find them useful long after they are closed).
Renaming to refs/archive/<heads,tags>/* reduces the noise but still
keeps them in the repo. I think
git config --add remote.origin.fetch 'refs/archive/*:refs/archive/*'
will get those symbols in addition to the rest.
> But, in general, I advocate leaving well enough alone... especially
> if it not helping our release engineers (or worse, will cause release
> engineering pain).
Actually helping out with that was one thing I hoped this would do.
I don't see how your suggestions help release engineers, especially in absence of
change of development culture or 'discipline'.
--
Hallvard
4063
days inactive
4073
days old
9 comments
5 participants
participants (5)
-
Hallvard B Furuseth -
Hallvard Breien Furuseth
-
Howard Chu -
Kurt Zeilenga -
Quanah Gibson-Mount