Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.25-pre1-18-g20a4340

[Ed W <lists@xxxxxxxxxxxxxx>]

Hi

>> Create a new branch for the next version and
>> hack away on new confidence calculations in there.  Remember that if you
>> checkin a bug fix it's trivial to "pull" that to all release branches
>> (ie git makes it easy to maintain 1.1.x and 1.2.x and 1.3.x, where bug
>> fixes get easily pulled into all relevant branches in one hit!)
> 
> Yes, git is very good at branching, but sometimes the patch can't be
> applied cleanly and has to be backported. The time I can spend on
> chrony is quite limited, I'd rather keep working only in one branch.
> Are you willing to maintain a "super stable" branch?

Your email address shows that you most likely know more about this than
I, however, my experience is that with git the code has to diverge quite
substantially before patches are tricky to back/forward/sideways port?

Obviously by this I mean where there isn't divergent development on one
piece of code, but to be fair, in that instance it's not really a
backport of a fix if it's a fix to some new development?  So lets limit
our scope to pure linear evolutions of a chunk of code

My point is more that (whilst there is more than one) a good development
strategy seems to be to use "releases" to introduce new features, then
feature freeze that branch and continue development on new features in
the next feature branch (google "git feature branches" for a bunch of
various ways of expressing the same idea).  This seems to work well for
users because the feature set gets nailed down and from then on only bug
fixes appear

Surely Redhat is a model of such a release strategy?  You release
Version X, then only bug fixes appear for that release while development
continues in parallel on Version X+1.


Anyway, I'm very grateful for your development work on Chrony - my point
is simply if you haven't already experimented with using a "feature
branch" kind of development strategy in git then please do try it.  I
think it will work well on almost any sized project?  Roughly speaking
it's just: fork, stabilise, fork stabilise, etc.

With this strategy, if you need a bug fix then apply to the *earliest*
common tree, then pull from that tree into all subsequent branches to
get the fix rippling up. I asked the aufs developer recently and he uses
exactly this to maintain his kernel patch against multiple kernel
versions with relatively little work.



> I hope we'll get 1.25-pre2 out next week and if nothing bad shows up
> we can make final 1.25 a week or two after that.

Cool - I keep trying to plug chrony when I can, and the conversation
then starts to become - ahh yes, checkout the git version, build that...
Sadly this spoils the plug quite a bit...


> I'm not really sure that chrony is a good candidate for that. It's
> small, slowly moving (the average commit rate since last release is
> only about 10/month) and all releases should be stable, we surely
> don't want to release a misbehaving NTP client or unreliable server.

Disagree that it isn't a good fit, and strongly agree that the goal is
to keep things stable.  I have obviously mis-explained, but please give
it a bit more thought because the whole idea is to reduce the
possibility of releasing an unstable version, not increase it.

To rephrase in yet another way: instead of developing in the master
branch (which I claim is what is currently done), instead develop in one
or more side branches and then when the feature is stable, pull into
master. Generally this keeps master *more* stable (not less) and gives
you more freedom to checkin ideas willy nilly.

Anyway, these are just ideas and opinions, use whatever suits, just
checking you had come across the principle - it works very nicely for me
(and many others)!!

Thanks again and good luck

Ed W

---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.