Forum OpenACS Q&A: Response to Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST
Ok I've had more time to look through the document in more detail.
I'll start by picking up a few points in the text, and slip in my comments and conclusions there.
I'll start with the summary section and work down
'However, we are currently pursuing a development route very much in conflict with this goal.'
There is no reason to suspect this. We are pursuing a development goal of a suitably stable release (4.7) from which the issues raised in your document can be properly addressed. The ability to do this has been hampered by limited resources.
'We are adding more packages to the core, adding more dependencies to the release of a monolithic distribution, and generally slowing down development.'
Its hard to define what 'adding to the core' means. If you mean its all downloaded as one, well yes thats true (as no suitable system for separable downloads is available at present other than CVS). Nmost packages have dependencies, but it is not conversely true that they all have to be installed. As for references to slowing down development, this appears to be baseless as development in recent months appears to have increased if its changed at all. It also extremely difficult to find examples of how exactly the issues of a single release has slowed development. As a product matures and stabalises, it is only natural that new additions have a greater effort in terms of meeting the current quality levels. I agree that just hacking out new stuff without consideration for the state of the rest of the system is quicker.... but not necessarily better, as this statement seems to imply.
'If we do this right, we retain all the current advantages while gaining faster development, a leaner core, and generally a technology environment that makes it easier for anyone to innovate.'
Yes, no disagreement there but, your premise here is that innovation is the ultimate, if not only, goal of the project/community. It is not! That may be your primary goal, but this cannot be applied 'blanket' style to everyone.
'Certain specific packages (e.g. calendar) have plenty of bugs left, but the code freeze date for OpenACS 4.6 is past due: calendar bug fixes will have to wait for OpenACS 4.7. Progress of an end-user package still depends on a central release date'
Well of course. If its not to trite to say so, thats software development bud! The reason for this is that we are trying to get some focussed testing done on this (not something this community has traditionally been all that good at, OpenForce included). For that to have any meaning we need some sort of cut off to work against. That doesn;t prevent bugs being fixed etc.. what it does is prevent chaos-hackers whacking away at code while people are trying to assess it. No-one likes working to a constantly moving set of goalposts.
'People interested in a subset of dotLRN have to download all of dotLRN'
If thats so, well, that is largely down to OF in the first place, secondly this is not the OpenACS and thirdly this is now an issue for the Governance Board to address, from which you have opted out.
'People interested in a subset of OpenACS have to download all of OpenACS.'
Yes, everyone accepts we'd like a smaller download. But this really only about download time. This doesn't imply people have to use/install everything.
'"Rolling package X back into OpenACS" is generally considered a good thing, but it has at least 3 different meanings. Plenty of miscommunication occurs based on this confusion.'
You make a very salient point here, and I agree a definition or common understanding of what that means is required.
'no one should ever be forced to download or install new-portal if they don't need it.'
Yes, but my understanding is that in general new-portal is very popular as a concept and a lot of people have said they'd want to see it as an inherent part of OpenACS. Therefore, your personal preference aside this is a moot point. The decision seems to have been taken, and so thats the way it is. There's no point rehashing this debate again.
'Unfortunately, these properties are too often ignored in our discussions and development process. We've lost touch with the true nature of OpenACS modularity.'
Who has? I for one don't like being spoken for and this kind of comment is personal conjecture only. You think we've lost touch. I disagree most strongly.
' Under this proposal, lars-bloggerbecame "part of OpenACS" only a few weeks ago, when the source code was added to the OpenACS central repository. Did something technically important change when Lars moved the CVS from his site to the OpenACS repository? Not really. Should the location of the code really matter? Not if we can help it. '
Location does matter in as much as we want to make it easy for people to find what they're looking for. As you say, if the location doesn't matter, then it doesn't matter if its all stored in the same place does it!
'
We must find a more sensible and balanced approach.
'Yes, overall I agree with you, I just think you're making the point based on perceived problems that don't necessarily exist.
The 'Two Questions, Two Answers' Section. No one has said that your package has to be in the core to be part of the OpenACS... I just wonder where you;re getting all this from? You also refer to 'Our' current thinking a lot... Who the hell is this group of people? My thinking ain't along those lines, and I don't know anyone else in the community whose is either. I'm sorry but this sounds like creating an artificial sense of something is wrong to justify your own argument.
A Leaner, Meaner OpenACS'. Firstly let me say I think we're all working towards that. And secondly given the bloated nature of dotLRN, I think there's an element of 'people in glass houses'. If this is a highly motivating issue for you how do you reconcile that with the nature of the dotLRN distribution?
Although I agree with the premise, again I have to express concern over the '
MIST does away with the ever-growing and now bloated OpenACS core'
Warming Warning Warning... shameless negative marketing. This kind of tish really gets in the way of a serious discussion.
Ok, now finally I can comment on the scheme your proposing.
Apart from your obsession with Debian as an great exemplar, which I think is open to argument, the scheme your proposing seems pretty workable, and I think I probably would get behind an effort of this kind.
I think the only sticking point is not ending up creating a diverse, but incredibly thinly spread community. As you point out it may lead to umpteen Content Repositories. This is dilution of resource, plain and simple, and to be honest it smacks of hacker mentality. If there's one thing guranteed to piss me off its computer nerd banging on about how much better their version of something is compared to someone else. All you end up with is lots of shit, half finished code. If we can think of a way that might avoid this senseless dissolution, then I think the scheme's got a lot of potential.
Conclusion
Just think how much more positively you suggestion might have been received has you not indulged in something of an egotistical rant about the current state of things. I think Don echoed similar thoughts earlier in that stuff like this does make you feel like saying 'sod this, I'll spend my time and energy elsewhere'.
I for one would love to pontificate about what might come next, and how shit everything is, but I like Don and many other are also actually having to do the hard, and less glamorous tasks that will actually get a 4.6 release out.
Maybe you didn't intend it this way, maybe you just have slightly poor written communication skills, but either way the net effect is a good idea, somewhat spoiled by a lack of respect for the hard work people are currently putting in, the difficulties that that entails and a lack of sensitivity in your approach.
I'm sorry I can't be more conciliatory about this, but to be honest your article is insulting.
'Its easier to paint Demons than Dogs'. Unfortunately I've got testing to do, and thats a dog if ever there was one.
