David Crossley wrote:
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.
+1 - not enough docs could be one reason why someone would object to a
mere (see below)
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.
+1 - 3 complete revolutions of the planet is the "usual" on other projects.
...
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.
True, so we need to create one. The absence of one should not prevent us
from moving forwards with Ferdinands proposal, but it should be
considered an important addition to the process.
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.
+1 - I had interpreted "ignore" in the context of lazy consensu, I agree
nothing should be ignored in the sense of no notice is taken.
Wouldn't a well-chosen subject title suffice.
+1
Ross
