Branch Philosophy

[Tim Wilde <tw...@dyndns.org>]

I'll preface this by saying I'm not much of a developer myself, but I use
a number of major open source software packages, and follow their
development models pretty closely.

I don't understand all this fighting about branching and development.  I
don't understand why Apache 2.0 has been released, and recommended for
production use, if, as many seem to be saying, it isn't
"feature-complete".  Every other project I've ever seen doesn't do active
development on a released branch.  That's just NOT how to do things.  Yet
Apache 2.0's API is changing, it seems on a daily basis.  If this is
release software, why are you changing the API?

Examples:

mySQL - 3.23.xx is released.  Bug-fixes only.  4.0 is now in beta -
feature freeze, bug fixing for release.  4.1 is alpha, 5.0 is pre-alpha.
Those are where development is going on, use at your own risk,
back-porting major bug/security fixes to the released/stabilizing
branches.

FreeBSD - 4.7 is the current release.  Minor development occurs on the
-STABLE branch, which will lead to the release of 4.8, 4.9, etc, with a
-CURRENT branch for bleeding edge, which will become 5.0.  When 5.0 is
released, -CURRENT (which may then become -STABLE, with -CURRENT being
6.0) will be developed for 5.1, 5.2, etc.  FreeBSD "releases" never change
after they're released - point releases are made if absolutely necessary
(4.6.1 and 4.6.2, for example) and a security-patches-only CVS tag is
available for each release.

Perl - Releases are made on even numbers (5.6, 5.8) with development
happening in the next odd number (currently 5.9) which will be released as
5.10.  Changes within branches (5.6.1, 5.8.1, if/when they're made) are
for vital fixes only, and extensively tested in previous versions before
being released.

All of these projects have their own problems.  But at least their users
can know that "FreeBSD 4.7" or "Perl 5.6" is going to be the same piece of
software between 4.7.0 and 4.7.1 or 5.6.0 and 5.6.1, with only minor
changes.  That's not so with Apache 2.0.

I don't see what's so hard here.  Maybe 2.0 isn't "feature-complete" yet.
But I think it's time to give up on 2.0 and start doing things right.
Start developing full-time on 2.1.  Make it available as development
software, clearly marked as such.  Get it feature-complete.  Set goals.
Then, when the time is right, release it as 2.2.  While you're going,
backport bug fixes to 2.0 if they become necessary.  But don't make API
changes.  Don't change the heart of the software.  Heck, you shouldn't
even be making MAJOR API changes in 2.1 - PHP and Linux have both made
that mistake at different times, and many people would never touch them
again because of it.

Apache is a de-facto standard.  Don't wreck it by going around making
changes willy-nilly mid-stream and alienating your users.  Pick a
development model that doesn't have people running software that doesn't
even have functional helper applications as if it's release quality.  I'm
sorry, but a broken htpasswd binary is NOT acceptable in a GA release.  If
I'd read this list before I switched to Apache 2.0, I never would have
made the change.

I don't want to start a flamewar, and I know the first cry is going to be
"then why don't /you/ coordinate it?!"  Take my advice, or leave it.  I
don't have the time to coordinate a major software project, nor do I think
I'm capable of doing it right - certainly I couldn't do it "perfectly",
nor do I think anyone could.  I just think it can be done better than the
way it's being done here.

That's my several dollars of opinion.  Take or leave it, it's up to all of
you.  I just use the software :)  And I know there are a lot of people out
there who feel the same way I do.

Tim Wilde

-- 
Tim Wilde
twilde@dyndns.org
Systems Administrator
Dynamic DNS Network Services
http://www.dyndns.org/

Re: Branch Philosophy

[Greg Stein <gs...@lyra.org>]

On Sat, Oct 12, 2002 at 11:41:01PM -0400, Tim Wilde wrote:
>...
> I don't understand all this fighting about branching and development.  I
> don't understand why Apache 2.0 has been released, and recommended for
> production use, if, as many seem to be saying, it isn't
> "feature-complete".

Apache 2.0 has all the features that most people need to run their web site.
Thus, it is quite ready for production use. The fact that some people want
to add features doesn't detract from the fact that it is useful *today*.

Your car gets you from point A to point B. It is useful, and it works quite
well in the role, so you begin to use it. But the people that make the car
want to add a rear-window wiper. That doesn't detract from its original
utility, but it now has an extra feature that you can use.

> Every other project I've ever seen doesn't do active
> development on a released branch.  That's just NOT how to do things.  Yet
> Apache 2.0's API is changing, it seems on a daily basis.  If this is
> release software, why are you changing the API?

To make it better. And no, the API is not changing on a daily basis. Here
are the latest set of entries from ap_mmn.h:

 * 20020602 (2.0.37-dev) Bucket API change (metadata buckets)
 * 20020612 (2.0.38-dev) Changed server_rec->[keep_alive_]timeout to apr time
 * 20020625 (2.0.40-dev) Changed conn_rec->keepalive to an enumeration
 * 20020628 (2.0.40-dev) Added filter_init to filter registration functions
 * 20020903 (2.0.41-dev) APR's error constants changed

I think there were more changes between 20020628 and 20020903, but they
simply didn't get recorded like they should. But nobody has bumped that
value for over a month, and it hasn't needed to be bumped. In other words,
the API has been stable for about six weeks now.

> Examples:
> 
> mySQL - 3.23.xx is released.  Bug-fixes only.  4.0 is now in beta -
>...
> FreeBSD - 4.7 is the current release.  Minor development occurs on the
>...
> Perl - Releases are made on even numbers (5.6, 5.8) with development

All of these projects have a central core of people who are defining the
feature set for each release, and have the right/ability to enforce that.
The Apache community, and httpd in particular, is not set up that way. We
do not have a central authority who defines releases, schedules, or limits
on the committers' activities. Call it good or bad, but that is our way.

>...
> I don't see what's so hard here.  Maybe 2.0 isn't "feature-complete" yet.
> But I think it's time to give up on 2.0 and start doing things right.

Right in your mind. That simply isn't how this project is organized, and I
don't see it changing any time soon.

I'm not saying you're wrong. Most of the other projects that I work on/with
have a central authority. Apache/httpd does not, so your ideas just don't
apply.

>...
> even have functional helper applications as if it's release quality.  I'm
> sorry, but a broken htpasswd binary is NOT acceptable in a GA release.  If

Gee, and nobody has ever made a mistake before. Wow. We were the first? Boy,
that totally sucks.

[ /me points out Linus' "brown paper bag" release ]

>...
> nor do I think anyone could.  I just think it can be done better than the
> way it's being done here.

Projects *can* be run better, yes. But this project is not set up that way.

Seriously, I have no problem with suggestions on how to improve stability.
But they have to match the community. I think you also needed a bit more
research on the actual rate of change in the API, and bit of simple human
forgiveness for error with the htpasswd thing. It happens.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Branch Philosophy

[Glenn <gs...@gluelogic.com>]

On Sat, Oct 12, 2002 at 11:41:01PM -0400, Tim Wilde wrote:
> I'll preface this by saying I'm not much of a developer myself, but I use
> a number of major open source software packages, and follow their
> development models pretty closely.
> 
> I don't understand all this fighting about branching and development.  I
> don't understand why Apache 2.0 has been released, and recommended for
> production use, if, as many seem to be saying, it isn't
> "feature-complete".  Every other project I've ever seen doesn't do active
> development on a released branch.  That's just NOT how to do things. [...]

Let me preface my response by saying that I am not running Apache2 in
production (module reasons), although I run it in my test lab.  In the
1.3 tree, I watch the releases and see what has changed.  Not all Apache
point releases reach GA.  And a few that do occasionally shouldn't have.
That's just the way it is, even with proprietary software.  But being
open source, I can gauge things much better in Apache by following the
development.

The same thing goes for RedHat releases.  I know a lot of people who
won't touch RedHat *.0 releases.  Historically, the *.0 releases include
major changes.  RedHat has done an excellent job with each release, but
the *.0 releases have typically needed more initial fixes than the rest.
Why is this?  RedHat does rigorous testing on its releases, but only once
it is being used by a much wider audience do more subtle bugs show up
(often related to the major changes that fewer people were previously using)
This has the effect of pushing the envelope a bit, which I like (gcc and
glibc upgrades, for example).

I look at Apache the same way.  Apache2 includes some _major_ changes.
These changes are not going to stabilize until they are used by a wider
audience.  At last post of the count to this list, slightly more than
6,000 servers were running Apache2 (did I get that right?)  Therefore,
changing the API at this early stage in order to move towards a solid
2.0 platform is a Good Thing (tm), even if it means the many changes
restrict the growth of Apache2 to early adopters.  It's much better than
withholding those changes and slowing down progress.  And growing the
Apache2 userbase slowly as the 2.0 platform stabilizes is also much
better than wholesale adoption by general users who often do not maintain
their systems as well as early adopters, and who might be slow in 
updating to important releases.

Don't misunderstand: Apache2 works today!  It just isn't everything to
everyone yet since some module authors need to catch up to the new Apache
model.

Just a counterpoint.
Cheers,
-Glenn
(who normally doesn't post this much, but has something to contribute)