Good thoughtful post. Answer inline...
On 1/9/02 3:22 AM, "David Bullock" <[EMAIL PROTECTED]> wrote: > In this email, I address two concerns: > > 1) policy for promoting commons-sandbox to commons > 2) the general direction of Jakarta > > > 1) ON POLICY FOR COMMONS > > This is a general observation, and not made with respect to the ARMI > proposal itself, but about project organisation at Jakarta. > > On Wed, 9 Jan 2002, Geir Magnusson Jr. wrote: > >> The point of the sandbox is to build/introduce something and see if it as a >> project can get momentum, build a community, get a clear picture if there is >> enough interest behind something to bring to Commons with the expectation of >> success towards a release, not just a 'dressing room...' > > The point about commons not being a 'dressing room' is good. > > However, there is an obvious tension: > > 1. projects are encouraged to componentise and make facilities > reusable > Yes - that was one of the intents in founding Comons > 2. 'baby components' start in commons-sandbox, and don't get promoted > to maturity in commons until there are 'enough' committers. Hm. Nothing to disagree with there, but not sure of why it's been said > > 3. projects should only rely on mature components in commons Yes (but we don't) :) > So it seems like the path to spinning a good idea into the commons is > going to mean maintaining 2 separate codebases for the same idea for a > while ( one in the project, one in the sandbox ), until the comitter > community catches up and it can become one codebase ( in the commons )? Maybe. For example, Digester et al from Struts came here, was sandboxed and grown, and at the same time Struts depended upon what it still head, making the switch later. Now, nothing states (afaik) that code *must* go into the sandbox first (it's not a dressing room :) For example, you could propose that component X from Jakarta project Y is made a commons component, and will be supported by committers A, B from Y and also C from Z, and used by project Y & Z (this of course is great, bridging projects Y and Z through shared code) For something like that, I think that it doesn't have to go to the sandbox as you have a few things going for it : 1) Support : it has a community of developers and users to support it ( from Y, as it came from Y as well as the bonus add on from Z) 2) Reuse : It is getting > 1 Jakarta projects to use it (reuse good!) 3) Relevance : an existing project Y is already using it, and Z is saying they will - it's therefore provably a relevant component. This of course isn't required, else there could be no innovation, as the relevance of 'new stuff' is often an insight by the original developer not seen by others initally... The combination of 1 & 2 supports the likelihood of success as a standalone component. > I don't think the right place to nip this cyclical dependency is to > rush maybe-good ideas to premature 'maturity'. But maybe something > else could change? > > Perhaps the maturity distinction could be based on: > > sandbox/immature: only 1 PROJECT using it No - I don't support that - there could be something of wider usefulness - for example, Velocity uses a popular parser generator, JavaCC, which is not used by any other jakarta project.... > commons/mature: more than 1 project using it > > and constraint 3 relaxed? > > ( ie. maturity based on actual dependencies, rather than a raw count of > comitters ... the support needed to ensure its continued existence is > pretty much guaranteed if 2 projects actually *rely* on it, and it has > proved its stripes in being reusable as soon as >1 project actually does > use it ). Not sure about that. Not disagreeing, but not sure. I believe that if several projects depend on it (even 1) then you *should* be able to round up 3 committers that will support it from the get-go, so it shouldn't even *be* a problem. And I am not sure about this because I know personally I couldn't commit to supporting every component that projects I work on depend on. Just not enough time in the day. I mean, I could rubber stamp the requirement by listing myself to get by the rule, but the spirit of the rule is important here, not just the letter. > > This kind of policy makes for a 'commons' for genuine *components OF* > top-level projects. Yes - however I can see how you wouldn't want that requirement - for example, I wouldn't hesitate for a second to support bringing something like Poolman here to commons - it has a dedicated developer and user base, even though no project here in Jakarta depends on it explicitly. Of course, you would need to add to the outside component's community one (or more) Jakarta committers to start... > > Maybe there is another kind of policy ( say, 'incubator' ) for aspiring > top-level projects, and maybe the 'count of comitters' metric is more > appropriate here. > Yes - but I will still argue the 'count of committers' shouldn't be a problem at all if you have multiple projects already depending on something - so there is no need for a variant to the rule. > Of course, one would need separate CVS repositories for projects > under each policy, to avoid confusion. > > > > 2) ON FOCUS and LEADERSHIP > > On another thread, there are some very loud yells of 'no better > than sourceforge' and 'duplication!' I am on that other thread :) I openly support duplication - promotes innovation. I will admit to worrying about the 'sourceforgification' of Jakarta. > > I personally think that Jakarta have been a little too lax in > really qualifying their ideas. The criticism of duplication can > apply not just intra-Jakarta but intra- the open-source community. > > [ I find some of the discussion quite amusing given this angle ] > > For example, at the time that J2EEUnit became Cactus, an > alternative project, JUnitEE, existed. It did not cater to > the testing of JSP's, but the architecture was much cleaner > and simpler to use. There was no discussion at the time if > Cactus' contorted multiple proxy idea was in fact the best way > to get the job done. Someone just said, 'how about this?' and > it got in! > > Nobody asked 'well, what does it really mean to try to run JUnit > tests in this environment', and identify facts like that there is no > way to use the ServletContext's log stream from within a test-case > even if you write your own TestRunner. If someone had come up > with a list of issues like this and then approached the JUnit authors > with a proposal, maybe contributed, or maybe offered to adopt the > codebase, who can doubt that testing of J2EE and other application > with JUnit would be much simpler today and Cactus a much less > cumbersome and more popular product? Especially given that Jakarta > is custodian of the javax.servlet.http API too! > > As has been pointed out, it is up to volunteers to contribute their > time and they cannot be *forced* to contribute in a particular way, but > that is no reason why the PMC cannot get volunteers to qualify and > improve thier ideas, consider a bigger picture, before they get > started coding. Yep. Or as I would like, sharpen the focus - and work to make a place for things that don't quite fit. I won't belabor my views from general@ here. > Most people will quite readily accept the > challenge of a bigger picture, and you would probably get the > same non-initiating volunteer base because it is still a 'famous' > organisation to contribute to, and there is a genuine need for good > J2EE testing software and many people like to not start from scratch > by themselves. > > > Guess that must be close to a dime? The exchange rate is pretty > bad from this end ;-) :) > cheers, > David. > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "Now what do we do?" -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
