qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: M3 Freeze
Date Tue, 05 Aug 2008 18:23:16 GMT
The general practise (as seen in other apache projects and in general) is
not to freeze the trunk.
The java client will also have some clustering related changes to go along
with Alans stuff on C++.
If need be these changes can be kept in a local copy btw the freeze and
release, but having read Alans comments I agree with him that a branch is
probably a better and safer option.



On Tue, Aug 5, 2008 at 1:56 PM, Alan Conway <aconway@redhat.com> wrote:

> On Tue, 2008-08-05 at 15:06 +0100, Aidan Skinner wrote:
> > On Tue, Aug 5, 2008 at 2:41 PM, Alan Conway <aconway@redhat.com> wrote:
> >
> > > What I recall us saying is "don't until you really need one". We need
> > > one if there is any post-M3 work going on during the freeze. I'm
> working
> > > on clustering code that is well decoupled but still poses a risk of me
> > > breaking the C++ broker. There may be others working on post-M3 work as
> > > well.
> >
> > Is that something you need to land before M3 goes out? I guess ideally
> > you'd be doing this on a feature branch that tracks trunk, probably
> > easier with git than svn though. :/
> I'm doing small incremental merges. The new functionality does nothing
> unless explicitly enabled so it doesn't interfere with non-cluster use
> of the broker. I prefer incremental merges to trunk (or some shared
> post-M3 branch) so that my code gets continuously integrated with any
> other work that is going on.
> > > I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> > > merging M3 to trunk as we go. The alternative is to use trunk for M3
> and
> > > create a post-M3-branch but that seems backwards to me.
> >
> > If you have to commit your stuff in the weeks between freeze and
> > release then yeah, that makes sense.
> The other advantage of an M3 branch over a frozen trunk is that it's
> unlikely anyone will accidentally commit post-M3 changes to an explicit
> M3 branch, which is always a risk with the trunk.
> Cheers,
> Alan.


Rajith Attapattu
Red Hat

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message