On Wed, 10 Jul 2013 09:14:16 -0400 Jim Jagielski <j...@jagunet.com> wrote:
> According to STATUS: > > 2.4.5 : In development. Jim proposes a release ~July 4, 2013 > and offers to RM. > 2.4.4 : Tagged on February 18, 2013. Released Feb 25, 2013 > 2.4.3 : Tagged on August 17, 2012. Released Aug 18, 2012 > 2.4.2 : Tagged on April 5, 2012. Released Apr 17, 2012. > 2.4.1 : Tagged on February 13, 2012. Released Feb 21, 2012. > 2.4.0 : Tagged on January 16, 2012, not released. > > So I have no idea where you get "6+ mos between releases" of 2.4.x I stand corrected, only 2.4.4 has taken 6+ mos, as 2.4.5 will only take 6+ mos if this release stretches to August. > In any case, I *am* concerned that w seem to have quite a bit of > difficulty in getting 3 +1s a lot of the time and that the backport > process from trunk to 2.4 is becoming more and more painful. [...] 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? It seems we might be diagnosing the same problem. Everyone can agree there is further good code in /trunk/ right now, what I don't know is whether we are at a point in time where the apply-to-trunk/backport to 2.4 is the right model to encourage development and commits? > And we don't release 2.5.0... We only do even releases, remember? We don't? I count 10 alpha (or beta) tags during the 2.1.x cycle, and 16 during the 2.3.x cycle, including the vast majority of 2.3.x tagged and rolled by yourself. These do become releases; they are simply alpha/beta development and testing releases rather than GA releases. As things have stood since 2.4.0 arrived, we are asking developers to test /trunk/, but not asking so effectively, IMHO. It appears that trunk exists more as a sandbox for applying patches and obtaining feedback (which can happen in a sandbox, or the live tree, or a bug ticket, or the dev list, IMHO) to present a backport in STATUS (which is too complex at the present time, IMHO). So reverting branches/2.4.x/ to trunk is my first suggestion to make this easier, and it seems that the list would like to make things a bit easier on committers and contributors. Reverting to CTR on 2.4.x would be my second suggestion. Are there other suggestions that may also simplify this process? And throughout these comments, when I say 'developers' - I mean far more individuals than the handful of active, or even inactive httpd committers.
