On 8/15/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
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.
True, I don't see why it does not to be an issue. I'm mostly trying to be cautious here and totally open about motivations etc... Whether Oracle does or does not need to use the branch seems irrelevent to
me.
True. So, if there was a branch that ever was "only company XYZ people may touch this branch", that'd be wrong and bad. But milestone branches, open in general, maintained by committers (and it's not like committers are just going to be clamoring to push fixes into the trunk and lots of branches too), then there's no problem. I do rather like Craig's idea of fairly soon saying "we've got a 1.0 branch", and getting that towards production - for everyone's sake - while we feel free to make larger changes - again, for everyone's sake - on the trunk. Now that the large-scale repackaging is done, I think merges will be relatively straightforward when there will be a need to commit on both trunk and a branch. -- Adam 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 > >
