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

[Ed W <lists@xxxxxxxxxxxxxx>]

On 18/04/2011 12:23, Miroslav Lichvar wrote:

> It would be interesting to try to apply only the bugfixes made since
> 1.24 to a 1.24.1 branch and see how far it would go without conflict.

I think my follow on caveat was something like: if it doesn't apply
reasonably cleanly, then probably it's no longer a bug fix that applies
to the 1.24 branch anyway?

ie if you substantially modify the code, then discover a bug, probably
the fix is no longer relevant to the original code (in many situations)

So, I would still claim that bug fixes roll forwards and backwards
fairly easily in general.  The trick is simply to initially apply to the
oldest common branch and then pull forwards through the remaining
branches - this causes the fix to ripple up with fewest chances for a
collision


>> 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 see. They can download tarballs from gitweb though, no need to use
> git.

Hmm, I think there is a big gulf between those who use something other
than the packaged version they can get from some repository and those
who compile their own code?  Once you are into the "compile your own",
then I think there is little difference between those who can unpack a
tar ball and those who can download git?

There is big resistance in the user community to use anything other than
packages I think?

So the key thing is to get packaged versions into repos, and this
generally seems to mean "labelled" or "released" code versions (yes I
get that Redhat, et al could package an arbitrary git commit, but this
seems not to happen in general?)

Plus "releases" are a good reason to post a news article, which in turn
attracts project interest and feedback...  Can I recommend a blog post
on release and pushing it up to the usual geek news sites?

:-)


> I try to keep it always "stable" and when a larger feature is
> being implemented, I play with it in my private repo until I feel it's
> good enough and push it all at once.


Sure - just note that the main goal is to avoid "developing in master"
though.

I think a specific example would be your ideas on "weighting".  A nice
technique right now (since we are close to a release) would be to
deliberately branch the pre-release code, get that stable and continue
the weighting ideas in a separate branch.  If that stabilises in a way
that's suitable for release then for sure push it back to the
pre-release branch, if not then it continues on it's way to make 1.26,
and you now have two HEADs that you can develop against, one stable, one
development. Cool!

I'm sure I'm teaching you to suck eggs, but "git cherry" and "git
cherry-pick" are both great ways to compare branches and pull commits
each way.

Another idea I played with was using git rebase to transplant a master
branch back onto a predecessor branch (the difference from a merge is
that you keep all the individual commits).  This works fairly well,
although needs some reading of the man pages to get the command correct.
 eg consider doing some development on master to create a "weighting"
feature, then wanting to transplant all those individual commits back to
the release branch that you had previously forked.


Apologies since we are way OT now...

How are we looking for a release at this point though?!

Cheers

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.