You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marion & Christophe JAILLET <ch...@wanadoo.fr> on 2017/11/04 13:28:50 UTC
Re: We have soon 5 SVN repo's
Hi,
So 2.5.0-alpha will be RTC.
Good for me, it is what I personally prefer.
Will it be a fork of latest 2.4.x and trunk things will have to be
proposed, voted and backported?
Or will it be a fork from trunk with things likely never (IMHO) really
reviewed?
My own opinion is a copy of 2.4.x + RTC process because I think it is
safer. But I'm not sure it is what others have in mind.
CJ
Le 04/11/2017 à 11:59, Graham Leggett a écrit :
> On 04 Nov 2017, at 12:03 PM, Steffen <info@apachelounge.com
> <ma...@apachelounge.com>> wrote:
>
>> Soon we have:
>>
>> branches 2.4.x
>> trunk
>> 2.5.0-alpha
>> patches/2.4.x
>> patches/trunk
>>
>> Please a procedure: *where*and*when*do we apply patches/fixes.
>
> When: When you feel your change is appropriate, and when on
> review-then-commit branches you have received three +1’s including
> yours binding vote.
>
> Where: Read on.
>
> Everything starts on bleeding edge trunk, always, just as we always
> have done.
>
> People propose backports to the older branches, in order, if people
> feel those patches are warranted, just as we always have done.
>
> If a branch is commit-then-review (CTR), and you believe it is
> appropriate to do so, you commit to that branch, and if people have a
> problem with it, they will say so.
>
> If a branch is review-then-commit (RTC), and you believe it is
> appropriate to do so, you propose a backport in STATUS and when you
> get three +1’s (including your own binding one), you commit to that
> branch.
>
> The changes cascade down the branches as far as you feel is appropriate.
>
> Concrete example.
>
> You have a change. You believe this change should be backported to
> v2.4.x, so that people using the current v2.4.x line will see your
> change. You commit it to trunk. You propose it for backport to
> v2.5.0-alpha. You propose it for backport to v2.4.x. You could carry
> on down to v2.2.x if you believe it is warranted, but you probably
> won’t believe it is warranted for a branch that is end of life.
>
> What do we want?
>
> - All changes on v2.2.x should also appear in all higher branches and
> trunk.
> - All changes on v2.4.x should also appear in all higher branches and
> trunk.
> - All changes on v2.5.x should also appear in trunk.
>
> What _don’t_ we want?
>
> - Changes to appear on v2.4.x that _aren’t_ also made to v2.5.x. For
> obvious reasons we don’t want things in v2.4.x to suddenly vanish from
> v2.5/v2.6; except for
> - Code that only appears in older branches. For example if a module is
> removed, you physically can’t patch it in trunk because it no longer
> exists. In these rare cases you would propose a fix for an older
> branch only. The rule here is “be sensible”.
>
> Nothing has changed in our process.
>
> Regards,
> Graham
> —
>
Re: We have soon 5 SVN repo's
Posted by Rainer Jung <ra...@kippdata.de>.
Although that list is almost 5 years old, people interested for some
major differences between trunk and 2.4.x might have a look at:
https://home.apache.org/~rjung/patches/possible-backports-httpd-trunk-2_4.txt
especially at items 1)-7).
Regards,
Rainer
Re: We have soon 5 SVN repo's
Posted by Stefan Eissing <st...@greenbytes.de>.
If we get a more automated release process and more frequent releases out of this, for all branches, I am happy.
That is in no way to be understood as a critic on the many times Jim has done the RMing.
I am curious to learn what will happen to trunk in regards to this and what ABI breaking goodness people will create. If this goes very wild, people like me who have their heads on the 2.4.x line can always create a 2.4-dev branch for cooperation.
Cheers,
Stefan
PS. FTR: I miss jchampions presence with a focus on test improvements. The sole thing that gives stability to releases, in my experience.
> Am 07.11.2017 um 03:56 schrieb Daniel Ruggeri <DR...@primary.net>:
>
>
> On 11/6/2017 12:44 PM, Jim Jagielski wrote:
>>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>
>>> Reiterating again, that we disagree about who our preferred
>>> approaches are serving and they are disingenuous toward.
>>> Again, a value judgement.
>>>
>> Assuming we go ahead and tag 2.5.0, what is your intention
>> related to 2.4.x? My understanding is that your desire is to
>> place it under "maintenance mode", that is, no functional
>> backports to 2.4.x.
>>
>> Is this correct?
>>
>> To be honest, I don't care at all what happens re: trunk and
>> the 2.5.0 tag, etc as long as it does NOT restrict what we
>> can do for 2.4.x. My fear is that one goal behind tagging 2.5.x
>> is hamstringing 2.4.x.
>>
>> So, for the record, just so we are all clear, what is your desire/goal
>> in all this as far as 2.4.x is related?
>
> To echo also what Bill has said, I don't intend 2.4 to die off because
> we're rolling an alpha for 2.5.0. Far from it. For any of the changes
> I've submitted over the years, I tried to maintain 2.2 parity with
> things backported to 2.4 as much as possible. It's not *easy* managing
> two backport proposals in two different STATUS files, but it's certainly
> not undoable.
>
> I definitely want to help people interested in testing trunk get that
> version in their hands sooner, so if alphas are the way to do that, I'm
> all for it
>
> I'll tag and roll tomorrow evening (roughly 24 hours from the time I
> sent this message) as a first whack at the process. This first run will
> be the first full execution of the script to do the tagging and prepping
> for next version. After that I'll move on to other parts of the release
> process (seems like release.sh is rather complete) and, of course,
> documentation updates as needed.
>
> P.S.
> Resending to dev list
>
> --
> Daniel Ruggeri
>
Re: We have soon 5 SVN repo's
Posted by Daniel Ruggeri <DR...@primary.net>.
On 11/6/2017 12:44 PM, Jim Jagielski wrote:
>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> Reiterating again, that we disagree about who our preferred
>> approaches are serving and they are disingenuous toward.
>> Again, a value judgement.
>>
> Assuming we go ahead and tag 2.5.0, what is your intention
> related to 2.4.x? My understanding is that your desire is to
> place it under "maintenance mode", that is, no functional
> backports to 2.4.x.
>
> Is this correct?
>
> To be honest, I don't care at all what happens re: trunk and
> the 2.5.0 tag, etc as long as it does NOT restrict what we
> can do for 2.4.x. My fear is that one goal behind tagging 2.5.x
> is hamstringing 2.4.x.
>
> So, for the record, just so we are all clear, what is your desire/goal
> in all this as far as 2.4.x is related?
To echo also what Bill has said, I don't intend 2.4 to die off because
we're rolling an alpha for 2.5.0. Far from it. For any of the changes
I've submitted over the years, I tried to maintain 2.2 parity with
things backported to 2.4 as much as possible. It's not *easy* managing
two backport proposals in two different STATUS files, but it's certainly
not undoable.
I definitely want to help people interested in testing trunk get that
version in their hands sooner, so if alphas are the way to do that, I'm
all for it
I'll tag and roll tomorrow evening (roughly 24 hours from the time I
sent this message) as a first whack at the process. This first run will
be the first full execution of the script to do the tagging and prepping
for next version. After that I'll move on to other parts of the release
process (seems like release.sh is rather complete) and, of course,
documentation updates as needed.
P.S.
Resending to dev list
--
Daniel Ruggeri
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
Thx for the clarification.
> On Nov 6, 2017, at 2:34 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>>
>>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>
>>> Reiterating again, that we disagree about who our preferred
>>> approaches are serving and they are disingenuous toward.
>>> Again, a value judgement.
>>>
>>
>> Assuming we go ahead and tag 2.5.0, what is your intention
>> related to 2.4.x? My understanding is that your desire is to
>> place it under "maintenance mode", that is, no functional
>> backports to 2.4.x.
>>
>> Is this correct?
>
> No, that's a misunderstanding... my desire is to have 2.4.x stable,
> but my ability to do this (short of technical vetoes of ABI-breaking
> changes) is non-existent.
>
> My voting or not voting on backports has nothing to do with what
> other committers choose to do. Just as some chose to have nothing
> to do with backporting to 2.2.x for years, others chose to propose
> and commit backports to 2.2.x in those years.
>
> 2.2.x went into an effective feature-freeze when a majority of the
> httpd project voted that it be frozen, and then began rejecting
> destabilizing changes. 2.2.x went EOL when a vast majority of
> the httpd project declared they would no longer participate in
> its maintenance after {date}. I structured it as a poll so we would
> all understand at what point there would not be three participants
> in future maintenance releases.
>
> My individual desire is irrelevant.
>
>
>> To be honest, I don't care at all what happens re: trunk and
>> the 2.5.0 tag, etc as long as it does NOT restrict what we
>> can do for 2.4.x. My fear is that one goal behind tagging 2.5.x
>> is hamstringing 2.4.x.
>
> Which became justification for hamstringing all future releases?
>
>
>> So, for the record, just so we are all clear, what is your desire/goal
>> in all this as far as 2.4.x is related?
>
> That 2.4.x needs a minimum of three committers to continue to make
> releases, that is project policy. If 2.4.x ends up being a 20-year LTS
> maintained release, it reflects that there are 3+ committers who make
> make that happen, not that there is or isn't demand for it.
>
> And if maintainers are interested in specific trunk/ efforts, then by
> all means propose and adopt those for backport. Those who have
> an itch to scratch should scratch that itch.
>
> Remember I have no more power to block a 2.4.x branch release than
> another committer could veto a trunk release. And we have nothing but
> technical justification to base rejecting either a new submission or some
> backport proposal.
>
>
> Beyond that, I'll vote up some good bugfix backports, veto breaking
> changes, and otherwise ignore the stream of potentially unwise
> enhancements and leave it to those who want to spend their free
> cycles to evaluate those proposals, and make those calls. I expect
> 2.4.x to eat much less of my own time, going forwards.
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> Reiterating again, that we disagree about who our preferred
>> approaches are serving and they are disingenuous toward.
>> Again, a value judgement.
>>
>
> Assuming we go ahead and tag 2.5.0, what is your intention
> related to 2.4.x? My understanding is that your desire is to
> place it under "maintenance mode", that is, no functional
> backports to 2.4.x.
>
> Is this correct?
No, that's a misunderstanding... my desire is to have 2.4.x stable,
but my ability to do this (short of technical vetoes of ABI-breaking
changes) is non-existent.
My voting or not voting on backports has nothing to do with what
other committers choose to do. Just as some chose to have nothing
to do with backporting to 2.2.x for years, others chose to propose
and commit backports to 2.2.x in those years.
2.2.x went into an effective feature-freeze when a majority of the
httpd project voted that it be frozen, and then began rejecting
destabilizing changes. 2.2.x went EOL when a vast majority of
the httpd project declared they would no longer participate in
its maintenance after {date}. I structured it as a poll so we would
all understand at what point there would not be three participants
in future maintenance releases.
My individual desire is irrelevant.
> To be honest, I don't care at all what happens re: trunk and
> the 2.5.0 tag, etc as long as it does NOT restrict what we
> can do for 2.4.x. My fear is that one goal behind tagging 2.5.x
> is hamstringing 2.4.x.
Which became justification for hamstringing all future releases?
> So, for the record, just so we are all clear, what is your desire/goal
> in all this as far as 2.4.x is related?
That 2.4.x needs a minimum of three committers to continue to make
releases, that is project policy. If 2.4.x ends up being a 20-year LTS
maintained release, it reflects that there are 3+ committers who make
make that happen, not that there is or isn't demand for it.
And if maintainers are interested in specific trunk/ efforts, then by
all means propose and adopt those for backport. Those who have
an itch to scratch should scratch that itch.
Remember I have no more power to block a 2.4.x branch release than
another committer could veto a trunk release. And we have nothing but
technical justification to base rejecting either a new submission or some
backport proposal.
Beyond that, I'll vote up some good bugfix backports, veto breaking
changes, and otherwise ignore the stream of potentially unwise
enhancements and leave it to those who want to spend their free
cycles to evaluate those proposals, and make those calls. I expect
2.4.x to eat much less of my own time, going forwards.
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Reiterating again, that we disagree about who our preferred
> approaches are serving and they are disingenuous toward.
> Again, a value judgement.
>
Assuming we go ahead and tag 2.5.0, what is your intention
related to 2.4.x? My understanding is that your desire is to
place it under "maintenance mode", that is, no functional
backports to 2.4.x.
Is this correct?
To be honest, I don't care at all what happens re: trunk and
the 2.5.0 tag, etc as long as it does NOT restrict what we
can do for 2.4.x. My fear is that one goal behind tagging 2.5.x
is hamstringing 2.4.x.
So, for the record, just so we are all clear, what is your desire/goal
in all this as far as 2.4.x is related?
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Nov 5, 2017 at 3:44 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> It is safer. It is incredibly time consuming to effectively perform
>> a full audit of the state of trunk vs current. If we were to take this
>> approach, it seems necessary to revert all of the unaccepted
>> changes that live on trunk. E.g. rename trunk/ to scratchpad/
>> and fork 2.4.x as trunk/ - 2.5.x.
>>
>> It is also disrespectful to our fellow committers who wrote and
>> committed code to the next iteration of httpd. Few of them are
>> still participating actively, which is little surprise given that their
>> code is still not distributed after 7 years, and active committers
>> are now advocating trashing it. Not only dismissing those who
>> coded before you, but foretelling what contributors should
>> expect of their contributions moving forwards.
>>
>
> IMO, we are not being disrespectful at all... we are actively
> pushing code from trunk to 2.4.x, but only when the PMC
> is ready, willing and able to "stand behind it", which
> is done via a backport proposal and the required 3 +1s.
> If the real goal and intent is to get that stuff out, then,
> IMO at least, the "best" way to do it is to propose a
> backport, or provide the backport, so that the PMC
> can allow it to be in 2.4.x. I see many people doing
> this. This is good for our contributors and our users.
"This is good" is opinion, not fact. My opinion that preventing
2.6.0 from replacing insufficient APIs with cleaner APIs "is bad".
Again, different value judgements from the same set of facts.
> I actually encourage people to:
>
> svn diff https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x https://svn.apache.org/repos/asf/httpd/httpd/trunk | colordiff
>
> and review the actual code diffs (a chunk of the diffs are in
> the docs, *.mak or *.dep files). From those, which diffs
> are really "unportable" to 2.4.x?
And I agree with your encouragement, suggest that it is
easier to read for content with -x --ignore-all-space.
That has nothing to do with those committers who wish to
work through 2.5.x towards 2|3.next.
> My reasons for "eager" back porting is that there are
> things in trunk that people want, and need, *now*, not
> as some nebulous time in the future when 2.6/3.0 is released
> and GA and easily obtainable and readily bundled in distros.
> Putting some arbitrary moratorium on backports simply
> to force-drive 2.6/3.0 seems disingenuous to those
> contributors and esp our users.
Reiterating again, that we disagree about who our preferred
approaches are serving and they are disingenuous toward.
Again, a value judgement.
Neither of our value judgments need to "win". If one does
"win", then a subset of the project consumers are poorly served.
If they coexist, neither subset of the community needs to demand
that others must scratch their own itch... what "encouragement"
has escalated to. By unilaterally denying any future development
releases, the project is locked in infinite "maintenance" releases.
You can call these enhancements "improvements" and others
can call these "destabilizing" and neither value judgement is
necessarily wrong.
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> It is safer. It is incredibly time consuming to effectively perform
> a full audit of the state of trunk vs current. If we were to take this
> approach, it seems necessary to revert all of the unaccepted
> changes that live on trunk. E.g. rename trunk/ to scratchpad/
> and fork 2.4.x as trunk/ - 2.5.x.
>
> It is also disrespectful to our fellow committers who wrote and
> committed code to the next iteration of httpd. Few of them are
> still participating actively, which is little surprise given that their
> code is still not distributed after 7 years, and active committers
> are now advocating trashing it. Not only dismissing those who
> coded before you, but foretelling what contributors should
> expect of their contributions moving forwards.
>
IMO, we are not being disrespectful at all... we are actively
pushing code from trunk to 2.4.x, but only when the PMC
is ready, willing and able to "stand behind it", which
is done via a backport proposal and the required 3 +1s.
If the real goal and intent is to get that stuff out, then,
IMO at least, the "best" way to do it is to propose a
backport, or provide the backport, so that the PMC
can allow it to be in 2.4.x. I see many people doing
this. This is good for our contributors and our users.
I actually encourage people to:
svn diff https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x https://svn.apache.org/repos/asf/httpd/httpd/trunk | colordiff
and review the actual code diffs (a chunk of the diffs are in
the docs, *.mak or *.dep files). From those, which diffs
are really "unportable" to 2.4.x?
My reasons for "eager" back porting is that there are
things in trunk that people want, and need, *now*, not
as some nebulous time in the future when 2.6/3.0 is released
and GA and easily obtainable and readily bundled in distros.
Putting some arbitrary moratorium on backports simply
to force-drive 2.6/3.0 seems disingenuous to those
contributors and esp our users.
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 5, 2017 11:49, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
Suggested reading; it is interesting to me how many participants of these
threads are now absent, and of those who remain, who are sitting on
opposite positions of what they held before;
http://markmail.org/message/w2bwnszl7tx766oc
Switch httpd-2.0 to RTC?
Apr 8, 2002 5:38:40 pm
http://httpd.markmail.org/thread/w5syvr5temiylewp
CTR policy for experimental modules in A2.0?
RTC killed the open source project
Aug 8, 2005 1:32:51 pm
Additional useful reading... Not necessarily decisive but illustrative of
prior considerations...
http://httpd.markmail.org/thread/fjq2ljjipqikyyev
the wheel of httpd-dev life is surely slowing down, solutions please
Nov 10, 2003 5:14:35 pm
http://httpd.markmail.org/thread/wftwjrv37mbn2fz4
Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
Nov 16, 2004 5:10:17 pm
http://httpd.markmail.org/thread/ykbng2dqkxxjwd5g
[PROPOSAL] How to treat release candidate branches
Feb 23, 2005 8:03:48 am
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 5, 2017 10:47, "Eric Covener" <co...@gmail.com> wrote:
On Sun, Nov 5, 2017 at 12:53 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Nov 4, 2017 23:18, "Jacob Champion" <ch...@gmail.com> wrote:
>
> On Nov 4, 2017 8:44 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>
>>> Will it be a fork of latest 2.4.x and trunk things will have to be
>>> proposed, voted and backported?
>
> That is not how httpd has operated previously. Again, a proposal
> to change the process and a vote is needed if this is desired.
>
>
> Time for a vote I think.
>
> Time to read the archives. Then perhaps time for a concrete proposal, to
> then say so long to the remaining holdouts for evolutionary or disruptive
> development, and for the last hangers-on to ride this project into its
> twilight.
Time to read the code of conduct.
---------
Asking for the PMC to examine why the project adopted the model it has is
not a CoC violation by my reading. That is using CoC as a club to end
disagreement.
Suggested reading; it is interesting to me how many participants of these
threads are now absent, and of those who remain, who are sitting on
opposite positions of what they held before;
http://markmail.org/message/w2bwnszl7tx766oc
Switch httpd-2.0 to RTC?
Apr 8, 2002 5:38:40 pm
http://httpd.markmail.org/thread/w5syvr5temiylewp
CTR policy for experimental modules in A2.0?
RTC killed the open source project
Aug 8, 2005 1:32:51 pm
Nothing wrong with proposing changes, discussing and holding votes, but
seems unwise to do so without reviewing the original discussion that led to
the original vote results and resulting policy, IMO.
Re: We have soon 5 SVN repo's
Posted by Eric Covener <co...@gmail.com>.
On Sun, Nov 5, 2017 at 12:53 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Nov 4, 2017 23:18, "Jacob Champion" <ch...@gmail.com> wrote:
>
> On Nov 4, 2017 8:44 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>
>>> Will it be a fork of latest 2.4.x and trunk things will have to be
>>> proposed, voted and backported?
>
> That is not how httpd has operated previously. Again, a proposal
> to change the process and a vote is needed if this is desired.
>
>
> Time for a vote I think.
>
> Time to read the archives. Then perhaps time for a concrete proposal, to
> then say so long to the remaining holdouts for evolutionary or disruptive
> development, and for the last hangers-on to ride this project into its
> twilight.
Time to read the code of conduct.
--
Eric Covener
covener@gmail.com
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 4, 2017 23:18, "Jacob Champion" <ch...@gmail.com> wrote:
On Nov 4, 2017 8:44 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>> Will it be a fork of latest 2.4.x and trunk things will have to be
>> proposed, voted and backported?
That is not how httpd has operated previously. Again, a proposal
to change the process and a vote is needed if this is desired.
Time for a vote I think.
Time to read the archives. Then perhaps time for a concrete proposal, to
then say so long to the remaining holdouts for evolutionary or disruptive
development, and for the last hangers-on to ride this project into its
twilight.
Re: We have soon 5 SVN repo's
Posted by Jacob Champion <ch...@gmail.com>.
On Nov 4, 2017 8:44 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote:
>> Will it be a fork of latest 2.4.x and trunk things will have to be
>> proposed, voted and backported?
That is not how httpd has operated previously. Again, a proposal
to change the process and a vote is needed if this is desired.
Time for a vote I think.
--Jacob
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Nov 6, 2017 at 5:48 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Nov 5, 2017, at 9:39 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Nov 5, 2017 12:21, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
>> Sorry Bill, but that's not right. trunk is not a "branch" that directly
>> leads
>> to a releasable branch. Its simply not. It was not intended to
>> be. You cannot now claim that any inability, or concern, about
>> releasing a RTC "sandbox" somehow implies your conclusion.
>>
>> It has always been so for 2.2.0 and 2.4.0. You are shifting perspective and
>>demonstrably were entirely engaged in every prior version-minor discussion.
> Because they were/are direct-to-release branches. trunk is not.
I repeat, 2.1.x which became 2.2.0 were released from trunk; once it
reached beta it was branched to 2.2.x, trunk became 2.3.x.
2.3.x which became 2.4.0 were released from trunk, until it reached
beta and was branched to 2.4.x, and trunk became 2.5.x.
Neither of the two release cycles below experienced anything like a
complete feature scope or audit of 2.1.1-alpha vs 2.0.current or
2.3.0-alpha vs 2.2.current as now proposed. 2.2.0 and 2.4.1 were
released as GA in spite of this "oversight."
Any claims that httpd trunk 2.5.x cannot be tagged as 2.5.0 for
consideration as an alpha or beta candidate by a majority vote
of the PMC must be based on a veto of specific code. That code
has lived on trunk, just as 2.1.1-alpha and 2.3.0-alpha had lived
on trunk for a very, very long time, plenty of time to raise veto
objections to the code.
Any committer (certainly any PMC member) can proceed without
unanimous consent, the project's charter and the character of
the entire foundation is that no one individual can block a release
of the next version of the software, individuals can block major
changes to the software in a veto which they justify (and we hope
they offer an agreeable compromise path to resolving the veto.).
As you are a participant in this process as demonstrated below, it's
a little hard for me to believe you aren't fully aware of the process.
Your participation in this project since it's inception suggests you
contributed to setting forth these very principals. Why you've
chosen to invent an entire set of hurdles that don't exist yet is
beyond me, without framing this as a policy change, and I'm sorry
for whatever antagonism it is costing to repeatedly explain these
documented principals to everyone, old hands and newcomers alike.
I'd much rather debate merits of newly proposed policy on the merits
of the proposed changes, rather than respond to untruths.
Ver Status Rev Origin Date Committer Commit Log
2.1.1/ -alpha 105913 trunk 2004-11-19 jerenkrantz The fact that I
can't roll to save my life isn't going to cause to abandon 2.1.1…
2.1.2/ -alpha 111352 trunk 2004-12-08 jerenkrantz Tag 2.1.2.
2.1.3/ -alpha (*) 154972 trunk 2005-02-22 jerenkrantz Tag 2.1.3
2.1.4/ (nr) 157727 trunk 2005-03-16 striker Tag 2.1.4
2.1.5/ (nr) (*) 191099 trunk 2005-06-17 pquerna Create the 2.1.5 Tag.
2.1.6/ -alpha 201578 trunk 2005-06-27 pquerna Server-Side Tags
are fun. Copy trunk to 2.1.6.
2.1.7/ -beta 234113 branches/2.2.x 2005-09-12 pquerna Tag 2.1.7
2.1.8/ -beta 291487 branches/2.2.x 2005-10-01 pquerna Tag 2.1.8
2.1.9/ -beta 329515 branches/2.2.x 2005-11-05 pquerna Tag 2.1.9 for release
2.1.10/ (nr) 345696 branches/2.2.x 2005-11-19 pquerna Tag the
2.1.10 release.
2.2.0/ -ga 349669 branches/2.2.x 2005-12-01 pquerna Tag 2.2.0.
2.2.1/ (nr) 390731 branches/2.2.x 2006-04-01 pquerna Tag httpd
2.2.1 from the 2.2.x branch.
2.3.0/ (nr) 724095 trunk 2008-12-06 pquerna Tag trunk as 2.3.0.
2.3.1/ (nr) 730918 trunk 2009-01-02 pquerna Tag 2.3.1 from trunk.
2.3.2/ (nr) 757423 trunk 2009-03-23 pquerna Tag 2.3.2.
2.3.3/ (nr) 835030 trunk 2009-11-11 pquerna create 2.3.3 release tag.
2.3.4/ -alpha 884300 trunk 2009-12-08 pquerna create 2.3.4 tag
2.3.5/ -alpha 901882 trunk 2010-01-26 pquerna tag 2.3.5
2.3.6/ -alpha (*) 953681 trunk 2010-06-21 jim Tag 2.3.6 alpha
2.3.7/ (nr) 987150 trunk 2010-08-19 jim Tag 2.3.7
2.3.8/ -alpha (*) 988617 trunk 2010-08-24 jim Tag httpd-2.3.8
2.3.9/ (nr) 1038142 trunk 2010-11-23 jim Tag trunk as 2.3.9-alpha
2.3.10/ -alpha 1045184 trunk 2010-12-21 jim Tagging trunk as 2.3.10 (alpha)
2.3.11/ -beta 1075920 trunk 2011-03-07 jim Tag trunk as 2.3.11
2.3.12/ -beta 1101854 trunk 2011-05-23 jim Tagging trunk as 2.3.12-beta
2.3.13/ (nr) 1140732 trunk 2011-06-28 jim Tag as 2.3.13
2.3.14/ -beta 1152858 trunk 2011-08-01 jim Tagging trunk1152854 as 2.3.14
2.3.15/ -beta 1199517 trunk 2011-11-08 jim Tagging trunk as 2.3.15-dev
2.3.16/ -beta 1214788 branches/2.4.x 2011-12-15 jim Tag 2.3.16
2.4.0/ (nr) 1232070 branches/2.4.x 2012-01-16 jim Tag trunk as
Apache httpd 2.4.0
2.4.1/ -ga 1243503 branches/2.4.x 2012-02-21 jim Tag HEAD
httpd-2.4.x as 2.4.1
(*) naming, labeling or released status disagreement with archive.apache.org
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 5, 2017, at 9:39 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Nov 5, 2017 12:21, "Jim Jagielski" <jim@jagunet.com <ma...@jagunet.com>> wrote:
>
> Sorry Bill, but that's not right. trunk is not a "branch" that directly leads
> to a releasable branch. Its simply not. It was not intended to
> be. You cannot now claim that any inability, or concern, about
> releasing a RTC "sandbox" somehow implies your conclusion.
>
> It has always been so for 2.2.0 and 2.4.0. You are shifting perspective and demonstrably were entirely engaged in every prior version-minor discussion.
>
Because they were/are direct-to-release branches. trunk is not.
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 5, 2017 12:21, "Jim Jagielski" <ji...@jagunet.com> wrote:
Sorry Bill, but that's not right. trunk is not a "branch" that directly
leads
to a releasable branch. Its simply not. It was not intended to
be. You cannot now claim that any inability, or concern, about
releasing a RTC "sandbox" somehow implies your conclusion.
It has always been so for 2.2.0 and 2.4.0. You are shifting perspective and
demonstrably were entirely engaged in every prior version-minor discussion.
So what you claim is not the norm, it is deviation from the norm and
practice.
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>>
>
> It is safer. It is incredibly time consuming to effectively perform
> a full audit of the state of trunk vs current. If we were to take this
> approach, it seems necessary to revert all of the unaccepted
> changes that live on trunk. E.g. rename trunk/ to scratchpad/
> and fork 2.4.x as trunk/ - 2.5.x.
>
You state that "It is incredibly time consuming to effectively perform a
full audit of the state of trunk vs current" which would imply that trunk
deviates so significantly from current that we have no idea of where trunk is.
You are against a full audit because it is time consuming? That those who
wish that the QA aspects of trunk, *as a releasable branch which
has been under RTC for year* be verified are somehow
obstructionists? I think it's called due diligence.
>
> If this is in fact the state of httpd, that trunk/ can no longer be
> released, that committers and PMC performed no oversight of
> the repository, it seems like a stunning indictment of all of us,
> and the obvious reaction by ASF board would be to strip the
> committer privileges of all, dissolve the PMC, and use the
> metric of trunk commit -> dev@ feedback to repopulate the
> project with those who demonstrated some participation over
> the trunk/ review process within the past seven years. Every
> ex-officer of the project and foundation would be ineligible to
> participate as a PMC or committer due to willful negligence
> for any such a restart, myself included.
Sorry Bill, but that's not right. trunk is not a "branch" that directly leads
to a releasable branch. Its simply not. It was not intended to
be. You cannot now claim that any inability, or concern, about
releasing a RTC "sandbox" somehow implies your conclusion.
Re: We have soon 5 SVN repo's
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sat, Nov 4, 2017 at 10:48 AM, Eric Covener <co...@gmail.com> wrote:
> On Sat, Nov 4, 2017 at 9:28 AM, Marion & Christophe JAILLET
> <ch...@wanadoo.fr> wrote:
>> Hi,
>>
>> So 2.5.0-alpha will be RTC.
Howso? I haven't seen a vote. There can be no 2.5.x-GA. We only
deliver 2.5.x-alpha|beta. Without a proposal followed by a majority
vote, this is the process we adopted and documented long ago
and follow to this day. For very specific reasons...
As a committee we long ago voted that GA releases follow RTC
and development follows CTR. You can find the very lengthy
debates on the merits in dev@ list history. This was a compromise
between committers who support current users and hate disruption,
and committers with new ideas who hate obstacles to development.
The compromise ensured the released software was generally not
disruptively changed, while the project as a whole was not closed
off to evolution.
Two different groups of committers, two different solutions. When
only one development methodology is permitted, only one group
of committers will remain. We are largely already there, if you
look at the list of contributors to that compromise.
> It is not clear to me when we'd branch trunk to 2.5 vs. just rolling
> alphas from trunk.
There is a valid point that once the ABI of a 2.next is stable, that
it is disruptive to development/developers, and they need a place
to commit code, so a fork at ABI-stable makes sense. 2.5.x-alpha
is nowhere near being declared stable.
>> Will it be a fork of latest 2.4.x and trunk things will have to be
>> proposed, voted and backported?
That is not how httpd has operated previously. Again, a proposal
to change the process and a vote is needed if this is desired.
I expect it will result in the final arc of project stagnation.
>> Or will it be a fork from trunk with things likely never (IMHO) really
>> reviewed?
Thanks for clarifying this is your opinion, shared by several others.
I strongly disagree.
Our responsibility is to monitor code contributed to httpd, as both
PMC and project committers. There has been plenty of specific
technical feedback to some significant number of commits to trunk,
before they were ever proposed for backport.
Committers do watch commits@. If your and other's opinion is
true, it seems this is a reflection of a 7-year technical deficit of
not watching commits yourself as closely as you wished to.
Trashing 7 years of activity over personal lack of attention seems
to be the worst possible outcome for the health of a publicly coded
open source project.
>> My own opinion is a copy of 2.4.x + RTC process because I think it is
>> safer. But I'm not sure it is what others have in mind.
>
> Definitely trunk, but I considered this same kind of 2.4->2.5 proposal
> but decided to keep quiet. A big dependency on this choice is the
> goals and the effect on people with other goals.
It is safer. It is incredibly time consuming to effectively perform
a full audit of the state of trunk vs current. If we were to take this
approach, it seems necessary to revert all of the unaccepted
changes that live on trunk. E.g. rename trunk/ to scratchpad/
and fork 2.4.x as trunk/ - 2.5.x.
It is also disrespectful to our fellow committers who wrote and
committed code to the next iteration of httpd. Few of them are
still participating actively, which is little surprise given that their
code is still not distributed after 7 years, and active committers
are now advocating trashing it. Not only dismissing those who
coded before you, but foretelling what contributors should
expect of their contributions moving forwards.
I view this proposal as an acknowledgement that httpd has been
completed, that further evolution is not realistic, and httpd's
current adoption glide-path is terminal. All software reaches
end-of-life. I haven't booted CP/M in the past 20 years. I haven't
used kermit in 25. Not even a telnet session in the past 15 yrs.
But I'm hoping httpd isn't at this point. The CTR/RTC even-odds
was baked to compromise between this stale, uncompromising
"gatekeeper" approach to httpd maintenance, and fresh httpd
coding. But because further version major.minor releases were
abandoned, a large amount of disruptive code keeps landing
on the maintenance branch, because "there are no other
prospects" for ever getting the code released.
The worst offenders of throwing fresh new development at what
others wish to be a maintenance branch are the very same who
had argued against another trunk release whatsoever. Why?
Because of this very dichotomy. "I don't want to see regressions
in httpd. But I want my code released." And so, we have the worst
of both outcomes, a disruptive "stable" and a dead "development"
avenue.
If this is in fact the state of httpd, that trunk/ can no longer be
released, that committers and PMC performed no oversight of
the repository, it seems like a stunning indictment of all of us,
and the obvious reaction by ASF board would be to strip the
committer privileges of all, dissolve the PMC, and use the
metric of trunk commit -> dev@ feedback to repopulate the
project with those who demonstrated some participation over
the trunk/ review process within the past seven years. Every
ex-officer of the project and foundation would be ineligible to
participate as a PMC or committer due to willful negligence
for any such a restart, myself included.
I'm not that pessimistic. I did read commits. I build and run
trunk. I don't know that they don't contain bugs. This is the
value of all of our previous lengthy alpha -> beta transition
phases. And I expect nothing different this cycle, a testing
and review cycle to validate the current state of the code.
HOWEVER, if there are committers with an itch to scratch,
who want to take modules or mpms or core functionality or
even main() to task and review these line by line for all of
the intended development changes that live on trunk... that
is an itch. Nobody would block or disrespect reports of any
human-iterated audit of the state of our code, from any of a
delta-view, fuzzing results, whitehat vulnerability probes or
any of dozens of other methodologies to find flaws. (We will
regularly dismiss automated discovery of ""defects"" which
are no such thing, and when given a dump from such tools,
nobody here has the patience to find the five gold invitations
in a pile of 1,600 "issues".)
The sooner we publish 2.5.x-alpha, the sooner we resurrect
our committers efforts to improve httpd, and the later the
eventual retirement of this project will occur. Let's get testing
and reviewing, thank you Daniel for simplifying this workflow!
Re: We have soon 5 SVN repo's
Posted by Eric Covener <co...@gmail.com>.
On Sat, Nov 4, 2017 at 9:28 AM, Marion & Christophe JAILLET
<ch...@wanadoo.fr> wrote:
> Hi,
>
> So 2.5.0-alpha will be RTC.
> Good for me, it is what I personally prefer.
It is not clear to me when we'd branch trunk to 2.5 vs. just rolling
alphas from trunk.
Bill seemed to have the strongest opinion on this, but I don't want to
read too much into the language.
>
> Will it be a fork of latest 2.4.x and trunk things will have to be
> proposed, voted and backported?
> Or will it be a fork from trunk with things likely never (IMHO) really
> reviewed?
>
> My own opinion is a copy of 2.4.x + RTC process because I think it is
> safer. But I'm not sure it is what others have in mind.
Definitely trunk, but I considered this same kind of 2.4->2.5 proposal
but decided to keep quiet. A big dependency on this choice is the
goals and the effect on people with other goals.
(Sorry if you see two copies of this, I thought I had replied but my
outgoing mail / thread had no trace. I also went out on a limb on the
first note; re delayed 2.5 branch that may be wrong)