On 2/8/07, Sam Ruby <[EMAIL PROTECTED]> wrote:
On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote: > > > On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > >> > > >> > So I think we need a branch to do this stabilization work > >> > >> I'm disturbed by this proposal as I don't think we have consensus in > >> the community yet on this issue. > > > > This is not an issue that requires consensus. I've referred > > previously to a memo tited 'rules for revolutionaries'[1] which > > addresses the need to reduce friction in times like these. > > Consensus may have been the wrong word - common understanding of what > the branch is for might have been better phrasing. There's been talk > about stabilizing for a release (which is often when branches are > used for), but also about developing new features (which is usually > done in trunk). Is this someone's personal environment, or a > revolution? I simply don't know. It actually is unknowable. It is the nature of the work. The branch could go nowhere. It could become the basis for people to quickly these scenarios to the trunk. It could expose problems earlier than would otherwise be found on the trunk. At a minimum, it will not disrupt continued progress on the trunk, and by being done in the open and under a compatible license, it can be readily cannibalized at any point. > I think consensus here though is important - not on whether we create > a branch but in the impact this has on how we develop as a community. > We were working together, all of a sudden something has changed and > now we have friction. That's what we need to fix. Reviewing the archives, what I see is mounting frustration, one that would benefit from a release valve. No-one seems to be questioning that the work that is going on in the trunk is necessary, the only is growing recognition that more parallelism is required. > >> If the issue here is that trunk is unstable, then we should stabilize > >> trunk. > > > > That would be wonderful. But let's put that in concrete terms. At > > least one individual (and possibly several) is interested in working > > on the 'BigBank' end to end scenario. Other (others?) are interested > > in verifying fixes to issues reported in JIRA. > > > > Which would minimize friction more? Allowing that work to proceed in > > a branch, or for that individual (or individuals) to start exercising > > their right to veto any change that impedes their progress? The > > latter approach would put a significant, albeit short term, damper on > > refactoring efforts, independent of the long term value in said > > refactoring. > > > > So, to put a not so fine point on it, it would represent essentially a > > moratorium on all but the most insignificant refactoring efforts. > > > > Is that what this group wants? > > I don't know. Actually, I would seriously doubt it. > One of the factors here is the change in the spec APIs from 0.95 to > 1.0 which had many incompatible changes. I think we all want to > support 1.0 but reality is that all of our samples, "end-to-end > scenarios" and itests are written against the 0.95 level. We knew > evolution to 1.0 would be disruptive which is why we have a "pre- > spec" branch as a baseline for ongoing development at the 0.95 level; > it seems like some friction is coming because this is not working and > perhaps tackling that will make things smoother. Perhaps. But it is also possible that a branch that is closer to the current trunk would be less disruptive long term. And not necessarily just one branch, this process could conceivably even repeat periodically, and eventually converge. > People have talked about working on scenarios and Jira issues, but > it's not clear if they are intending to do that at the 0.95 level or > at the 1.0 level. If at the 1.0 level, the harsh reality is that we > don't have a 1.0 level runtime yet to support them - some of us are > working on it but it's not done yet. I think joining in that work is > the most effective way to get something that can run 1.0 level > scenarios, but if people want to start a branch and do it there > that's cool too. At some point you hit the mythical man month "nine women, one baby" issue. re: "if people want to start a branch and do it there that's cool too." +1 > > If so, another way to proceed is for the project to adopt a 'review > > then commit model', whereby all changes are proposed for discussion > > and voted on before commits are made. Projects which place a high > > premium on stability, like the Apache HTTPD project operate in this > > way everyday. > > I've been wondering about that too - not for stability, but for the > community-building aspect. It's certainly a better option than > throwing vetos around. Geronimo recently had this imposed on them. It was just the jolt that they needed, but once that was accomplished, it was quickly disposed of. My thoughts are that it is an option to consider, but one not to be taken lightly. - Sam Ruby --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I can't speak from a java SCA developers perspective. I 've been tucked
away in PHP and C++ land. But I've only this week started again to think about looking back at getting the various runtimes to play together having not looked at Java SCA since M1 days. Back then I got put off because of the revolution moving from M1 to the M2 approach made it very difficult, for the Java SCA novice like me at least, to do anything sensible. My timing must be really messed up because I'm now looking at this thread with a certain sense of Deja Vu. I'm interested in being able to test running Java SCA composites over the coming weeks. Not absolutely convinced I need a system supporting all the 1.0 features this minute but clearly it would be good not to be prevented from moving in that direction. I'm no fan of branch and merge either but I guess I'm saying I would like two things which appear, from this thread, to be at odds at the moment, i.e. a reasonably stable and up to date-ish integration environment and the continued development of the trunk toward the bells and whistles 1.0 environment. Simon
