Hi folks,
co-incidentally, CVS has just begun to give me some pain last Friday,
when it came to actually working with the different branches I now have.
And a rainy Sunday made my have a deep look at the git manual. End
result: I won't wait 10 weeks from now but have started to finally
convert. I have pulled Michael Biebl's git repository, which he
thankfully kept synchronized with the CVS. I am doing some final checks
right now, but as it looks we will be using git from now on. Rsyslog is
available from Adiscon's gitweb:
http://git.adiscon.com/
It can also be pulled via git protocol. Please keep in mind that it may
receive some more finishing touches.
I will now have four active branches:
- v2-stable
- v3-stable
- beta -- what becomes the next release of v3-stable
- master -- the current (b)leading development edge
There is also v1-stable, which is deprecated and a few legacy branches.
As suggested by Raoul and Michael, I'll now begin to work with
feature-branches (as soon as I have finished current work in progress).
I am new to git and I may mess up things. Bear with me if I do ;)
Please note that I am still working on the initial setup, so if you pull
the repository now, you may need to pull it again some time later ;) If
I mess up, I'll let you know via the mailing list.
I hope this will be a good move. Special thanks to Michael and Raoul,
who were persistent enough to finally made me move (and, well, to CVS
which provided the final bit of motivation ;)).
Rainer
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, April 04, 2008 12:18 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog version numbering
>
> OK, let me come to a conclusion ;)
>
> What Michael writes and Raoul suggested makes an awful lot of sense.
> Right now, I have two problems:
>
> a) we are still having a bit of trouble with the git transistion of
> rsyslog - I hope to have that sorted out soon
> b) I need to invest some time to fully understand how git branches.
>
> The bigger problem is probably b). Thankfully, I have started to work
> with git on librelp and it was a very good experience. It still looks
> like I need to invest at least a day or two more into getting fully
> involved with it. That doesn't sound much, but there is a lot I can do
> in rsyslog in this time.
>
> I think I will proceed as follows:
>
> For the next few weeks, I'll use the scheme that I outlined this
> morning. It works and it is sufficiently clean for the time being.
> Especially as I don't see any reason for gaps, there is no such major
> overhaul in sight.
>
> While I do so, I'll get more acquainted to git and see how I can make
> utilize its branching capabilities. At some point in time (and if
> everything works as well as advertised, what I assume ;)), I'll switch
> to the git feature branch strategy. My hope is all this can be done in
> the next 10 weeks or so.
>
> I hope I don't disappoint anyone - but the problem is things to do.
All
> needs to go by priorities and, quite honestly, TLS or the new config
> file format is higher on my priority scale than the branching
strategy.
> And, yes, I know good knowledge with git will save in the long run.
But
> I need to start somewhere ;)
>
> I someone has serious concerns on the route I am taking, please scream
> now ;)
>
> Rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> > Sent: Friday, April 04, 2008 12:02 PM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] rsyslog version numbering
> >
> > 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > > 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > > >
> > > > > 999.2.0 - stable
> > > > > 999.3.x - big overhaul feature, stabilizing
> > > > > 999.5.x - .3 + next focus feature, stabilizing
> > > > > 999.7.x - .5 + next focus feature, stabilizing
> > > > > 999.9.x - devel
> > > > >
> > > > > Again... comments please ;)
> > > >
> > > > I think you really should try to use git feature branches for
> > that.
> > > > Have a stable and master (development) branch, and develop the
> > > > features in separate topic branches feature-A, feature-B etc.
> > > > Whenever one feature is ready, merge it into master.
> > > > This way, it doesn't matter which feature you have to
> concentrate
> > on
> > > > is released first (no skipped version numbers!).
> > > > The strong merge suppport in git would also allow to cherrypick
> > easily
> > > > from the different feature branches or merge between them.
> > >
> > >
> > > Sounds good, but a honest question (NOT trying to give a bias,
just
> a
> > > problem description):
> > >
> > > While I implement FocusFeatureX, I get Feature 1, 2, 3 requests
> and
> > > implement them - all while FocusFeatureX is being developed.
Where
> > do I
> > > apply these? And don't I get into trouble if that interferes with
> > things
> > > that I do in FocusFeatureX? Remember, I change a couple of
> hundered
> > > lines all over the project on a typical day...
> >
> > Say you work on a featureA branch. Now you get an unrelated feature
> > request for featureB.
> > You'd switch back to current master, and branch of featureB,
starting
> > to work on that.
> > By the end of the day, say featureB is ready, you'd merge those
> branch
> > back into master (and delete branch featureB if no longer required).
> > If featureC is dependend on featureA, you can branch from there. If
> > you now work again on featureA, and later on featureC, you can merge
> > the new commits from featureA back into featureC again.
> > Later, when featureA and C are ready, you merge them into master
> again.
> > For small changes, I'd directly work on master and commit there.
> There
> > is also a nice feature called git-stash, which allows to put
> > uncommitted changes away, work temporarily on other stuff, an get
> back
> > to the uncommited stuff later.
> >
> > I'd say, just test git and try to get a "feeling" for it. That
> > probably helps to make a better decision.
> >
> > Cheers,
> > Michael
> >
> >
> >
> > --
> > Why is it that all of the instruments seeking intelligent life in
the
> > universe are pointed away from Earth?
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
co-incidentally, CVS has just begun to give me some pain last Friday,
when it came to actually working with the different branches I now have.
And a rainy Sunday made my have a deep look at the git manual. End
result: I won't wait 10 weeks from now but have started to finally
convert. I have pulled Michael Biebl's git repository, which he
thankfully kept synchronized with the CVS. I am doing some final checks
right now, but as it looks we will be using git from now on. Rsyslog is
available from Adiscon's gitweb:
http://git.adiscon.com/
It can also be pulled via git protocol. Please keep in mind that it may
receive some more finishing touches.
I will now have four active branches:
- v2-stable
- v3-stable
- beta -- what becomes the next release of v3-stable
- master -- the current (b)leading development edge
There is also v1-stable, which is deprecated and a few legacy branches.
As suggested by Raoul and Michael, I'll now begin to work with
feature-branches (as soon as I have finished current work in progress).
I am new to git and I may mess up things. Bear with me if I do ;)
Please note that I am still working on the initial setup, so if you pull
the repository now, you may need to pull it again some time later ;) If
I mess up, I'll let you know via the mailing list.
I hope this will be a good move. Special thanks to Michael and Raoul,
who were persistent enough to finally made me move (and, well, to CVS
which provided the final bit of motivation ;)).
Rainer
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards
> Sent: Friday, April 04, 2008 12:18 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslog version numbering
>
> OK, let me come to a conclusion ;)
>
> What Michael writes and Raoul suggested makes an awful lot of sense.
> Right now, I have two problems:
>
> a) we are still having a bit of trouble with the git transistion of
> rsyslog - I hope to have that sorted out soon
> b) I need to invest some time to fully understand how git branches.
>
> The bigger problem is probably b). Thankfully, I have started to work
> with git on librelp and it was a very good experience. It still looks
> like I need to invest at least a day or two more into getting fully
> involved with it. That doesn't sound much, but there is a lot I can do
> in rsyslog in this time.
>
> I think I will proceed as follows:
>
> For the next few weeks, I'll use the scheme that I outlined this
> morning. It works and it is sufficiently clean for the time being.
> Especially as I don't see any reason for gaps, there is no such major
> overhaul in sight.
>
> While I do so, I'll get more acquainted to git and see how I can make
> utilize its branching capabilities. At some point in time (and if
> everything works as well as advertised, what I assume ;)), I'll switch
> to the git feature branch strategy. My hope is all this can be done in
> the next 10 weeks or so.
>
> I hope I don't disappoint anyone - but the problem is things to do.
All
> needs to go by priorities and, quite honestly, TLS or the new config
> file format is higher on my priority scale than the branching
strategy.
> And, yes, I know good knowledge with git will save in the long run.
But
> I need to start somewhere ;)
>
> I someone has serious concerns on the route I am taking, please scream
> now ;)
>
> Rainer
>
> > -----Original Message-----
> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> > bounces at lists.adiscon.com] On Behalf Of Michael Biebl
> > Sent: Friday, April 04, 2008 12:02 PM
> > To: rsyslog-users
> > Subject: Re: [rsyslog] rsyslog version numbering
> >
> > 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > > 2008/4/4, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > > >
> > > > > 999.2.0 - stable
> > > > > 999.3.x - big overhaul feature, stabilizing
> > > > > 999.5.x - .3 + next focus feature, stabilizing
> > > > > 999.7.x - .5 + next focus feature, stabilizing
> > > > > 999.9.x - devel
> > > > >
> > > > > Again... comments please ;)
> > > >
> > > > I think you really should try to use git feature branches for
> > that.
> > > > Have a stable and master (development) branch, and develop the
> > > > features in separate topic branches feature-A, feature-B etc.
> > > > Whenever one feature is ready, merge it into master.
> > > > This way, it doesn't matter which feature you have to
> concentrate
> > on
> > > > is released first (no skipped version numbers!).
> > > > The strong merge suppport in git would also allow to cherrypick
> > easily
> > > > from the different feature branches or merge between them.
> > >
> > >
> > > Sounds good, but a honest question (NOT trying to give a bias,
just
> a
> > > problem description):
> > >
> > > While I implement FocusFeatureX, I get Feature 1, 2, 3 requests
> and
> > > implement them - all while FocusFeatureX is being developed.
Where
> > do I
> > > apply these? And don't I get into trouble if that interferes with
> > things
> > > that I do in FocusFeatureX? Remember, I change a couple of
> hundered
> > > lines all over the project on a typical day...
> >
> > Say you work on a featureA branch. Now you get an unrelated feature
> > request for featureB.
> > You'd switch back to current master, and branch of featureB,
starting
> > to work on that.
> > By the end of the day, say featureB is ready, you'd merge those
> branch
> > back into master (and delete branch featureB if no longer required).
> > If featureC is dependend on featureA, you can branch from there. If
> > you now work again on featureA, and later on featureC, you can merge
> > the new commits from featureA back into featureC again.
> > Later, when featureA and C are ready, you merge them into master
> again.
> > For small changes, I'd directly work on master and commit there.
> There
> > is also a nice feature called git-stash, which allows to put
> > uncommitted changes away, work temporarily on other stuff, an get
> back
> > to the uncommited stuff later.
> >
> > I'd say, just test git and try to get a "feeling" for it. That
> > probably helps to make a better decision.
> >
> > Cheers,
> > Michael
> >
> >
> >
> > --
> > Why is it that all of the instruments seeking intelligent life in
the
> > universe are pointed away from Earth?
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog