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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.