Tim Williams wrote:
On 8/26/05, Ross Gardler <[EMAIL PROTECTED]> wrote:
Ferdinand Soethe wrote:
I have an uncomfortable gut feeling with the current status of our
pre-release version and I'd like your feedback on these concerns and
my suggestions to change our process.
My concerns with the current situation:
- in the last few month a number of exciting major projects
(location maps, views, i18n, change of cocoon ...)and a number of
smaller ones have been developed (which is good!)
- most of them have not been finished to the point of being releasable
and (so it seems to me) will not be for considerable time so it
seems like we won't be able to release quickly without a major clean-up
effort (which I consider bad).
- the work-in-progress-state and its (perfectly normal) unfinished
documentation make it very hard for people to understand the
development version or work with it at any point in time or
understand the implications and side effects of each new development.
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).
We've talked about this before and last time the only thing I had
heartburn with was "always releasable" trunk as it implies an "Always
Branch" system and I think that's overly rigid and runs counter to our
community goals. A reasonably stable trunk is a good goal. Well
documented to the extent possible - if something is still under heavy
development then time shouldn't be wasted documenting yet (beyond that
which would allow other devs to check it out). Heavy development in
the trunk? Yes, if it's not causing the trunk to be unstable, then
yes.
+1, my recollection of the previous discussion was that a branch is used
for new functionality or major refactoring. My recollection of "always
releasable" is that Forrest devs are using it in production
environments. This implies that there may be one or two hidden bugs but
in the main it is releasable.
In addition "always releasable" should mean that all tests are past
(when we have them)
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.
Develop all major changes and new features *that may make the trunk
unstable* in separate branches maybe. As written, I think this would
lead to fracturing in a couple ways. 1) devs wouldn't check-out all
the other branches and new stuff would be sole-developed even more so
than some things are now; 2) bleeding-edge users won't get into
checking out multiple branches to checkout new functionality (i.e. no
patches).
The reality of most work is that it starts of as a one person operation
until it becomes usable, occasionally someone else comes along (as you
did with Loationmaps). SVN does not force users to checkout complete
branches. They simply run a switch command and that's it. this is a very
fast operation in most cases.
Having said that, I agree with your concerns. It's difficult to decide
when not to branch, often a simple change becomes something much more major.
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.
I think we agreed to these goals (more or less):
1) a stable trunk (ie. no "hoop-jumping" to build and run).
2) a branch for anything that would violate goal #1
3) each branch in #2 should be independent features (so that each can
merge separately)
My take on what's being suggested goes well-beyond this but maybe I'm
reading too much into it.
My take, is as you define it. Who knows exactly what Ferdinand meant
(I'm sure he'll tell us if it is different). What we need to do is
document it, this thread and the others I linked to in a previous reply
go a long way to providing this documentation. We just need someone to
have the time to pull it all together.
...
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.
I don't think we're mature enough for that. At least, I've not seen a
robust enough test harness around for it.
I don't understand how we can not be mature enough. In agile programming
you write the tests *before* you write the code. We are a long way from
that, but I don't see why we can't try and catch up a bit.
At the very least we should insist that the minimal testing we do have
is passed (David as set up an instance of Forrest on our zone, we need
to make use of this for testing).
In addition there are a number of testing frameworks that can be used
for this. We have discussed it in the past. There are some basic
starting points in the whiteboard.
However, I agree with both yourself and David in that the absence of
these tests should not prevent us actoning this proposal (or whatever we
agree on).
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
Encouraging such on the project would lead, in my opinion, to a
fractured community. People naturally tend to prioritize email based
on the subject line, but supporting that through branch prefixes or
the like would lead to several "mini-projects". Heck, people might
even set up email filters to only look at "their" branch -- not good.
I think instead we need folks periodically reminding everyone to write
good archive/mailbox-friendly subject lines.
Yes, David and Thorsten have made similar points, I agree.
Ross
