Joerg Barfurth wrote:
If people really find something they can't live with they can use use our processes to get obstacles removed (like the Community Council or the Engineering steering comittee). But of course, as in any OSS project, if you can't live with project policies, you have to bite the bullet and leave or fork.
Or change the polices :-)
I said "[affected people] can use our processes to get obstacles removed". But it is something different to criticize a policy and to define a viable replacement that removes the problems. First you have to find out what it is that creates the problem. Then you should understand why it is that way (usually we don't put up obstacles just to anger contributors). And then you need a solution that reconciles the various interests.
Joerg, do you have any ideas for making development more attractive? What do you think of the "testing branch" idea? Could it be done?
I think it is a lot of work to merge stuff across branches and do the associated build and release engineering work. Particularly if you start to merge over features out of order, because some are less risky or better tested.
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.
The unusual points about this model: There is no single branch on which all current feature development is thrown together, so there is no single 'unstable' build. As a consequence of this, we require some QA (and some bureaucracy) before a CWS is nominated for inclusion into the main branch. 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'.
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 we had a "testing" branch like that, volunteers could contribute macros to add some features. For example, remember the word count macro? I understand that it was a "feature" and so it wouldn't go in the "stable" branch. But it could well go in a "testing" branch, for example.
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 think this would be an example of how we can alter the project procedures a bit to make it a more welcomming place for "community".
I'd be grateful for your thoughts on this.
Ciao, Joerg
-- 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]
