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? I'm also going to do some thinking about this with regard to Shale (again, need to get to a stable release first, but that shouldn't be an infinite amount of time any more :-). -- Adam
Craig Craig
