Hello Joerg,
Thank you for your input. It's important to hear the developers' side of the story.
But it is something different to criticize a policy and to define a viable replacement that removes the problems.
Yes, and that's what I'm trying to do here. Explore options to find a viable improvement.
We really already have Child Workspaces (CWS) as bleeding edge development branches, where new features can be stabilized. With this model it should be possible to keep the main development branch at a quality that are at 'testing' level. Recent 1.9.xx milestones show what is (and isn't) possible here.
Maybe that'll happen in the future. My experience with the 1.9.6x and 1.9.7x releases was that they were pretty unstable. So it's not what I'd call "testing". I'd say that something like 1.9.87 could be "testing". It was still not very stable, but it could be installed, and you could reasonably use the product.
Okay, let's aim for using the dev branch like that (in the future).
That means even a committer won't see there feature in a milestone release quickly. But you can at any time produce a build that is 'latest milstone plus one new feature'.
If people saw that, I think we would have made a step forward. Part of that is seeing that there is progress going on. You know, seeing light at the end of the tunnel.
On the upside, it should be possible for ordinary people to use and test most of the milestone releases (of course at their own risk).
If they can maintain the stability of the current beta releases, I think that would work well. I know a couple of people who are already using the beta release as their standard release. I don't because I still find it too unstable. But it's at the point where people who are inpatient can start using it (at their own risk).
We have a sophisticated add-on package manager and care a lot about compatibility. It should be possible to distribute add-ons and macros (via the OOo site) independent of core product release trains.
I never managed to figure out the package manager. That was a big barrier for me. That's why I decided that writing macros wasn't worth my time because none but the most committed members would be able to install them. The other barrier I hit was documentation.
Ian L is working on documentation, so that leaves deployment. How can we improve deployment?
+ Is it possible to make a generic macro installer?
+ Is it possible to add a dialog to OOo to install macross from the web?
+ We'd need a website where people can upload addons easily. If there is interest, I can pursue that. I could talk to Russ about how to let people upload files themselves to OOoMacros. Or maybe Ian will want to add this to his new website. It does make sense to have a single site with (1) documentation (2) sample templates (3) and the add-ons themselves.
Cheers, Daniel.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
