You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Steffen <in...@apachelounge.com> on 2017/11/04 10:03:31 UTC
We have soon 5 SVN repo's
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.
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)
Re: We have soon 5 SVN repo's
Posted by Marion & Christophe JAILLET <ch...@wanadoo.fr>.
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 Graham Leggett <mi...@sharp.fm>.
On 04 Nov 2017, at 12:03 PM, Steffen <in...@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 William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 4, 2017 05:04, "Steffen" <in...@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.
I hope not.
Trunk tracks new development. There is no distinction between 2.5.x and
trunk, until we vote to freeze 2.6.0 API, that is still some time off. At
that branch Trunk becomes 2.7.x (or 3.1.x). That's one, and sometime next
year the third.
2.4.x is maintenance, and backport proposals route through STATUS. That is
the second.
patches/2.4.x tracks STATUS proposals into 2.4. The very same thing we've
done since 1996, except that this gives us a predictable place to deliver
them from, as opposed to people.apache.org/~user/ URLs, github forks or
gists or other personal preferences. Its use is optional for the simplest
backports which simply apply.
As a rule 2.4 backports are RTC. Platform quirks and docs are CTR. While
trunk is CTR, major trunk/ patches should also be proposed first to dev@.
So patches/trunk can be useful in these extreme cases.
In any case that was three (counting 2.2.x), is now two, and back to three
when we are finished with 2.5.x-alpha. Hope this clarifies when and where.
Re: We have soon 5 SVN repo's
Posted by Luca Toscano <to...@gmail.com>.
Hi,
2017-11-04 23:43 GMT+01:00 Helmut K. C. Tessarek <te...@evermeet.cx>:
> On 2017-11-04 18:25, Graham Leggett wrote:
> > If you aren’t willing to do the four things you’ve mentioned above,
> > your code has pretty much disqualified itself from consideration, and
> > what you want is largely irrelevant.
>
> This attitude is exactly the reason why Apache is losing marketshare
> against Nginx.
>
> > We have a development and release process that has been in place and
> > served us well for almost two decades, and most of the popular
> > release processes that are in vogue today are just more complex
> > versions of our existing workflow. I would recommend learning how our
> > release process works before suggesting it be replaced (with a
> > workflow not unlike our existing).
>
> Seriously? You must be joking. Also, I'm not the one who suggested to
> replace it, but pointed out a few arguments for git, which was suggested
> by Stefan Priebe. Or the be exact, he asked "why not git?".
>
> > Every project I’ve been involved in, from Apache C projects to Maven
> > based Java projects, to other open source projects like freeradius
> > and gstreamer, has its own set of conventions and ways of doing
> > things. In each case I tailor my contribution to fit the existing
> > project, I don’t expect the project to rearrange itself around me.
>
> Yes, most projects have their own conventions and yes, I tailor my
> contributions towards their processes as well.
>
> However, there are projects, which processes are too extrem and tedious
> and I don't contribute because of them.
>
> I did not suggest to replace your precious work flow, I only showed up
> why people _might_ be put off by it.
I agree with what Graham and Yann wrote before me, but I'd like to add some
info about committing code to the httpd project. I recognize that the
github model is handy to share code and get some credit for it, but in my
opinion with complex projects like httpd the majority of the time to change
even a line of code is spent in research and testing to avoid shipping
broken features or introducing regressions that impact users.
In the beginning it might seem cumbersome to learn the differences about
trunk and 2.4.x for example, but from my experience (I am relatively new to
the project) it is unlikely that a knowledge gap prevents you completely
from shipping new code, unless of course you want to change important core
parts like HTTP protocol handling or MPM internals. In these cases there
are a lot of experienced people that are willing to help and follow up if
the change is worth it, it is just a matter of asking to the community :)
New code can be easily submitted via a patch in bugzilla, discussed in
there and eventually see it merged (if the code/tests pass certain
standards) by one of the httpd committers. Credits will be added to the
commit to recognize merit, and usually good attitude and participation to
the dev community daily life leads to a committer account (as Yann said,
everybody is happy to see new people joining the project!). This is not
that different from what you can currently do in github, but I admit that
the "interface" is way less immediate and user friendly.
Luca
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 4, 2017, at 6:43 PM, Helmut K. C. Tessarek <te...@evermeet.cx> wrote:
>
> On 2017-11-04 18:25, Graham Leggett wrote:
>> If you aren’t willing to do the four things you’ve mentioned above,
>> your code has pretty much disqualified itself from consideration, and
>> what you want is largely irrelevant.
>
> This attitude is exactly the reason why Apache is losing marketshare
> against Nginx.
>
Well, I disagree. The exact reason why, is that nginx has a huge marketing
force and a huge sales team while still portraying themselves as
an open source project, when they are (obviously) a single
vendor, open core project.
Re: We have soon 5 SVN repo's
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 4, 2017 at 11:43 PM, Helmut K. C. Tessarek
<te...@evermeet.cx> wrote:
> On 2017-11-04 18:25, Graham Leggett wrote:
>> If you aren’t willing to do the four things you’ve mentioned above,
>> your code has pretty much disqualified itself from consideration, and
>> what you want is largely irrelevant.
>
> This attitude is exactly the reason why Apache is losing marketshare
> against Nginx.
Possibly, Apache httpd isn't really doing marketing either..
Anyway, your opinion on our weakness in attracting new contibutors is
not to be neglected.
You seem to point to a complicated workflow, and I don't think it is
(really) once you are a committer, so maybe the complication is to
become a committer?
[quote from the other message]
> All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a
> new feature or patch branch) and send a PR. (X reviewers are required,
> and boom it gets merged. Don't forget all the nice CI that can be
> triggered before or after the merge.)
I read this as an easier access to or better consideration of
pull/merge requests (à la git-hub/lab), am I correct?
Our github mirror allows this already, but we may not be good at
treating them quickly enough (I try from time to time, but there are
requests on our mailing lists and bugzilla that busy me and each
committer already..).
How about if this requests were (auto-)routed to our dev@ mailing list
(in both ways, if that's ever possible), do you think it will help
git-ers to contribute more?
It shouldn't be a matter of the used SCM (ISTM that committers can
already use git to commit to httpd), and I don't feel that our
branchs' handling is more complicated than anywhere else.
Could you please elaborate on a concrete contribution procedure you would use?
Regards,
Yann.
Re: We have soon 5 SVN repo's
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-11-05 06:08, Graham Leggett wrote:
> Your desire for us to host your private feature branches, and hand out logins to our infrastructure to people who openly profess not to care about our projects is not something I would like to see encouraged.
You still do not understand what I am saying. And you are twisting my words.
Maybe you are referring to the following:
---
Commit the patch to the 2.4.x branch (as a
new feature or patch branch) and send a PR. (X reviewers are required,
and boom it gets merged. Don't forget all the nice CI that can be
triggered before or after the merge.)
---
Where do I say that I want you to host my private feature branches?
git is distributed and decentralized. I create a branch locally and send
a PR (which could trigger a CI run on your repo as part of the PR).
But you are not wrong. Core developers should have the possibility to
create feature and patch branches on the remote (main) repo (in case of
git). This does not mean that I want to push my branches to the main
repo as a one time or casual contributor. Theoretically you could setup
access control in a way that people can't push to certain branches,
and/or are only allowed to create branches as subbranches and whatnot.
The possibilities are endless. But this is another story and I never
wanted to discuss this in the first place.
Also, I never said I do not care about your projects. Do I really have
to explain how a statement refers to a quote?
---
Graham: you expressed a definite unwillingness to follow our process,
Graham: which starts by creating a patch for trunk.
KC: I don't really care, because
KC: I don't have time to contribute to this project anyway.
---
This means I currently don't care about the process, because I don't
have the time to contribute.
Then 2 sentences later I also wrote the following:
---
If I really wanted to start writing code (new features, internals, ...)
for httpd, I'd be willing to learn the process.
---
I also never said I wanted login credentials. I said the current system
requires a developer to have login credentials.
e.g. with git and a PR concept, there's no need to have login
credentials (but CI can still be used)
Anyway, I'm done. You are either not reading my mails in context or
ignoring what I'm writing. Like the process this conversation is too
tedious for me.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: We have soon 5 SVN repo's
Posted by Graham Leggett <mi...@sharp.fm>.
On 05 Nov 2017, at 4:01 AM, Helmut K. C. Tessarek <te...@evermeet.cx> wrote:
>> No, you expressed a definite unwillingness to follow our process,
>> which starts by creating a patch for trunk.
>
> I think you misunderstood, at least partly. I don't really care, because
> I don't have time to contribute to this project anyway.
>
> I was just talking about why others _might_ not want to. Why would I do
> that, you may ask. The topics of VCS and release strategy came up
> several times during the past years and the discussions never really
> changed anything.
If following a release process is too difficult, then following the rest of our processes simply isn’t going to happen. These further processes including our ABI rules on backwards compatibility to ensure that our users can confidently upgrade to a new httpd point release secure in the knowledge that this won’t break their server. This includes our oversight rules, to ensure that changes that appear in our releases have the required number of approvals to be allowed to be called a release of code of the ASF.
There are those who genuinely do not have time to become fully engaged in our project, and so will contribute a patch to a mailing list or bugzilla in the hope that someone else takes it through the process, and for that we are very grateful. Your desire for us to host your private feature branches, and hand out logins to our infrastructure to people who openly profess not to care about our projects is not something I would like to see encouraged.
Regards,
Graham
—
Re: We have soon 5 SVN repo's
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-11-04 19:18, Graham Leggett wrote:
> No, you expressed a definite unwillingness to follow our process,
> which starts by creating a patch for trunk.
I think you misunderstood, at least partly. I don't really care, because
I don't have time to contribute to this project anyway.
I was just talking about why others _might_ not want to. Why would I do
that, you may ask. The topics of VCS and release strategy came up
several times during the past years and the discussions never really
changed anything.
If I really wanted to start writing code (new features, internals, ...)
for httpd, I'd be willing to learn the process.
However, I would not do the same for patches. If I were to find a bug
and had a patch for it, I'd not want to follow your process.
I'd send off the patch to the list and you can do whatever you want with
it. I would not be wasting my time to learn a tedious process for
submitting a patch.
And I am not talking about core developers, but people who find
something, fix it, and want to contribute their fix back to the project.
A lot of projects live because of these casual contributions and Apache
httpd would attract more devs for these kind of contributions with an
easier process. That's all that I'm saying.
>> Yes, most projects have their own conventions and yes, I tailor my
>> contributions towards their processes as well.
> Except in this case.
Yes and no, as mentioned before there's a difference between core
developer, casual contributor, and one time contributor.
On the other hand, my hint towards CI was not without reason.
I do not know your current CI pipeline or if you even have one, but
working with git and branches, triggers and plugins makes the process
very convenient. Although I'm sure you can get this done with SVN as well.
How often was a release thrown out because some tests failed after
tagging? If you used CI and after every commit or a merge to a certain
branch the entire test suite were triggered (on all OSes/systems),
wouldn't that make your job a lot easier?
Just saying... ...not forcing anything on you...
(To be clear, this is my opinion, not telling you what to do.)
> Unfortunately you’re pointing out the obvious. There are a number of
> ways of doing things, and projects make different decisions to meet
> their needs and objectives. That way is sometimes not your favoured
> way. If we constantly changed our process, we’d not serve our
> community, and ultimately serving our community is the point.
As you mentioned before, you haven't changed anything for the last 2
decades, so talking about changing something constantly is a bit of
stretch, isn't it?
I've worked on IBM DB2 were coding a line item took maybe a few days,
but getting it into the source tree took up to 6 or 8 weeks. That
process was necessary with 2,500 developers and 40,000,000 lines of
code. So, I do understand that certain processes make sense, some others
are just bureaucracy, and others exist because people just do not want
to change them.
I can also tell you that I had patches available for other projects and
I did not contribute them, because I would have had to create yet
another userid for another system, or sign up for another forum, or
subscribe to another mailinglist - just because there was no way to do a
fire-and-forget method of submitting a patch.
Please note, there are differences in contributions and how much a dev
is willing to do for each of them.
"I fix something and they want me to jump through hoops? Sorry, not with
me." - This attitude is quite common, especially if it is a one time
contribution.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: We have soon 5 SVN repo's
Posted by Graham Leggett <mi...@sharp.fm>.
On 05 Nov 2017, at 12:43 AM, Helmut K. C. Tessarek <te...@evermeet.cx> wrote:
>> If you aren’t willing to do the four things you’ve mentioned above,
>> your code has pretty much disqualified itself from consideration, and
>> what you want is largely irrelevant.
>
> This attitude is exactly the reason why Apache is losing marketshare
> against Nginx.
Nginx has their own development process. They don’t use git either, nor do they accept pull requests, and they expect you to follow a well defined process not dissimilar to ours. If I was to contribute to Nginx I would respect their process, not attempt to impose mine on them first.
> Seriously? You must be joking. Also, I'm not the one who suggested to
> replace it, but pointed out a few arguments for git, which was suggested
> by Stefan Priebe. Or the be exact, he asked "why not git?”.
No, you expressed a definite unwillingness to follow our process, which starts by creating a patch for trunk.
> Yes, most projects have their own conventions and yes, I tailor my
> contributions towards their processes as well.
Except in this case.
> However, there are projects, which processes are too extrem and tedious
> and I don't contribute because of them.
>
> I did not suggest to replace your precious work flow, I only showed up
> why people _might_ be put off by it.
Unfortunately you’re pointing out the obvious. There are a number of ways of doing things, and projects make different decisions to meet their needs and objectives. That way is sometimes not your favoured way. If we constantly changed our process, we’d not serve our community, and ultimately serving our community is the point.
Regards,
Graham
—
Re: We have soon 5 SVN repo's
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-11-04 18:25, Graham Leggett wrote:
> If you aren’t willing to do the four things you’ve mentioned above,
> your code has pretty much disqualified itself from consideration, and
> what you want is largely irrelevant.
This attitude is exactly the reason why Apache is losing marketshare
against Nginx.
> We have a development and release process that has been in place and
> served us well for almost two decades, and most of the popular
> release processes that are in vogue today are just more complex
> versions of our existing workflow. I would recommend learning how our
> release process works before suggesting it be replaced (with a
> workflow not unlike our existing).
Seriously? You must be joking. Also, I'm not the one who suggested to
replace it, but pointed out a few arguments for git, which was suggested
by Stefan Priebe. Or the be exact, he asked "why not git?".
> Every project I’ve been involved in, from Apache C projects to Maven
> based Java projects, to other open source projects like freeradius
> and gstreamer, has its own set of conventions and ways of doing
> things. In each case I tailor my contribution to fit the existing
> project, I don’t expect the project to rearrange itself around me.
Yes, most projects have their own conventions and yes, I tailor my
contributions towards their processes as well.
However, there are projects, which processes are too extrem and tedious
and I don't contribute because of them.
I did not suggest to replace your precious work flow, I only showed up
why people _might_ be put off by it.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: We have soon 5 SVN repo's
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Nov 2017, at 10:49 PM, Helmut K. C. Tessarek <te...@evermeet.cx> wrote:
> Let's say I have a patch for the current version of Apache: 2.4.29. What
> now? I have to get it first into 2.5.0 or trunk, which might not even be
> compatible?
Yes.
> So I have to figure out how the code in trunk works?
Yes.
> Then I
> have to do what? Learn SVN and how to use the STATUS file?
Yes.
> I can't even
> commit to a branch (let alone the fact that feature banches do not
> exist) without a userid on svn.apache.org.
Yes.
> All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a
> new feature or patch branch) and send a PR. (X reviewers are required,
> and boom it gets merged. Don't forget all the nice CI that can be
> triggered before or after the merge.)
If you aren’t willing to do the four things you’ve mentioned above, your code has pretty much disqualified itself from consideration, and what you want is largely irrelevant. Apache projects are not drive-by code dumps. You need to care about the community around you who uses and develops this code. Is your code complete and bug free, so other developers aren’t burdened with cleaning up after you? Does your submission follow the established conventions, so everyone else doesn’t have to constantly figure out what special flavour-of-the-month process you’re following today? Did you take the time to figure out how the documentation works, so that people know your code exists and how it works? Have you made your code work in the next development version of httpd on trunk and soon v2.5.0, and not just the current one, so future users don’t see your code suddenly vanish in the next version? What about the last version of httpd, is it relevant there too?
> While I still learned how to use CVS and SVN (which I also used in
> personal projects and hated btw), used other ones like clearcase for
> huge projects (like IBM DB2), the new generation of developers did not
> and - believe me - they don't want to. (I definitely wouldn't want to,
> if I had ever be involved in a project that used git.)
>
> A move to git doesn't mean that this project will gain hundreds of new
> developers over night, but it might give you a chance to streamline the
> current development *and* release process. The rest will follow.
We have a development and release process that has been in place and served us well for almost two decades, and most of the popular release processes that are in vogue today are just more complex versions of our existing workflow. I would recommend learning how our release process works before suggesting it be replaced (with a workflow not unlike our existing).
Every project I’ve been involved in, from Apache C projects to Maven based Java projects, to other open source projects like freeradius and gstreamer, has its own set of conventions and ways of doing things. In each case I tailor my contribution to fit the existing project, I don’t expect the project to rearrange itself around me.
Regards,
Graham
—
Re: We have soon 5 SVN repo's
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 4, 2017 at 11:15 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> So one has to to know trunk if (s)he wants to be a code committer, I
> don't know any other project where it's different, changes always go
> to current first.
Well, I may have spoken too quickly here, there may be projects which
don't work like this, but in any case they'd better have a solid
frontporting procedure for the health of their trunk/master code I
guess.
> It's not a requirement for contributors though, patches on any version
> is always very welcome and will be back/font-ported as needed by a
> committer.
As a side note, frequent contributors to 2.4.x (only) are very likely
to know trunk code quite quickly, and are also very welcome if they
want to become committers.
>
>
> Regards,
> Yann.
Re: We have soon 5 SVN repo's
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Nov 4, 2017 at 10:39 PM, Eric Covener <co...@gmail.com> wrote:
> On Sat, Nov 4, 2017 at 4:49 PM, Helmut K. C. Tessarek
> <te...@evermeet.cx> wrote:
>>
>> All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a
>> new feature or patch branch) and send a PR. (X reviewers are required,
>> and boom it gets merged. Don't forget all the nice CI that can be
>> triggered before or after the merge.)
>
> I don't see the difference in practice.
>
> A contributor can open a bug report or send an email and share their
> changes, or even develop it in git and submit a PR against our r/o
> mirror on github.
>
> But ultimately you've just got a code change. They aren't commiting
> anything or editing STATUS.
>
> If their patch doesn't apply to trunk or 2.4.x, more work is needed
> regardless of the SCM system.
>
> I doubt Graham could describe how to do release management in git much
> more succintly.
I agree, this has nothing to do with the SCM system.
If one can commit directly to 2.4.x, who is going to frontport the
change to trunk?
We don't want fixes or improvements in current release(s) only, but in
future ones too...
So one has to to know trunk if (s)he wants to be a code committer, I
don't know any other project where it's different, changes always go
to current first.
It's not a requirement for contributors though, patches on any version
is always very welcome and will be back/font-ported as needed by a
committer.
Regards,
Yann.
Re: We have soon 5 SVN repo's
Posted by Eric Covener <co...@gmail.com>.
On Sat, Nov 4, 2017 at 4:49 PM, Helmut K. C. Tessarek
<te...@evermeet.cx> wrote:
> On 2017-11-04 11:43, Eric Covener wrote:
>> I'd be surprised if it helped someone who felt overwhelmed by the
>> existence of 5 branches in SVN (no offense intended).
>
> I agree to disagree. Graham's long explanation which still doesn't cover
> certain scenarios is for sure a reason why not more people contribute to
> the project.
> Let's say I have a patch for the current version of Apache: 2.4.29. What
> now? I have to get it first into 2.5.0 or trunk, which might not even be
> compatible? So I have to figure out how the code in trunk works? Then I
> have to do what? Learn SVN and how to use the STATUS file? I can't even
> commit to a branch (let alone the fact that feature banches do not
> exist) without a userid on svn.apache.org.
Contributors do almost none of this. They just need to share a patch.
>
> All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a
> new feature or patch branch) and send a PR. (X reviewers are required,
> and boom it gets merged. Don't forget all the nice CI that can be
> triggered before or after the merge.)
I don't see the difference in practice.
A contributor can open a bug report or send an email and share their
changes, or even develop it in git and submit a PR against our r/o
mirror on github.
But ultimately you've just got a code change. They aren't commiting
anything or editing STATUS.
If their patch doesn't apply to trunk or 2.4.x, more work is needed
regardless of the SCM system.
I doubt Graham could describe how to do release management in git much
more succintly.
Re: We have soon 5 SVN repo's
Posted by "Helmut K. C. Tessarek" <te...@evermeet.cx>.
On 2017-11-04 11:43, Eric Covener wrote:
> I'd be surprised if it helped someone who felt overwhelmed by the
> existence of 5 branches in SVN (no offense intended).
I agree to disagree. Graham's long explanation which still doesn't cover
certain scenarios is for sure a reason why not more people contribute to
the project.
Let's say I have a patch for the current version of Apache: 2.4.29. What
now? I have to get it first into 2.5.0 or trunk, which might not even be
compatible? So I have to figure out how the code in trunk works? Then I
have to do what? Learn SVN and how to use the STATUS file? I can't even
commit to a branch (let alone the fact that feature banches do not
exist) without a userid on svn.apache.org.
All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a
new feature or patch branch) and send a PR. (X reviewers are required,
and boom it gets merged. Don't forget all the nice CI that can be
triggered before or after the merge.)
While I still learned how to use CVS and SVN (which I also used in
personal projects and hated btw), used other ones like clearcase for
huge projects (like IBM DB2), the new generation of developers did not
and - believe me - they don't want to. (I definitely wouldn't want to,
if I had ever be involved in a project that used git.)
A move to git doesn't mean that this project will gain hundreds of new
developers over night, but it might give you a chance to streamline the
current development *and* release process. The rest will follow.
--
regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D
Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
Re: We have soon 5 SVN repo's
Posted by Eric Covener <co...@gmail.com>.
> Why don‘t move to git?
It has been discussed a few times, net not much interest from current
contributors.
Very little activity on the mirror.
I'd be surprised if it helped someone who felt overwhelmed by the
existence of 5 branches in SVN (no offense intended).
Re: We have soon 5 SVN repo's
Posted by Stefan Priebe - Profihost AG <s....@profihost.ag>.
> Am 04.11.2017 um 11:03 schrieb Steffen <in...@apachelounge.com>:
>
> 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.
>
Why don‘t move to git?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
>
>
>
Re: We have soon 5 SVN repo's
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 4, 2017, at 6:03 AM, Steffen <in...@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.
IMO, the ones w/ the LEAST clarity are the ones related to
2.5.0-alpha.
What, exactly, are the expected differences between trunk and 2.5.0-alpha?
I think it would make sense for those who are driving and championing
these events to have some formal, written roadmap available to avoid
confusion and the inevitable arguments/discussions that lack-of-clarity
incurs.