On Wed, Feb 26, 2003 at 12:44:28PM +0100, Stefano Mazzocchi wrote: > Jeff Turner wrote: > >On Wed, Feb 26, 2003 at 09:05:02AM +0100, Nicola Ken Barozzi wrote:
<snip scratchpad ideas/> <snip consensus on alpha blocks/> > This leaves us with the alpha core stuff. > > Many of you say that Schecoon would not have happened if it wasn't for > the scratchpad. I don't see this. Nobody helped Ovidiu and the scheme > syntax argument was discussed over email, not CVS. He proposed, we > commented, some disliked, some liked, some ignored, some backed up. The > fact that code development happened on our CVS did it really made a > difference? > > Only one: we saw commit messages. We followed development. > > Now, did you guys ever heard about a nice CVS concept called > "branching"? Ovidiu wanted to work on some cocoon internals, wanted to > have a place to try things and didn't want to step on our toes, so he > should have asked for a branch and we would have given it to him. So you're saying that for core development, people should use branches instead of the scratchpad? So when someone comes up with an alpha SuperDuperProcessingPipeline class, what is the process? Do they tag the whole of CVS? Tag just the subset they modify? I've been down the tag-a-subset road before. I developed Excalibur's horrible dependency-checking build system on a branch over a few months. The HALF_BRANCHING.txt file in Excalibur describes the hoops one needs to jump through to use branching for a set of files. It's not fun. > the scratchpad is a lazy version of the same concept, too bad that when > developers use branches the tend to go quickly to the point where they > can merge it with HEAD, unlike the scratchpad that is *already* in head, > so it will be picked up anyway by the release, even if marked sideways. > > I want people to work on HEAD so that they feel the pressure and do a > better job. That is clear. It's not clear how a branch is better than a separate directory. > If I refactored the build on a branch (or even worse, on another CVS > module), how many of you would have tried it out and debug it? Now it seems you don't like branches.. if not, how would Schecoon have come into existence? What should happen to the current 'core' classes in the scratchpad? > Martin Holz wrote: > > P.S : Improving the build system is really worth some temporary > > inconvenience. Thank you very much. > > See? > > Now, about the alpha-committers: the scratchpad creates one-man-shows > even if we know that our committers have an extensive log of being able > to work with others. *Everything* starts off as a one-man show. Innovation comes from individuals pursuing ideas. The issue is where the one-man shows take place: a) Cocoon src/java/* b) Cocoon branch c) Cocoon scratchpad d) Cocoon sandbox module e) Sourceforge sandbox f) in private > If you open up the gates to everyone, do you really think that this will > help finding new developers for this community? I strongly doubt it. > > I'm positive it will generate tons of half-baked concepts and components > mockups, but it will reduce the filtering that community performs and > will remove the incentive for them to work harder to gain access to CVS. > > The overall quality of code will be much lower and they will feel > confortable with this since nobody will (could) complain for political > correctness. > > The result will be that we won't ship anything from that since we will > fear of insulting some of those one-man-shows. > > So, at the end, you have simply created a poor-quality collection of > one-man dumped and half-baked efforts. Also known as the result of the > "Sourceforge Effect". Agreed. Just like Sourceforge, there will be a lot of crud, but equally, there will be a few gems. That's the point: provide an open "sandbox", and pick the quality ones for inclusion in Cocoon. There are two more points to consider: 1) Irrespective of whether an open Cocoon sandbox improves Cocoon, it will benefit *users*, who will have a place to share code. Just like the Wiki helps users, irrespective of whether it results in better xdocs. 2) If the sandbox participants choose to implement a "lease" idea, then it won't be the Sourceforge effect; old code will be culled. > Sure, one of a thousands might be worth considering. But somebody will > have to spend his energy finding out which one of these is worthwile and > since cocoon users and devs will concentrate here, the amount of energy > to screen those efforts will be very low. See point #1 above; if stuff doesn't migrate to Cocoon, that is not of huge concern. The intention is to get Wiki-like community involvement in the process of writing new code, and as a side-effect, gaining an incubator for potential new committers. --Jeff > - 0 - > > I continue to propose to kill the scratchpad for alpha core code without > creating an alternative. > > -- > Stefano Mazzocchi <[EMAIL PROTECTED]> > Pluralitas non est ponenda sine necessitate [William of Ockham] > -------------------------------------------------------------------- > >
