Re: http2 backports need one vote

Thanks, Yann! Merged into 2.4.x as r1910699. > Am 29.06.2023 um 10:30 schrieb Stefan Eissing via dev : > > The cumulative mod_http2 backport proposal via PR > https://github.com/apache/httpd/pull/364 needs one more vote. > > I appreciate if someone could add his vote to this. > > Kind

http2 backports need one vote

The cumulative mod_http2 backport proposal via PR https://github.com/apache/httpd/pull/364 needs one more vote. I appreciate if someone could add his vote to this. Kind Regards, Stefan

Re: backports

On 3/8/22 4:15 PM, Stefan Eissing wrote: > > >> Am 08.03.2022 um 14:34 schrieb Jim Jagielski : >> >>> On Mar 8, 2022, at 7:58 AM, Graham Leggett wrote: >>> >>> >>> I would far rather the empty APLOGNO check was part of the build. >>> >>> Vastly simpler. >>> >> >> I agree w/ that... > > I

Re: backports

On 3/9/22 1:11 PM, Yann Ylavic wrote: > On Tue, Mar 8, 2022 at 2:34 PM Jim Jagielski wrote: >> >>> On Mar 8, 2022, at 7:58 AM, Graham Leggett wrote: >>> >>> I would far rather the empty APLOGNO check was part of the build. >>> >>> Vastly simpler. >> >> >> I agree w/ that... > > I for one

Re: backports

> Am 09.03.2022 um 13:11 schrieb Yann Ylavic : > > On Tue, Mar 8, 2022 at 2:34 PM Jim Jagielski wrote: >> >>> On Mar 8, 2022, at 7:58 AM, Graham Leggett wrote: >>> >>> I would far rather the empty APLOGNO check was part of the build. >>> >>> Vastly simpler. >> >> >> I agree w/ that... >

Re: backports

On Tue, Mar 8, 2022 at 2:34 PM Jim Jagielski wrote: > >> On Mar 8, 2022, at 7:58 AM, Graham Leggett wrote: >> >> I would far rather the empty APLOGNO check was part of the build. >> >> Vastly simpler. > > > I agree w/ that... I for one prefer post processing of APLOGNO()s, if `make` started to

Re: backports

On Tue, Mar 8, 2022 at 1:59 PM Graham Leggett wrote: > > Using Github/Travis should inform us on the status of a proposal. Good, so having it run on every branch is fine by you right? > > Github/Travis should definitely not be invited onto our PMC and given a veto > vo

Re: backports

> I have the feeling that the work that has went into making our > tests run on travis is not sufficiently honoured in this discussion. > > Looking back on the last 6 years I participated here, the situation > now is *vastly* improved to what we had before. For me, the Travis CI > status is now

Re: backports

> Am 08.03.2022 um 14:34 schrieb Jim Jagielski : > >> On Mar 8, 2022, at 7:58 AM, Graham Leggett wrote: >> >> >> I would far rather the empty APLOGNO check was part of the build. >> >> Vastly simpler. >> > > I agree w/ that... I have the feeling that the work that has went into making

Re: backports

> On Mar 8, 2022, at 7:58 AM, Graham Leggett wrote: > > > I would far rather the empty APLOGNO check was part of the build. > > Vastly simpler. > I agree w/ that...

Re: backports

uddenly break), sometimes network outages, in other cases there is an inability to compile with no obvious reason. Using Github/Travis should inform us on the status of a proposal. Github/Travis should definitely not be invited onto our PMC and given a veto vote on backports and releases. I spend a l

Re: backports

On 3/7/22 12:23 PM, Joe Orton wrote: > > AIUI you can configure github to allow merges even if tests fail, though > I'm not familiar with that, has anybody played with the settings there? > Haven't played with them, but the below looks like a good starting point:

Re: backports

On Sun, Mar 06, 2022 at 05:56:36PM +0200, Graham Leggett wrote: > I am however strongly opposed for Github to be our only promotion process. > > CI is great right until the point you get your first unrelated test failure, > then it is a nightmare. The collectd project was completely stuck unable

Re: backports

On Mon, Mar 07, 2022 at 01:28:19PM +0200, Graham Leggett wrote: > On 07 Mar 2022, at 11:21, Stefan Eissing wrote: > > > I'd really like, as a reviewer of backports, you can: > > - see that it passes all our tests. No need to patch/compile/test locally. > > “No need

Re: backports

On Fri, Mar 04, 2022 at 09:40:49AM -0800, Roy T. Fielding wrote: > > On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: > > > > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: > >> > >> A question: Would it be easier for all this if we moved to being Github > >> canon? > > > > I think it is

Re: backports

> On Mar 7, 2022, at 6:28 AM, Graham Leggett wrote: > > On 07 Mar 2022, at 11:21, Stefan Eissing <mailto:ste...@eissing.org>> wrote: > >> I'd really like, as a reviewer of backports, you can: >> - see that it passes all our tests. No need to patch/compile/tes

Re: backports

On 07 Mar 2022, at 11:21, Stefan Eissing wrote: > I'd really like, as a reviewer of backports, you can: > - see that it passes all our tests. No need to patch/compile/test locally. “No need to patch/compile locally" is not a good idea - currently the travis tests target

Re: backports

gt;> anywhere on it. >>> >>> I think we are far beyond that point where staying with svn/bugzilla is >>> actively >>> hurting the project for little or no benefit. >>> >>> I'd +1 a switch just to get real issue management and PRs. >>

Re: backports

ve a github account could not participate in the new workflow though, at least for code contributions, not that I have a particular concern with github today but I wouldn't want to depend on my acceptance of their terms of service (or evolution thereof) for my contributions to httpd. But it will always b

Re: backports

> > To sum up: > > +1 on the option to use Github PRs for backports. > -1 to mandating the use of Github PRs for backports. > For backports specifically: Is a middle ground to not have GH block merging based on CI checks? This way PRs could be required, so revieers (the same

Re: backports

To sum up: +1 on the option to use Github PRs for backports. -1 to mandating the use of Github PRs for backports. Regards, Graham —

Re: backports

On Sat, Mar 5, 2022, 11:47 AM Jim Jagielski wrote: > > That's where I was heading with this, so I'm an obvious +1 to switching to > making > a Github-based workflow "official" for the PMC. +1 --Jacob

Re: backports

> On Mar 4, 2022, at 12:40 PM, Roy T. Fielding wrote: > >> On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: >> >> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: >>> >>> A question: Would it be easier for all this if we moved to being Github >>> canon? >> >> I think it is much more

Re: backports

On Fri, Mar 04, 2022 at 09:40:49AM -0800, Roy T. Fielding wrote: > > On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: > > > > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: > >> > >> A question: Would it be easier for all this if we moved to being Github > >> canon? > > > > I think it is

Re: backports

> Am 04.03.2022 um 18:40 schrieb Roy T. Fielding : > >> On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: >> >> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: >>> >>> A question: Would it be easier for all this if we moved to being Github >>> canon? >> >> I think it is much more

Re: backports

> On Mar 4, 2022, at 6:17 AM, Eric Covener wrote: > > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: >> >> A question: Would it be easier for all this if we moved to being Github >> canon? > > I think it is much more straightforward. The original work, reviews > and travis results are

Re: backports

On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski wrote: > > A question: Would it be easier for all this if we moved to being Github canon? I think it is much more straightforward. The original work, reviews and travis results are all in the same place and nothing is copied around. I have had the

Re: backports

A question: Would it be easier for all this if we moved to being Github canon? > On Mar 4, 2022, at 5:08 AM, Stefan Eissing wrote: > > We should improve our backport procedure and provide guidance on how to use > it after the next release. > > Post-mortem dbm backport: > - the patch pointed

backports

We should improve our backport procedure and provide guidance on how to use it after the next release. Post-mortem dbm backport: - the patch pointed to the in 2.4.x/STATUS was incomplete, lacking APLOGNO() - the incomplete patch was voted on and accepted, as local tests do not have the full CI

Re: can we haz backports?

On Wed, Jan 17, 2018 at 4:18 AM, Stefan Eissing wrote: > >> Am 17.01.2018 um 10:45 schrieb Yann Ylavic : >> >> On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing >> wrote: >>> Am 16.01.2018 um 21:26 schrieb

Re: can we haz backports?

> Am 17.01.2018 um 10:45 schrieb Yann Ylavic : > > On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing > wrote: >> >>> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr : >>> >>> Color me very confused, but I can't

Re: can we haz backports?

On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing wrote: > >> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr : >> >> Color me very confused, but I can't distinguish a difference between vhost >> based >> Host: header selection in the "http-01"

Re: can we haz backports?

> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr : > > Color me very confused, but I can't distinguish a difference between vhost > based > Host: header selection in the "http-01" case, and SNI identification > in the case of > "tls-sni-01". Am I missing something?

Re: can we haz backports?

Color me very confused, but I can't distinguish a difference between vhost based Host: header selection in the "http-01" case, and SNI identification in the case of "tls-sni-01". Am I missing something? Discussion pointers? For protocol reasons, "dns-01" seems outside the scope of any mod_md

Re: can we haz backports?

. 2018 om 12:14 heeft Stefan Eissing <stefan.eiss...@greenbytes.de > <mailto:stefan.eiss...@greenbytes.de>> het volgende geschreven: > >> Team, >> >> the frequency that people keep on asking me when ACME >> support in Apache will be released is g

Re: can we haz backports?

I try a high level, short summary of the current ACME "TLS-SNI" issue: 1. There are 3 basic ways to verify domain ownership: a) "http-01" on port 80 requests /.well-known/acme-challenge/ response: signed token as base64url b) "tls-sni-01" on port 443 client hello with SNI for

Re: can we haz backports?

On 01/12/2018 01:50 PM, Eric Covener wrote: > On Fri, Jan 12, 2018 at 7:38 AM, Steffen wrote: >> Yann: it is not working (anymore) when you have only port 443 open. >> Yann: I am/was testing in real live, no boulder. >> Eric: proposed change: to begin with warns/errors

Re: can we haz backports?

> Generally, we don't use -1 for something like that. Although not all > -1's are actually "vetoes" -- it is still reserved for something > actively detrimental. Whoops, they are actuallt vetoes for code or backports.

Re: can we haz backports?

On Fri, Jan 12, 2018 at 7:38 AM, Steffen wrote: > Yann: it is not working (anymore) when you have only port 443 open. > Yann: I am/was testing in real live, no boulder. > Eric: proposed change: to begin with warns/errors user > > I am talking about SSL configurations

Re: can we haz backports?

Re: can we haz backports?

On Fri, Jan 12, 2018 at 12:32 PM, Steffen wrote: > > Propose to change mod_md regarding above, now I vote -1. Could you please elaborate on what isn't working for Windows/you? Is it a general failure for Windows users or something that can be addressed as follow up? I

Re: can we haz backports?

On Fri, Jan 12, 2018 at 6:14 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > Team, > > the frequency that people keep on asking me when ACME > support in Apache will be released is going up. For > this to happen, two backports need 1(!) more vote: > > 1. cor

Re: can we haz backports?

On Fri, Jan 12, 2018 at 6:32 AM, Steffen wrote: > Now mod_md contains features which are not supported anymore ! > > For SSL only config mod_md is not usable anymore, see >

Re: can we haz backports?

> Am 12.01.2018 um 13:07 schrieb Yann Ylavic : > > On Fri, Jan 12, 2018 at 12:14 PM, Stefan Eissing > wrote: >> >> Is anyone planning to review this in the next days? > > I plan to do so, is there a strong need to own a domain for tesing or

Re: can we haz backports?

On Fri, Jan 12, 2018 at 12:14 PM, Stefan Eissing wrote: > > Is anyone planning to review this in the next days? I plan to do so, is there a strong need to own a domain for tesing or can I use a "standalone" thingy (if that's ever relevant)?

Re: can we haz backports?

On Fri, Jan 12, 2018 at 12:32 PM, Steffen wrote: > Now mod_md contains features which are not supported anymore ! > > For SSL only config mod_md is not usable anymore, see >

Re: can we haz backports?

es.de> > het volgende geschreven: > >> Team, >> >> the frequency that people keep on asking me when ACME >> support in Apache will be released is going up. For >> this to happen, two backports need 1(!) more vote: >> >> 1. core/mod_ssl: Add new flag

Re: can we haz backports?

CME > support in Apache will be released is going up. For > this to happen, two backports need 1(!) more vote: > > 1. core/mod_ssl: Add new flag int to module struct. > existing votes: icing, ylavic > 2. mod_md: backport of ACME (Let's Encrypt) support. > existing votes:

can we haz backports?

Team, the frequency that people keep on asking me when ACME support in Apache will be released is going up. For this to happen, two backports need 1(!) more vote: 1. core/mod_ssl: Add new flag int to module struct. existing votes: icing, ylavic 2. mod_md: backport of ACME (Let's Encrypt

Re: mod_md backports and happy turkey day

et.com>: > > FWIW, I'd like to see us maybe do a nice solid 2.4.30 around > the end of the year which includes mod_md and some other > useful backports.

Re: mod_md backports and happy turkey day

FWIW, I'd like to see us maybe do a nice solid 2.4.30 around the end of the year which includes mod_md and some other useful backports.

Re: mod_md backports and happy turkey day

Re: mod_md backports and happy turkey day

I do not understand what "reported as error" means. I speculate 1. you do not want to see the INFO log on '-t' 2a. you do not want to see WARNINGS, when mod_md finds something to warn about in the config? 2b. you mean that your configuration is fine, and there should be no WARN messages at all?

Re: mod_md backports and happy turkey day

Re: mod_md backports and happy turkey day

FYI: I just updated the mod_md backport proposal. For this, we will work together in a new branch: "2.4.x-mod_md". This will allow us to make all needed changes for the Windows Build system together and, once we are satisfied and have the votes, merge the branch over to 2.4.x. After that, the

Re: mod_md backports and happy turkey day

> Am 24.11.2017 um 21:06 schrieb Ruediger Pluem : > > > > On 11/24/2017 07:22 PM, Steffen wrote: >> -1 >> > >> >> >> *mod_ssl* >> --- >> mod-ssl, as pointed before is going to contain experimental code. Seen so >> far only patched mod-ssl tested with mod_md.

Re: mod_md backports and happy turkey day

On 11/24/2017 07:22 PM, Steffen wrote: > -1 > > > > *mod_ssl* > --- > mod-ssl, as pointed before is going to contain experimental code. Seen so far > only patched mod-ssl tested with mod_md. > If mod_md is not loaded mod_ssl does nothing different except for one log message. All

Re: mod_md backports and happy turkey day

son ? Was building fine on Windows. Quick look windows --- See _tryserf in Buildbin.dsp Miss mak files and others Reminder: last week off-list to Stefan: Baseaddr.ref never backports as is without conflict BuildBin.dsp however will never patch because of _tryserf in trunk.

mod_md backports and happy turkey day

Happy Turkey everyone! Just added backport proposals and patches for mod_md to 2.4.x/STATUS. The mod_ssl patch proposed is the minimal one, without policy or other niceties. I hope I did get all Windows related changes, people might want to check this. Also, I think I just got the basics from

Re: .gdbinit changes backports. CTR or RTC?

On 10/05/2017 05:07 PM, Yann Ylavic wrote: > On Thu, Oct 5, 2017 at 2:28 PM, Eric Covener wrote: >> On Thu, Oct 5, 2017 at 8:08 AM, Plüm, Rüdiger, Vodafone Group >> wrote: >>> Is backporting .gdbinit changes to a stable branch CTR or RTC? >> >> I

Re: .gdbinit changes backports. CTR or RTC?

On Thu, Oct 5, 2017 at 7:28 AM, Eric Covener wrote: > On Thu, Oct 5, 2017 at 8:08 AM, Plüm, Rüdiger, Vodafone Group > wrote: > > Is backporting .gdbinit changes to a stable branch CTR or RTC? > > I would think CTR for a typical change there is

Re: .gdbinit changes backports. CTR or RTC?

On Thu, Oct 5, 2017 at 2:28 PM, Eric Covener wrote: > On Thu, Oct 5, 2017 at 8:08 AM, Plüm, Rüdiger, Vodafone Group > wrote: >> Is backporting .gdbinit changes to a stable branch CTR or RTC? > > I would think CTR for a typical change there is

Re: .gdbinit changes backports. CTR or RTC?

On Thu, Oct 5, 2017 at 8:08 AM, Plüm, Rüdiger, Vodafone Group wrote: > Is backporting .gdbinit changes to a stable branch CTR or RTC? I would think CTR for a typical change there is reasonable.

.gdbinit changes backports. CTR or RTC?

Is backporting .gdbinit changes to a stable branch CTR or RTC? Regards Rüdiger

Re: [DISCUSS] commit messages on backports

ove...@gmail.com> wrote: > > In a branch of a private discussion, some issues with how backports > are committed was raised. > > IMO, our use of STATUS kind of makes the current Reviewed By: a little > misleading in http://people.apache.org/~jorton/svn.merge > > * My olde

[DISCUSS] commit messages on backports

In a branch of a private discussion, some issues with how backports are committed was raised. IMO, our use of STATUS kind of makes the current Reviewed By: a little misleading in http://people.apache.org/~jorton/svn.merge * My older copy of the script doesn't have it at all, and I rarely edit

Re: APLOGNO in 2.2 backports

On Thu, Dec 22, 2016 at 9:33 AM, Eric Covener <cove...@gmail.com> wrote: > Should we have something like this in 2.2: > > #define APLOGNO(s) "" > > So subsequent backports don't need manual merging when the context has > a message ID in it? > IMO, no. Beca

APLOGNO in 2.2 backports

Should we have something like this in 2.2: #define APLOGNO(s) "" So subsequent backports don't need manual merging when the context has a message ID in it? -- Eric Covener cove...@gmail.com

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic ylavic@gmail.com wrote: *) mod_ssl: Improve handling of ephemeral DH and ECDH keys by allowing custom parameters to be configured via SSLCertificateFile, and by adding standardized DH parameters for 1024/2048/3072/4096 bits.

Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327) for backport to 2.2.x (in reverse order): *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer larger keys and support up to 8192-bit keys. [Ruediger Pluem, Joe Orton] *) mod_ssl: Improve handling of

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

Please note that the primes constants in modules/ssl/ssl_engine_dh.c are from openssl/crypto/bn/bn_const.c. FWIW, attached is a (stripped) diff between the two files that shows constants are the same... On Tue, May 5, 2015 at 7:12 PM, Yann Ylavic ylavic@gmail.com wrote: Possible backport

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

Possible backport patch attached. On Tue, May 5, 2015 at 3:14 PM, Yann Ylavic ylavic@gmail.com wrote: I'd like to propose those 2.4.x CHANGES (r1542327+r1569005+r1542327) for backport to 2.2.x (in reverse order): *) mod_ssl: Fix tmp DH parameter leak, adjust selection to prefer

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

On Tue, May 5, 2015 at 3:06 PM, Hanno Böck ha...@hboeck.de wrote: I haven't used apache 2.2, but isn't OCSP stapling support still missing there? I think if you're already working on backporting important TLS features that should certainly go with them. My own line for 2.2 would be drawn

Re: Possible mod_ssl's backports to 2.2.x? (was: Looking ahead to 2.4.13 / 2.2.30)

I haven't used apache 2.2, but isn't OCSP stapling support still missing there? I think if you're already working on backporting important TLS features that should certainly go with them. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpNXAgtjh1Er.pgp

RE: [VOTE] Lazy Consensus for 2.4.x backports

From: Jeff Trawick [Sent: Mittwoch, 10. Juli 2013 21:04 To: Apache HTTP Server Development List Subject: Re: [VOTE] Lazy Consensus for 2.4.x backports On Wed, Jul 10, 2013 at 2:03 PM, Jim Jagielski j...@jagunet.com wrote: Pulling this out as a proposal: I propose that we track all

[VOTE] Lazy Consensus for 2.4.x backports

Pulling this out as a proposal: I propose that we track all backports in 2.4 STATUS as we currently do. Each backport is time-tagged and we operate under a lazy consensus. Assuming no -1 votes within 96 hours, the backport can be applied to 2.4.x. If the backport gets 3 +1 votes sooner than

Re: [VOTE] Lazy Consensus for 2.4.x backports

On Wed, 10 Jul 2013 14:03:53 -0400 Jim Jagielski j...@jagunet.com wrote: Pulling this out as a proposal: I propose that we track all backports in 2.4 STATUS as we currently do. Each backport is time-tagged and we operate under a lazy consensus. Assuming no -1 votes within 96 hours

Re: [VOTE] Lazy Consensus for 2.4.x backports

On Wed, Jul 10, 2013 at 2:03 PM, Jim Jagielski j...@jagunet.com wrote: Pulling this out as a proposal: I propose that we track all backports in 2.4 STATUS as we currently do. Each backport is time-tagged and we operate under a lazy consensus. Assuming no -1 votes within 96 hours

Re: [VOTE] Lazy Consensus for 2.4.x backports

If I count right, 80% or more of the fixes potentially in 2.4.next are already there (I didn't count mod_lua.) That doesn't seem so bad. FWIW, I had a flurry of trivial fixes in trunk that I didn't want to derail/delay 2.4.5 with, which inflates the remaining 20% a bit.

Re: [VOTE] Lazy Consensus for 2.4.x backports

On Wed, Jul 10, 2013 at 3:09 PM, Eric Covener cove...@gmail.com wrote: If I count right, 80% or more of the fixes potentially in 2.4.next are already there (I didn't count mod_lua.) That doesn't seem so bad. FWIW, I had a flurry of trivial fixes in trunk that I didn't want to

[nudge] we should finish cleaning up the 2.0.x vulnerability backports soon

* Commit /dist/httpd/patches/apply_to_2.0.63/CVE-2008-2364-patch-2.0.txt: SECURITY: CVE-2008-2364 (cve.mitre.org) mod_proxy_http: Better handling of excessive interim responses from origin server to prevent potential denial of service and high memory usage. +1: trawick, wrowe

Backports from trunk to 2.2 proxy-balancers

, if that will be a impediment to actually *getting* these backports into 2.2, then I'm willing to keep the old structure... So my question is: if to be able to easily backport the various trunk proxy improvements into 2.2, we also need to backport the dir structure as well, is that OK? I don't want

Re: Backports from trunk to 2.2 proxy-balancers

as the config magic associated with it). However, if that will be a impediment to actually *getting* these backports into 2.2, then I'm willing to keep the old structure... So my question is: if to be able to easily backport the various trunk proxy improvements into 2.2, we also need to backport

Re: Backports from trunk to 2.2 proxy-balancers

that includes the balancer methods (as well as the config magic associated with it). However, if that will be a impediment to actually *getting* these backports into 2.2, then I'm willing to keep the old structure... So my question is: if to be able to easily backport the various trunk proxy

Re: Backports from trunk to 2.2 proxy-balancers

-Ursprüngliche Nachricht- Von: Rainer Jung Gesendet: Mittwoch, 6. Mai 2009 15:10 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers On 06.05.2009 14:39, Jim Jagielski wrote: It would certainly be easier to maintain a 2.2-proxy branch

Re: Backports from trunk to 2.2 proxy-balancers

Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Rainer Jung Gesendet: Mittwoch, 6. Mai 2009 15:10 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers On 06.05.2009 14:39, Jim Jagielski wrote: It would certainly be easier to maintain a 2.2

Re: Backports from trunk to 2.2 proxy-balancers

On May 6, 2009, at 9:54 AM, Plüm, Rüdiger, VF-Group wrote: The problem is that this breaks existing configurations for 2.2.x as the balancers are now in separate modules. How so (the breakage, that is)?? You mean they requirement for them to LoadModule them?

Re: Backports from trunk to 2.2 proxy-balancers

-Ursprüngliche Nachricht- Von: jean-frederic clere Gesendet: Mittwoch, 6. Mai 2009 16:40 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Rainer Jung Gesendet

Re: Backports from trunk to 2.2 proxy-balancers

-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 6. Mai 2009 16:59 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers On May 6, 2009, at 9:54 AM, Plüm, Rüdiger, VF-Group wrote: The problem is that this breaks existing

Re: Backports from trunk to 2.2 proxy-balancers

On May 6, 2009, at 11:04 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 6. Mai 2009 16:59 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers On May 6, 2009, at 9:54 AM, Plüm, Rüdiger, VF-Group

Re: Backports from trunk to 2.2 proxy-balancers

-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 6. Mai 2009 17:10 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers On May 6, 2009, at 11:04 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von

Re: Backports from trunk to 2.2 proxy-balancers

Just an update: Currently httpd-2.2-proxy contains the latest trunk proxy code and the new sub-module layout and passes all framework tests... I'll start, maybe after lunch, movement to sub-files, not sub-modules, for the balancers. On May 6, 2009, at 11:10 AM, Jim Jagielski wrote: In that

Re: Backports from trunk to 2.2 proxy-balancers

Jim Jagielski wrote: On May 6, 2009, at 11:04 AM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 6. Mai 2009 16:59 An: dev@httpd.apache.org Betreff: Re: Backports from trunk to 2.2 proxy-balancers On May 6, 2009, at 9:54 AM, Plüm

Re: Backports from trunk to 2.2 proxy-balancers

On May 6, 2009, at 11:15 AM, jean-frederic clere wrote: Jim Jagielski wrote: In that case, we could keep the trunk dir structure for any extra balancers we may add in the 2.2 tree and move the old balancer code back into mod_proxy_balancers.c (or, even better, as sep files that aren't

where do the APR(-UTIL) backports go?

Hi, just looked at the APR(-UTIL) 1.2.x STATUS file, but dont see there any backport proposals I've also few build system related (NetWare) backport proposals, where should I put them in? greets, Guenter.

Re: where do the APR(-UTIL) backports go?

Guenter Knauf wrote: Hi, just looked at the APR(-UTIL) 1.2.x STATUS file, but dont see there any backport proposals I've also few build system related (NetWare) backport proposals, where should I put them in? First, don't ask here, these folks wouldn't have your answer (har har)

Re: proxy balancer backports for 2.2.3

Turk wrote: Jim Jagielski wrote: Mladen Turk wrote: There are lots of things to backport. IMHO its the entire HEAD, and spread over the multiple svn commits. How we should deal with that? Having multiple backports or a single one? we should simply update STATUS as usually... most

Re: proxy balancer backports for 2.2.3

get your backports committed ASAP so folks on Wed night catch any troubles on branches/2.0.x or branches/2.2.x There are lots of things to backport. IMHO its the entire HEAD, and spread over the multiple svn commits. How we should deal with that? Having multiple backports or a single one

Re: proxy balancer backports for 2.2.3

On Wednesday 26 July 2006 11:02, Mladen Turk wrote: There are lots of things to backport. IMHO its the entire HEAD, and spread over the multiple svn commits. How we should deal with that? Having multiple backports or a single one? IMO if we try and deal with that for a security release

Re: proxy balancer backports for 2.2.3

Nick Kew wrote: On Wednesday 26 July 2006 11:02, Mladen Turk wrote: There are lots of things to backport. IMHO its the entire HEAD, and spread over the multiple svn commits. How we should deal with that? Having multiple backports or a single one? IMO if we try and deal

  1   2   >