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).
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.
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)
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.
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
----
A few weeks ago I started working on summarising the many discussions
like this that we have recently had. I have never found the time to
finish it, in fact I hardly got started. I'll copy what I have here, I'd
encourage someone to take this, put it in SVN and add the other details
from the threads linked to in this draft and the additional stuff
suggested above.
----------------------------------------------
--- Pre-draft of Development Process ---
----------------------------------------------
This proposal is a summary of the following recent threads
"Project participation and hackability" [1] and [2]
"Using Jira and branches for Project Management" [3]
I also used Cocoons [4] project management wiki page for inspiration.
It is intended to be the starting point not the end game, we should move
this into a document (any volunteers?) and keep it up to date as we
learn "on the job". Some of the things in here will prove to be
unworkable, some will be improved. Lets try them and see how it goes.
---
Objectives
==========
To define a project management process that will enable Forrest to
continue to grow without becoming a totally chaotic environemnt.
To create a structure to progect management that is not restricitve to
the Open Source development process
To define processes that, when followed correctly, will reduce the
effort required for Forrest developers to participate effectively, that
is, to not overly burden developers will project management tasks
To create a single point of reference for accepted best practices within
the Forrest development community
Background
==========
Forrest is growing rapidly in many directions. We have a far larger
developer base than just a few months ago, we have a code base that is
expanding in many directions and we have a user base that are applying
Forrest to an increasingly diverse range of problems.
This expansion has resulted in a great deal of new ideas from the
project and inputs to the project. Far more than can possibly be managed
by any single developer. As a result "virtual" teams are emerging within
the community, each focussing on different parts of the Forrest product.
Communication and understanding between these "teams" is excellent, but
the volume of mail passing through our Forrest mailing lists is becoming
unmanageable. As a result developers become selective of which threads
they track in detail which ultimately results in some duplication of
discussion at the overlap points between functionality.
It appears that the Forrest project has expanded to the point at which
we need to maintain an overview document about the project, the work
being carried out, the work planned and the integration of this work
into the core product.
Proposal
========
Using Branches for New Functionlaity
------------------------------------
---
[1] http://marc.theaimsgroup.com/?l=forrest-dev&m=111968323717620&w=2
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=111970514323568&w=2
[3] http://marc.theaimsgroup.com/?t=112393100500001&r=1&w=2
[4] http://wiki.apache.org/cocoon/ProjectManagement
