Hi,
Daniel Carrera wrote:
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.
Yes. I said 'it should be possible'. I know very well that we didn't use this model to its full potential on the road toward 2.0. And we certainly were far of 'testing' quality for a long time.
We may aim to sustain the quality we had from 2.0 Beta onward. I don't think we'll be able to keep quite that level for the entire product constantly, but we shouldn't allow global deterioration and need to recover from larger problems quickly. New features or larger restructurings won't ever be completely right instantly and need some 'soak time'. A CWS can catch the big problems, but keeping stuff like this off the main build for a long time will introduce new problems when merging the codelines that have drifted apart.
And I really don't think we can maintain both 'unstable' and 'testing' (in debian terms). A system like Debian GNU/Linux consists of many separate components which you can largely update independently. The OOo architecture is much more monolithic and work to break this up into more manageable pieces needs to be done in in small increments. Because of this, the effort to systematically mereg features back and forth between such branches quickly becomes prohibitive.
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.
I think the active committers we have that are working with this system see its virtues already.
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.
In 2.0 the package manager has a GUI. See Tools-Package Manager in OOo or use unopkg -gui (iirc). It also has better management functions.
+ 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.
For the web install, see Mathias' answer. If we support that and make it easy for anyone to upload their macros to an 'official' repository the security risk is really high.
Ciao, JÃrg
-- Joerg Barfurth Sun Microsystems - Desktop - Hamburg >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<< Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
