Branching

[Rafael Schloming <ra...@redhat.com>]

Hey Qpid-dev,

As you may know my employer recently released MRG 1.0 based on Qpid. I'm 
sure I speak for everyone at Red Hat when I say many thanks to all the 
contributors who have put in so much hard work on Qpid.

The packages we've released are built from the following revisions of trunk:

qpid/specs: 666398
qpid/python: 668378
qpid/gentools: 668333
qpid/java: 668333
qpid/cpp: 667603

RPMs for these revisions should be available through fedora as well.

I think it might be useful to create a branch against these revisions in 
Apache SVN, since they do represent a fairly stable cross section of 
trunk, and at some point if we have people who picked up qpid through 
fedora asking questions, it might be handy to be able to easily 
reference the code they are running.

I didn't want to just go ahead and do this though without checking if 
such a branch is appropriate and/or welcomed by the community. So if you 
have strong opinions on this, please let me know.

--Rafael

Re: Branching

[Rafael Schloming <ra...@redhat.com>]

Robert Greig wrote:
> 2008/7/3 Rafael Schloming <ra...@redhat.com>:
> 
>> As you may know my employer recently released MRG 1.0 based on Qpid. I'm
>> sure I speak for everyone at Red Hat when I say many thanks to all the
>> contributors who have put in so much hard work on Qpid.
> 
> Congratulations!
> 
>> I think it might be useful to create a branch against these revisions in
>> Apache SVN, since they do represent a fairly stable cross section of trunk,
> 
> Do you mean a branch or really just a tag? Do you plan on patching on
> that branch?

I would think a branch would be more useful so that we can put any 
critical bug fixes on it rather than hold them as patches inside an RPM.

>> and at some point if we have people who picked up qpid through fedora asking
>> questions, it might be handy to be able to easily reference the code they
>> are running.
> 
> I don't have a problem with this. Transitively, MRG usres are qpid
> users. Are you planning on doing a MRG 1.1. release to reflect Apache
> M3 or are you not going to attempt to track the Apache releases?

We're definitely going to try to track Apache releases, although I don't 
know if our 1.1 will line up with M3 or M4.

--Rafael

Re: Branching

[Robert Greig <ro...@gmail.com>]

2008/7/3 Rafael Schloming <ra...@redhat.com>:

> As you may know my employer recently released MRG 1.0 based on Qpid. I'm
> sure I speak for everyone at Red Hat when I say many thanks to all the
> contributors who have put in so much hard work on Qpid.

Congratulations!

> I think it might be useful to create a branch against these revisions in
> Apache SVN, since they do represent a fairly stable cross section of trunk,

Do you mean a branch or really just a tag? Do you plan on patching on
that branch?

> and at some point if we have people who picked up qpid through fedora asking
> questions, it might be handy to be able to easily reference the code they
> are running.

I don't have a problem with this. Transitively, MRG usres are qpid
users. Are you planning on doing a MRG 1.1. release to reflect Apache
M3 or are you not going to attempt to track the Apache releases?

RG

Re: Branching

[Alan Conway <ac...@redhat.com>]

On Fri, 2008-07-04 at 12:14 +0100, Marnie McCormack wrote:
> All,
> 
> I'd like to echo the congratulations of the two Roberts !
> 
> Likewise am happy for a branch or a tag to be created. Note that we're
> investing time in fixing up trunk (client working with broker and suchlike
> :-) so we can work together there going forward. Thus a minor plea for any
> fixes applied to branches etc to be merged down there as appropriate. I am
> definitely not on the moral high ground here ......


+1 to that plea. Fixes should always be merged from branch to trunk
unless the relevant code in trunk has changed too much for the fix to be
relevant. 

(If we ever get to multi-level branching we should merge from child
branch to parent branch recursively up to trunk. Pray we never get
there ;)

Re: Branching

[Marnie McCormack <ma...@googlemail.com>]

All,

I'd like to echo the congratulations of the two Roberts !

Likewise am happy for a branch or a tag to be created. Note that we're
investing time in fixing up trunk (client working with broker and suchlike
:-) so we can work together there going forward. Thus a minor plea for any
fixes applied to branches etc to be merged down there as appropriate. I am
definitely not on the moral high ground here ......

Bfn,
Marnie



On 7/4/08, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>  In future I think it would be good if you can tie
>> your commercial releases to Apache releases...
>>
>>
>>
>
> ack, if we go to faster schedule for M releases then this becomes easier
> for anyone redistributing :-)
>
> Carl.
>

Re: Branching

[Carl Trieloff <cc...@redhat.com>]

>  In future I think it would be good if you can tie
> your commercial releases to Apache releases...
>
>   

ack, if we go to faster schedule for M releases then this becomes easier
for anyone redistributing :-)

Carl.

Re: Branching

[Robert Godfrey <ro...@gmail.com>]

2008/7/3 Rafael Schloming <ra...@redhat.com>:
> Hey Qpid-dev,
>
> As you may know my employer recently released MRG 1.0 based on Qpid. I'm
> sure I speak for everyone at Red Hat when I say many thanks to all the
> contributors who have put in so much hard work on Qpid.
>

I add my congratualtions to those from Robert :-)

> The packages we've released are built from the following revisions of trunk:
>
> qpid/specs: 666398
> qpid/python: 668378
> qpid/gentools: 668333
> qpid/java: 668333
> qpid/cpp: 667603
>
> RPMs for these revisions should be available through fedora as well.
>
> I think it might be useful to create a branch against these revisions in
> Apache SVN, since they do represent a fairly stable cross section of trunk,
> and at some point if we have people who picked up qpid through fedora asking
> questions, it might be handy to be able to easily reference the code they
> are running.

I'm happy with a tag or a branch - whatever you think is
appropriate... I guess the choice depends on whether you are planning
to backport patches and the like from maintenance releases that you
create downstream.  In future I think it would be good if you can tie
your commercial releases to Apache releases...

> I didn't want to just go ahead and do this though without checking if such a
> branch is appropriate and/or welcomed by the community. So if you have
> strong opinions on this, please let me know.
>

-- Rob
>