When Karl was in the Netherlands last December, he and I talked quite
a while about the post-1.0 era and what it has gradually led to in our
community. Yesterday CMike told me that the same issues came up in a
conversation between CMike and Ben. Possibly, others are bothered by
this too.
Before 1.0, there was a large number of tasks to be done, but the
community selected a small number of them and worked on fixing those
as a whole. Then, later, different problems were selected and so on.
This had the benefit that everybody knew what the status was for each
of the different issues which were being addressed. Contributions
were swift and patch review was almost instant (even though on-list!).
Now we have passed the 1.0 mark, it seems all focus has been lost:
everybody is picking his own stuff to do, so much even that we end up
with 1.5 people and a dead horse working on merge tracking. MT is
supposed to be *the* killer feature after 1.0!
Both Karl and I as well as CMike and Ben concluded that the painfull
release stabilization we're seeing is a symptom of the same issue:
we're not working together until there's a moment where we really need
to: to get a release out the door.
Sure this is OSS, so it's logical everybody gets to scratch his/her
own itch. Next to that, the number of lines of code to maintain has
increased a lot since then, but the number of active committers
hasn't. So Karl, Ben, CMike and I feel that if we could -and should-
be more like a team again, not only scratching our own itches, but
help others scratch theirs too: we would greatly increase our
collective productivity and most of all find back the satisfaction of
working for a project where great design and team spirit are the major
drivers in the community.
All of this sounds idealistic, but how to realise all this? Well,
CMike and I propose to -right after 1.5 has been released- lay out a
road map for further Subversion development. Everybody is encouraged
to contribute his itches! Then, we work out a solid product road map
with *explicit* community consensus. That way, we all know what to
expect and what we agreed on.
The road map should define both which releases contain which features,
but also what internal developments we're expecting to be done by the
release milestone (test suite NG, rewrite ra_dav, rewrite wc lib,
etc). By addressing the 'other issues' explicitly, I think everybody
knows what to expect when in relation to itches of his own and those
of others.
Up until today, we have lacked such a well defined view of the future
(and we actually didn't have it before 1.0 either; we just chose a
moment to say 'yup, it's done.').
In other words, with all the (professional) promisses on what 1.5 is,
lets do it the way it's been one last time. After that, lets get
organized again and 'fix' these problems: lets make a solid road map
and try to adhere to it.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 27 12:55:53 2007