As the saying goes, it's individuals not corporations that drive
projects at the ASF, and if you, as an individual project manager,
decide to make a milestone branch, why should this be an issue? We
all make releases when we think we need them. I don't see the
reason for needing the release as being all that important.
Whether Oracle does or does not need to use the branch seems irrelevent to me.
On 8/15/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> >
> > On 8/14/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > On 8/14/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > On 8/14/06, Adam Winer < [EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > For some of our internal, non-open source work here at Oracle,
> > > > > we're heavily depending on Trinidad (yay!). The catch is that,
> > > > > at certain points, we need a stable branch to build off of and
> > > > > apply only limited bug fixes so that internal work never gets
> > > > > destabilized.
> > > > >
> > > > > What I'd like to do is create branches in the Subversion repository
> > > > > for Trinidad code, with the following commitments:
> > > > > - No proprietary, non-Apache code will *ever* be checked in to
> > > > > such branches.
> > > > > - No work will happen on these branches that has not *first*
> > > > > been checked into trunk, with the possible exception of deeply
> > > > > hacky bug patches that wouldn't be wanted on a trunk.
> > > > >
> > > > > In other words, this will still be public work, and never even
> > > > > anything that could be construed as a fork in any way.
> > > > >
> > > > > Does this seem reasonable? Is it legit by Apache rules?
> > > > >
> > > > > All the alternatives I can think of are even less legit - e.g., we
> > > > > could make an internal copy of the source code, but that just
> > > > > reduces our exposure to the internal work and makes it less
> > > > > straightforward for us to hew to the true code on the trunk.
> > > >
> > > >
> > > > I went back and asked what we (Sun) do with various artifacts we
> > depend on
> > > > (such as bits from Tomcat). Back in CVS days (where a branch was
> > pretty
> > > > expensive), we did some Sun-specific tags when we grabbed a snapshot,
> > but
> > > > then we put that code in an internal mirror repository and did our
> > builds
> > > > against that (plus any point fixes that were necessary).
> > > >
> > > > In an Subversion world where branches like this would be really cheap,
> > I
> > > > don't see a problem as long as the other committers are OK with
> > it. But
> > > > hey, I work for a company that might like to be able to do this too
> > :-). It
> > > > definitely seems like something worth asking on the Incubator general
> > list
> > > > (so that it eventually ends up as guidance for new podlings) but
> > perhaps
> > > > more broadly as well because it certainly matters for existing
> > projects as
> > > > well.
> > > >
> > > > I'll ping a couple of appropriate aliases so we can get broader
> > feedback
> > > > on this.
> > > >
> > >
> > > OK, got some feedback, and it's going to be a -1 for two different
> > > categories of reasons:
> > >
> > > * Company private branches could potentially be
> > > construed as being in conflict with Apache's
> > > non-profit (501c3) status.
> > >
> > > * Private stabilization branches are considered by
> > > many folks to be bad engineering practice in the
> > > first place. See below for more on the advice of
> > > some of the Apache members.
> > >
> > > The advice on the practice side is to consider why we go through this
> > kind
> > > of stabilization exercise in the first place. We don't want to get
> > > destabilized by changes in the trunk code (or in a Maven snapshot we
> > depend
> > > on that suddenly changes underneath us). So, we try to control this
> > change
> > > by a snapshot where we control what goes in for a while, and then give
> > back
> > > the patches later.
> > >
> > > The HTTPD project tries to deal with this by having the project itself
> > > support two parallel development branches ... one for active development
> > > (the trunk as we know it today in most projects), and one that receives
> > > primarily bugfix support, and can serve as the dependency for downstream
> > > users because the rate of change *is* controlled. In addition, the
> > HTTPD
> > > group does the even/odd version numbers that we see in Linux to help
> > users
> > > distinguish what kind of stability to expect.
> > >
> > > If the Java projects we depended on all operated like this, we wouldn't
> > find
> > > the need for private stabilization branches so important. *Escpecially*
> > if
> > > the developers who work for the company producing the downstream product
> > > were committers on the Java project being depended on, they could
> > influence
> > > the development practices of the project to ensure that an appropriate
> > > degree of stability (including quick turnaround on x.y.z patch updates,
> > if
> > > needed) could be provided, just using the stable project branch.
> > >
> > > I've started to see calls for this kind of thing in the user communities
> > of
> > > various projects (including recently from some folks frustrated that
> > they
> > > can't get bugfixes for MyFaces without buying in to all the
> > functionality
> > > changes in the trunk too). What would you think of working towards this
> > > kind of goal for Trinidad (once we get to the initial product quality
> > > release), and perhaps later trying to broaden it to MyFaces too?
> >
> > This process - stable main releases, with instability only at major
> > releases - is exactly how we developed ADF back at Oracle,
> > and exactly what I'd like to see for Trinidad with respect to any
> > changes that break backwards compatibility. Trinidad already
> > has the concept of an exposed, stable API, in the trinidad-api
> > JAR, and an internal, unstable API, in the trinidad-impl JAR.
> >
> > So, in the long run, I couldn't agree more. I also do want to broaden
> > this to MyFaces - it's a source of great personal concern that
> > there is no stated rule in MyFaces that any API can be depended
> > on from one release to any other.
> >
> > My issue right now is what to do in the short term, where:
> >
> > - We Trinidad committers have to make changes to Trinidad to get out
> > of the incubator
> > - Necessarily, there isn't yet a stable 1.0 release (because
> > we're a new podling).
> > - But Oracle still has to have some level of stability for internal
> > development.
> >
> > So, I can totally with the Apache folks that it's poor development
> > practice long-term, and I would never want to stick to the approach - I
> > want Oracle using *real* versions of Trinidad, not some hacked
> > up Oracle-only version.
> >
> > But it leaves me in a conundrum for what to do right now,
> > because I have to wear both the Oracle hat and the Trinidad hat.
> >
> > The simplest answer is to come up with something that is
> > not company-specific, so it doesn't get Apache into non-profit
> > legal trouble, yet addresses these real needs. How about
> > a basic "monthly stabilization branch" that anyone can pull
> > off of, and has no particular tie to any one company? And
> > a long-term strategy of eliminating the need for such branches
> > once we have a real set of releases?
> >
> > What would others say to something basic like that?
>
>
> I can definitely sympathize with having to wear two hats in this discussion
> :-).
>
> How's this for an alternative approach that might both meet the short term
> needs, but also set us up to succeed in the future?
>
> * Release a "milestone 1.0" (or whatever terminology was chosen) as soon as
> possible,
> and create a branch for it.
>
> * Continue the active development (such as any remaining package renames and
> such)
> in the trunk, with the ultimate destination of releasing a "milestone 1.1"
> if we are still in
> the incubator at that point.
>
> * As time progresses, port any mission critical bugfixes back from the trunk
> to the
> "milestone 1.0" branch, when accepted by the committers maintaining that
> branch.
>
> * If it is appropriate to meet the requirements of any downstream user that
> wants to
> rely on a "released" version, simply release a 1.0.x that contains the
> accumulated
> bugfixes to date. NOTE -- this is most definitely not specific to any
> particular downstream
> user ... the committers should be prepared to publish an x.y.z release at
> pretty much
> any time it is requested, or when enough patches have been accumulated
> that it is
> judged the user community at large would benefit from an update.
>
> This would get us already on the path towards an even/odd type release
> architecture, and provide Oracle (in this case ... but the principle is
> general) a stable branch to depend on. It even encourages companies that
> want to rely on open source software to make sure they have people with
> commit access, to provide the degree of stability control that their
> internal folks will expect.
>
>
> -- Adam
>
>
>
> Craig
>
>
