Ross Gardler wrote: > Ferdinand Soethe wrote: > > >What I'd like to see in the future: > > > >1 Adjust our development process so that the current development > > version (I think this is called 'trunk') is always releasable, > > stable and _well documented_ (meaning complete and correct, not well > > written or suitable for a dummy user). > > >2 Develop all major changes and new features in separate branches that > > will only be merged back into trunk when they are stable > > and well documented (not talking refined documentation but good enough > > that a technical writer could work with it) and a good number of > > committers > > not involved in the process have reviewed and tested them. > > Both 1 and 2 are already agreed in principle, we just have to action it > by creating the infrastructure and processes, see end of this mail for > links.
We did discuss this earlier and seemed to be in agreement. I know that documentation is a good thing, but i don't see how we can measure it enough to be able to deny a merge. Perhaps if there is at least some docs then merge is okay. > >3 Discuss and vote one merging each branch back into trunk. > > -1. We only need to discuss major contributions. You will see in the > above linked thread that we are talking about using branches for *all* > work that may break existing functionality, however votes should only be > taken on major functionality. > > Instead of a vote what should happen is that someone announces they are > going to merge into trunk unless someone objects (i.e. lazy consensus) I agree, but they also need to allow time for the world to turn a bit so that that we all have time to raise concerns. > >4 Create a new release whenever such a merger has taken place so that > > new functionalities become quickly available to new users and can be > > stress tested in a production environment without too many changes > > to consider as a source for potential problems. > > -1 for the same reason as above, some branches will be for minor changes > in functionality. However, we have already agreed, in principle, to do > more frequent releases. I believe the intent of your suggestion here is > aligned with that so I agree with the intent. > > This would also make testing of new releases a lot more focussed. > > I would like to go a step further and say we do not merge branches until > we have automated tests for the new features and all existing tests pass. Tests would be good, but as yet we don't have a good enough testing framework to be so rigorous. > >5 As a supportive measure, clearly mark threads in this list when they > > deal with a particular branch so that people not working on that > > issue can safely ignore it. > > +1 Don't use the "ignore" word. I agree with Thorsten that that can be damaging to community. Wouldn't a well-chosen subject title suffice. -David
