httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Whereforeartthou, 2.5.0?
Date Wed, 10 Jul 2013 18:58:12 GMT
On Wed, 10 Jul 2013 20:20:22 +0200
Stefan Fritsch <sf@sfritsch.de> wrote:

> On Wednesday 10 July 2013, William A. Rowe Jr. wrote:
> 
> > What I am asking, is whether that trunk is a sandbox to hack in, or
> > whether is is approaching a releasable state?  I'm asking, whether
> > trunk is a worthwhile exercise or a distraction and complication to
> > fixing and enhancing the shared, released project code,
> > branches/2.4.x?
> 
> trunk is needed for changes that break API/ABI compatibility. And I 
> think it is also very useful for complex changes that take time to
> get into a releasable state. If you take that away, the result will
> be that branches/2.4.x-renamed-to-trunk will not be always in a 
> releasable state, because it will contain unfinished/broken changes. 

I am not proposing to eliminate these.  I am proposing that these be
parceled into sandboxes, until such time as we are ready to create
a 2.5.0-alpha release.  That time doesn't seem to be right now.

The advantage is that each change can be reviewed and enhanced in
its own right by anyone (literally, we have opened the sandbox to
all ASF committers, right?)  By ensuring each developer who is
either breaking changes or offering a complex patch shepherds the
change into 2.4.x or a future 2.5.0-alpha trunk candidate, we will
ensure they don't languish and become troublesome debugging efforts
when they are finally noticed by the -alpha testing community, some
year or years after they are first committed.

These can certainly be tracked in STATUS.

Sandboxes are useful things (as I suggested, this could become a whole
svn vs. git debate, but the mechanics are similar enough to avoid that
discussion for now).  I'd maintain that working around 'future ABI
breaking proposals' today by all of the committers, rather than simply
by the patch's champion(s), is imposing unnecessary complexity on the
rest of the project.

> This may deter people from volunteering as RM because they would
> first have to clean up the mess by fixing open issues or reverting
> changes. And the quality of 2.4 releases will probably suffer, too.

The converse is also true.  If 2.4 is 'broken', that is where most of
our eyes are at (that, and 2.2, hopefully everyone has fun rm -rf'ing
their 2.0 checkouts this week :)  Such breakage is unlikely to last.

The rules of CTR are pretty specific about big breaking changes - we
propose them to the list first.  Better yet, submit them as a sandbox
where others can debug them.  Then svn cp them into place when the
devs agree we are ready for the change.

But discussing the small changes, were it simply CTR, then that review
simply happens.  If you don't like the change, you need to respond and
watch development.  While the changes sit in a non-release /trunk/ they
are ignored at the time they are authored.  Even the author may forget
where they were going with a patch by the time feedback arrives.  With
CTR there is an immediacy for reviewers to follow-along with the effort
which may revive some participation.

Committers are protective of the code they use (or hope to use soon,
in the case of the widely-unadopted 2.4), but less so of some intangible
code tree that may have little relevance for the next 1-3 years.

> The same is true if we make 2.4 completely CTR or the 72 hour scheme 
> proposed by Jim. But I would be open to CTR 2.4 for some classes of 
> changes, maybe simple bug fixes with no (public or private) API 
> change, or for changes that have reasonable test coverage in the test 
> framework.

That is pretty much what I am suggesting, and believe that STATUS for
every minor change is quite a bit of overkill.  STATUS is great to
point people at major refactorings, new works, ap_mmn bumping changes
and the like.

> WRT 2.5/2.6, I very much hope that it will not take as long as the 
> 2.2->2.4 cycle. I am pretty sure that we cannot reasonably support 
> SPDY/HTTPbis/HTTP2.0 in 2.4, so we will need a 2.6 in the forseeable 
> future.

Almost agree, I suspect that would become 3.0 though.  But since that 
is in the distant-foreseeable future and we may be facing new competing 
solutions to these problems, sandboxes seem like a better solution till
some -alpha release is more than a far-off possibility.

Once we are rowing together on an -alpha for a near-term 2.6 or 3.0
major release, the current /trunk/ -> backport strategy once again
will make good sense.  But the code in 2.4.x, while released, is
simply not adopted.  We don't have the frustrations of 2.0 or 2.2
where they are widely deployed and consumed by many downstream
packagers, at least not yet.

Bill

Mime
View raw message