Project participation and hackability

["Gregor J. Rothfuss" <gr...@apache.org>]

i quite like this approach, and i think we should use that in the future 
instead of creating another branch for trunk / 1.4.

this also means that we need to get the sandboxes in such as shape as to 
make merging easier.

WDYT?


-------- Original Message --------
Subject: Project participation and hackability
Date: Sat, 25 Jun 2005 09:06:23 +0200
From: Nicola Ken Barozzi <ni...@apache.org>
Reply-To: dev@forrest.apache.org
Newsgroups: gmane.text.xml.forrest.devel
References: <42...@apache.org>

The discussion that has sparked following the request to merge
incomplete branches in the trunk, along with Tim's comments, gives me
the opportunity to discuss about how we could manage code change.

The goal is to increase developer participation and involvment in the
Forrest Project, by reducing the barrier to entry.

I have been thinking about this lately, because I have tried to be
involved in other projects that I use for work. Some things that help are:

  * open discussions on mailing lists
  * meritrocracy
  * access to source code
  * clear license
  * collaborativness from existing developers
  * others users that can give you a hand
  * decent documentation to get you started
  * decent reference to key points of the system

These are all present in Forrest, but they are not all.
There is another point which I find very important:

                _hackability_

A project should be hackable, so that users can *quickly* tweak the code
and make patches, changes, enhancements.

To be hackable, it must be:

  - modular

    In this way it can be hacked in small chunks, which are more
    easily undertstandable. Sitemap separation has done something,
    but the locationmap will be a big improvement, separating
    location resolving and transformation processing

  - extensible

    The plugin system is exactly what we need for this, and is
    proving that it's easier to use.

  - have changes give immediate results

    In-place editing that has been done some time back has shown that
    instant results make it much faster and easier to hack.

  - easy buildability

    We provide Ant, so making it build is quite easy I think

Again, we provide all these... but there is one thing left, which is the
whole purpose of this mail.

Imagine that you have Forrest in production, and that you find a bug.
Ok, so you look in the code, find it, and fix it. Now what? You have to
send a patch... so you should :

  1. download Forrest from SVN
  2. see what has changed since the release
  3. do the fix
  4. test the change again
  5. see how the project accepts patches
  6. create the patch and send it
  7. get on the mailing list to see how the process is going
  8. update the svn forrest once the patch is put in
  9. test it again

Do you see something wrong with this?

I do. It's tooooooo long and tedious. In many cases I have resisted
sending patches for lack of time.

Another example.
I had done some extra classes I wanted to share, and in the process I
had made some changes to existing classes. But I had used the
distribution, not the CVS version, so I had to do the above steps again,
and halfway through I stopped.

"What the heck" - I thought - "too much hassle. If I could just use the
trunk in production, it would be much easier".

Imagine that all cutting-edge users can use the trunk in production. A
patch is just a couple of actions away. And after incorporation, the
check is instantaneous, and on a *real* test, as it actually get used.

This can only work if the trunk is always *usable*, and not only
_buildable_. This can make our trunk be really bug-free, as there would
really be a lot of eyes looking at the code.

I would thus propose that the trunk be always *releaseable* at all
times, and that all new functionality that interferes with usage of
prior features be developed on separate branches.

Furthremore, these branches should merge whenever possible between them
in a single branch so that they can be coded together, and get merged
with the trunk only when all developer-known bugs are fixed.

This will also make it easier for us to release often, and to learn to
make smaller reversible changes rather than big ones that are hard to
understand by other developers and users.

Let me know what you think.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org