Re: We have soon 5 SVN repo's

2017-11-07 Thread Daniel Ruggeri
On 11/7/2017 8:30 AM, William A Rowe Jr wrote:
> If you are thinking of n.n.n-alphan format, how is that going to be mapped
> within ap_release.h? Version numbers are cheap, so cycling n.n.n-alpha
> to n.n.n+1-alpha hasn't proven to be an issue.

+1

Will do that. In context of conversation alpha1, alpha2, etc just meant
x.y.z+1-alpha since it was much easier to type that than all the dots on
my tiny little on-screen mobile keyboard 

-- Daniel Ruggeri



Re: We have soon 5 SVN repo's

2017-11-07 Thread William A Rowe Jr
On Tue, Nov 7, 2017 at 6:35 AM, Daniel Ruggeri  wrote:
> This is open for discussion. My opinion: For Alpha, I think it makes sense
> to tag from trunk rather than branching first. That is, delay the branching
> as long as possible so 2.6 looks as close to trunk for as long as possible.
> This keeps the APIs in sync as well as avoids unnecessary process to
> backport changes to Alpha. That is not a hard and fast rule, of course. If
> we want to begin work on a major overhaul we'd consider too disruptive, then
> we should branch.

+1... in theory we eventually approve a beta, at that point we probably want
to branch for stability. But thinking more broadly, big changes should first
be presented to dev@... so do we consider branching trunk to demonstrate
some substantial API change, and simply merge it back when accepted?
That would be a way to preserve dev's ability to propose future api changes
before trunk becomes 2.7.0-dev.

If you are thinking of n.n.n-alphan format, how is that going to be mapped
within ap_release.h? Version numbers are cheap, so cycling n.n.n-alpha
to n.n.n+1-alpha hasn't proven to be an issue.


Re: We have soon 5 SVN repo's

2017-11-07 Thread Daniel Ruggeri
(sorry for top post)
This is open for discussion. My opinion: For Alpha, I think it makes sense to 
tag from trunk rather than branching first. That is, delay the branching as 
long as possible so 2.6 looks as close to trunk for as long as possible. This 
keeps the APIs in sync as well as avoids unnecessary process to backport 
changes to Alpha. That is not a hard and fast rule, of course. If we want to 
begin work on a major overhaul we'd consider too disruptive, then we should 
branch.

My plan was to tag only from trunk, which as you point out, makes no difference 
for that initial cut. If we decide later before Alpha2 that we should have 
branched, we could easily svn copy the tag directory to a branch directory 
before proceeding or branch from the post-tag commit where MMN for "next" is 
bumped.
-- 
Daniel Ruggeri


 Original Message 
From: Rainer Jung <rainer.j...@kippdata.de>
Sent: November 7, 2017 4:07:55 AM CST
To: dev@httpd.apache.org
Subject: Re: We have soon 5 SVN repo's

Hi Steffen,

Am 07.11.2017 um 10:10 schrieb Steffen:
> Jim wrote below:
> 
> /What, exactly, are the expected differences between trunk and 2.5.0-alpha?/
> I could not find the answer in this (long) thread ?

as far as I understand Daniel, he will tag current trunk as 2.5.0-alpha 
or more likely 2.5.0-alpha1 or similar.

So at the moment he tags it, there will be no difference between trunk 
and the tag. The tag will be a name for the state/contents of trunk at 
the time of tagging. trunk can move further along but the given tag will 
be frozen.

What is currently not clear is, whether Daniel tags dircetly from trunk, 
or first copies trunk to a new branch 2.5.0 and tags that one. It will 
not make an initial difference but the development procedure for the 
future will differ.

Typically branching will be done as late as possible to prevent the 
additional porting of patches through one more branch. On the other hand 
if the tags get closer to something releasable, branching is necessary 
to stabilize code, ie. being able to apply bigger changes somewhere 
(trunk) without breaking the soon to be released stuff.

Regards,

Rainer

> On Sunday 05/11/2017 at 14:31, Jim Jagielski wrote:
>>
>> On Nov 4, 2017, at 6:03 AM, Steffen <i...@apachelounge.com
>> <mailto:i...@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.


Re: We have soon 5 SVN repo's

2017-11-07 Thread Rainer Jung

Hi Steffen,

Am 07.11.2017 um 10:10 schrieb Steffen:

Jim wrote below:

/What, exactly, are the expected differences between trunk and 2.5.0-alpha?/
I could not find the answer in this (long) thread ?


as far as I understand Daniel, he will tag current trunk as 2.5.0-alpha 
or more likely 2.5.0-alpha1 or similar.


So at the moment he tags it, there will be no difference between trunk 
and the tag. The tag will be a name for the state/contents of trunk at 
the time of tagging. trunk can move further along but the given tag will 
be frozen.


What is currently not clear is, whether Daniel tags dircetly from trunk, 
or first copies trunk to a new branch 2.5.0 and tags that one. It will 
not make an initial difference but the development procedure for the 
future will differ.


Typically branching will be done as late as possible to prevent the 
additional porting of patches through one more branch. On the other hand 
if the tags get closer to something releasable, branching is necessary 
to stabilize code, ie. being able to apply bigger changes somewhere 
(trunk) without breaking the soon to be released stuff.


Regards,

Rainer


On Sunday 05/11/2017 at 14:31, Jim Jagielski wrote:


On Nov 4, 2017, at 6:03 AM, Steffen > 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.


Re: We have soon 5 SVN repo's

2017-11-07 Thread Steffen


Jim wrote below:

What, exactly, are the expected differences between trunk and 
2.5.0-alpha?



I could not find the answer in this (long) thread ?


Steffen




On Sunday 05/11/2017 at 14:31, Jim Jagielski  wrote:






On Nov 4, 2017, at 6:03 AM, Steffen  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.


Re: We have soon 5 SVN repo's

2017-11-07 Thread Rainer Jung
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

2017-11-06 Thread Stefan Eissing
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 :
> 
> 
> On 11/6/2017 12:44 PM, Jim Jagielski wrote:
>>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr  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

2017-11-06 Thread Daniel Ruggeri

On 11/6/2017 12:44 PM, Jim Jagielski wrote:
>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr  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

2017-11-06 Thread Jim Jagielski
Thx for the clarification.

> On Nov 6, 2017, at 2:34 PM, William A Rowe Jr  wrote:
> 
> On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski  > wrote:
>> 
>>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr  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

2017-11-06 Thread William A Rowe Jr
On Mon, Nov 6, 2017 at 12:44 PM, Jim Jagielski  wrote:
>
>> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr  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

2017-11-06 Thread Jim Jagielski

> On Nov 6, 2017, at 12:18 PM, William A Rowe Jr  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

2017-11-06 Thread William A Rowe Jr
On Sun, Nov 5, 2017 at 3:44 PM, Jim Jagielski  wrote:
>
>> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr  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

2017-11-06 Thread William A Rowe Jr
On Mon, Nov 6, 2017 at 5:48 AM, Jim Jagielski  wrote:
>
> On Nov 5, 2017, at 9:39 PM, William A Rowe Jr  wrote:
>
> On Nov 5, 2017 12:21, "Jim Jagielski"  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

(*) 

Re: We have soon 5 SVN repo's

2017-11-06 Thread Jim Jagielski

> On Nov 5, 2017, at 9:39 PM, William A Rowe Jr  wrote:
> 
> On Nov 5, 2017 12:21, "Jim Jagielski"  > 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

2017-11-05 Thread Ruediger Pluem


On 11/04/2017 12:51 PM, Steffen wrote:
> Thanks Graham, very helpful.
> 
> Question left is when/where is patches/2.4.x and patches/trunk used ?  Free 
> to use ? You do not mention them in the process.
> 
> Resume:
> 
> CTR: trunk
> RTC: branches/2.4.x
> RTC: 2.5.0-alpha

I don't see a 2.5.0-alpha branch, let alone RTC. 2.5.0-alpha releases will be 
directly cut from trunk until an API
freeze makes sense at which point of time we should branch.
Regarding the review topic: My impression is that trunk is reviewed in general 
but not thoroughly tested. The testing
should be improved by cutting the alpha releases which should make them easier 
to consume for a broader audience then
checking out stuff from svn trunk directly and compile it. It also sends the 
signal of some movement towards an API
freeze for a new major release.
There might be some parts of trunk which only received weak review, but I guess 
once testing intensifies and bugs pop
up this will be remedied by those working on resolving the bugs.
In the end I can also think that we rip out certain parts of trunk if we as a 
community get to the conclusion that the
code is not working and that nobody is willing to work on this. As long as it 
was not part of GA release I see no issue
with this. Ripping out does not mean that it gets to /dev/null. It can be put 
in a branch, it can get forked as a
separate module, whatever seem appropriate. What I want to avoid is that we get 
in a situation that says: That part of
the code is buggy, so we cannot do a GA with it, nobody is willing to work on 
it, but we cannot remove it. This
shouldn't happen.
Some remark on the backport new features to the stable branch vs. having the 
new features only in a new major release:
I personally like the backporting approach, because from my personal 
perspective as httpd user I cannot easily upgrade
to a new major release as I depend on 3rd party closed source modules that do 
not quickly adopt support for new major
release. So with the current way I get new stuff much faster. But I admit the 
following two things:

1. I think we had too much regressions lately. So I think we need to improve 
our QA process here to reduce this.
2. Having the new features in the stable branch seems to lower the appetite for 
a new major release which does
   not seem to be good in the long run. OTOH we there might have been just too 
few people that are keen on the new
   release and were working towards this. Looks like this is changing.

> ? : patches/2.4.x
> ? : patches/trunk

These are not branches. Just convenience locations to store your patches. For 
backports the preferred way is to do them
via svn merge, but sometimes this does not work due to differences between 
trunk and the stable branch. In this case you
need to prepare a merge patch manually and propose it. So far people used 
different locations e.g. home.apache.org to
store these patches and have them available for review for their fellows.

Regards

Rüdiger


Re: We have soon 5 SVN repo's

2017-11-05 Thread William A Rowe Jr
On Nov 5, 2017 11:49, "William A Rowe Jr"  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

2017-11-05 Thread William A Rowe Jr
On Nov 5, 2017 12:21, "Jim Jagielski"  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

2017-11-05 Thread Helmut K. C. Tessarek
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

2017-11-05 Thread Jim Jagielski

> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr  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

2017-11-05 Thread Jim Jagielski

> On Nov 4, 2017, at 11:44 PM, William A Rowe Jr  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

2017-11-05 Thread William A Rowe Jr
On Nov 5, 2017 10:47, "Eric Covener"  wrote:

On Sun, Nov 5, 2017 at 12:53 AM, William A Rowe Jr 
wrote:
> On Nov 4, 2017 23:18, "Jacob Champion"  wrote:
>
> On Nov 4, 2017 8:44 PM, "William A Rowe Jr"  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

2017-11-05 Thread Eric Covener
On Sun, Nov 5, 2017 at 12:53 AM, William A Rowe Jr  wrote:
> On Nov 4, 2017 23:18, "Jacob Champion"  wrote:
>
> On Nov 4, 2017 8:44 PM, "William A Rowe Jr"  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
cove...@gmail.com


Re: We have soon 5 SVN repo's

2017-11-05 Thread Jim Jagielski

> On Nov 4, 2017, at 6:43 PM, Helmut K. C. Tessarek  
> 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

2017-11-05 Thread Jim Jagielski

> On Nov 4, 2017, at 6:03 AM, Steffen  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.

Re: We have soon 5 SVN repo's

2017-11-05 Thread Graham Leggett
On 05 Nov 2017, at 4:01 AM, Helmut K. C. Tessarek  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
—



smime.p7s
Description: S/MIME cryptographic signature


Re: We have soon 5 SVN repo's

2017-11-04 Thread William A Rowe Jr
On Nov 4, 2017 23:18, "Jacob Champion"  wrote:

On Nov 4, 2017 8:44 PM, "William A Rowe Jr"  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

2017-11-04 Thread Jacob Champion
On Nov 4, 2017 8:44 PM, "William A Rowe Jr"  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

2017-11-04 Thread William A Rowe Jr
On Sat, Nov 4, 2017 at 10:48 AM, Eric Covener  wrote:
> On Sat, Nov 4, 2017 at 9:28 AM, Marion & Christophe JAILLET
>  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 

Re: We have soon 5 SVN repo's

2017-11-04 Thread Helmut K. C. Tessarek
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

2017-11-04 Thread Yann Ylavic
On Sat, Nov 4, 2017 at 11:43 PM, Helmut K. C. Tessarek
 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

2017-11-04 Thread Graham Leggett
On 05 Nov 2017, at 12:43 AM, Helmut K. C. Tessarek  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
—



smime.p7s
Description: S/MIME cryptographic signature


Re: We have soon 5 SVN repo's

2017-11-04 Thread Luca Toscano
Hi,

2017-11-04 23:43 GMT+01:00 Helmut K. C. Tessarek :

> 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

2017-11-04 Thread Helmut K. C. Tessarek
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

2017-11-04 Thread Yann Ylavic
On Sat, Nov 4, 2017 at 11:15 PM, Yann Ylavic  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

2017-11-04 Thread Graham Leggett
On 04 Nov 2017, at 10:49 PM, Helmut K. C. Tessarek  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
—



smime.p7s
Description: S/MIME cryptographic signature


Re: We have soon 5 SVN repo's

2017-11-04 Thread Yann Ylavic
On Sat, Nov 4, 2017 at 10:39 PM, Eric Covener  wrote:
> On Sat, Nov 4, 2017 at 4:49 PM, Helmut K. C. Tessarek
>  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

2017-11-04 Thread Eric Covener
On Sat, Nov 4, 2017 at 4:49 PM, Helmut K. C. Tessarek
 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

2017-11-04 Thread Helmut K. C. Tessarek
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

2017-11-04 Thread William A Rowe Jr
On Nov 4, 2017 05:04, "Steffen"  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

2017-11-04 Thread Eric Covener
On Sat, Nov 4, 2017 at 9:28 AM, Marion & Christophe JAILLET
 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

2017-11-04 Thread Eric Covener
> 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

2017-11-04 Thread Eric Covener
On Sat, Nov 4, 2017 at 7:51 AM, Steffen  wrote:
> Thanks Graham, very helpful.
>
> Question left is when/where is patches/2.4.x and patches/trunk used ?  Free
> to use ? You do not mention them in the process.
>
> Resume:
>
> CTR: trunk
> RTC: branches/2.4.x
> RTC: 2.5.0-alpha
> ? : patches/2.4.x
> ? : patches/trunk
>
> The RTC is not always followed. I see mostly that  for example config,
> cmake  and  .dsp changes are not RTC, they are just applied to all the
> repo's

The 2.4.x STATUS file summarizes what kinds of changes do not require RTC.

The patches/ branches are just a standardized place to put patches
before they can be applied. It's pretty rarely used.


Re: We have soon 5 SVN repo's

2017-11-04 Thread Marion & Christophe JAILLET

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 > 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

2017-11-04 Thread Steffen


Thanks Graham, very helpful.

Question left is when/where is patches/2.4.x and patches/trunk used ?  
Free to use ? You do not mention them in the process.


Resume:

CTR: trunk

RTC: branches/2.4.x
RTC: 2.5.0-alpha
? : patches/2.4.x
? : patches/trunk

The RTC is not always followed. I see mostly that  for example config, 
cmake  and  .dsp changes are not RTC, they are just applied to all 
the repo's


Regards,
Steffen


On Saturday 04/11/2017 at 11:59, Graham Leggett  wrote:


On 04 Nov 2017, at 12:03 PM, Steffen  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

2017-11-04 Thread Graham Leggett
On 04 Nov 2017, at 12:03 PM, Steffen  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
—



smime.p7s
Description: S/MIME cryptographic signature


Re: We have soon 5 SVN repo's

2017-11-04 Thread Stefan Priebe - Profihost AG


> Am 04.11.2017 um 11:03 schrieb Steffen :
> 
> 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.


> 
> 
>