Re: backports

[Ruediger Pluem]

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 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 *the* objective status of healthiness of our branches.
> Not because I am a Travis fanboy, but because we had nothing in the
> project before that was available to every team member.
> 
> Speaking as RM, I will *never* make a release on a branch that is
> not "green". That would be unprofessional. As it is not the task
> of an RM to make it green, it already needs to be that way.
> 
> As a developer, I very much prefer to commit to a "green" branch and
> see that it stays green with my changes. On a red branch, this becomes
> harder to analyse. The recent example of the async handshake showed
> that it become more and more difficult to isolate the breaking 
> changes and progress for everyone was hindered by this.
> 
> Now, that does not mean Travis CI is the end of all efforts. But
> it is a good start and it is worth expanding on, IMO.
> 
> Also we need to realise that aligning our way of working more to
> what is now common practise in the field actually *lowers* the 
> barriers for participation.
> 

+1 to this. While I agree that the ultimate decision on merging or not should 
be with us and that
there should be no blocking from Github in the end, I can only imagine very 
rare conditions where
merging a PR that fails the checks makes sense. Mainly in case of time pressure 
due to a security release
and the failure is known to be unrelated.
Otherwise I would strongly encourage to either fix the test that fails or the 
code that causes this test to fail.
Since we use the CI on every commit much effort was done to clean our test 
suite such that we no longer
have these "yeah I know it fails for ages for unknown reasons, but I don't 
care" tests any longer.

I understand and appreciate the concerns that we don't want to force people to 
create a Github account if they don't like.
>From my point of view this is exactly what gitbox is for when it comes to 
>committing. With regards to workflows though we could
still use the good old STATUS file for backport decisions, but I am not sure if 
most people would like to continue using it if
we would have a voting workflow on PR's (which we don't have yet, but which 
looks like to be doable).
I guess we should have an eye on whether we can somehow export all the data in 
addition to the code itself (issues, PR's, etc.)
from Github such that there would be a chance to retain that data in case 
Github pulls the plug.

With regards to the dependency on services like Github and Travis:
Well as far as I can see there is already a trend in infra to move to SaaS 
services, Ponymail, Jira and Confluence come to my
mind, that are already moved there or where there are plans for doing so. I 
guess we need to say a little bit goodbye to an all
"onprem" infrastructure purely created from open source where noone can change 
conditions such that we cannot use them any longer
or where we can quickly move to something else.
Hence if Github and / or Travis would switch to whatever unacceptable 
conditions short term this would have a huge impact on the
ASF and also already on this project. But we would still have access to the 
code via gitbox.

Regards

Rüdiger

Re: backports

[Ruediger Pluem]

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 prefer post processing of APLOGNO()s, if `make` started to
> fail because of that while coding (i.e. while adding/removing
> APLOGNO()s when "playing" with the code) it would be a pain IMO.
> So I prefer our ci failing occasionally because one[1] forgot a final
> `make update-log-tags` (the fix is easy and no one is really blocked
> by this in the meantime) rather than more work with APLOGNO()s while
> coding.

Big +1 to this.

Regards

Rüdiger

Re: backports

[Stefan Eissing]

> 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...
> 
> I for one prefer post processing of APLOGNO()s, if `make` started to
> fail because of that while coding (i.e. while adding/removing
> APLOGNO()s when "playing" with the code) it would be a pain IMO.

+1

> So I prefer our ci failing occasionally because one[1] forgot a final
> `make update-log-tags` (the fix is easy and no one is really blocked
> by this in the meantime) rather than more work with APLOGNO()s while
> coding.
> 
> Regards;
> Yann.
> 
> [1] well, mainly Stefan but he's doing (other) great things by the way :)

I try to compensate my APLOGNO() failures with other things. Thanks for 
noticing! ;)

Re: backports

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

I for one prefer post processing of APLOGNO()s, if `make` started to
fail because of that while coding (i.e. while adding/removing
APLOGNO()s when "playing" with the code) it would be a pain IMO.
So I prefer our ci failing occasionally because one[1] forgot a final
`make update-log-tags` (the fix is easy and no one is really blocked
by this in the meantime) rather than more work with APLOGNO()s while
coding.

Regards;
Yann.

[1] well, mainly Stefan but he's doing (other) great things by the way :)

Re: backports

[Yann Ylavic]

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 
> vote on backports and releases.

I don't think anyone proposed that merges (let alone releases) be
blocked by ci, this is a per-project setting in github AFAICT.
Now if the ci fails for whatever reason (bad code or bad test) and the
merge happens anyway, this will have to be fixed on the target branch
at one time or another. The point is that it shouldn't affect others
too much, if the PR uncovered a can of worms elsewhere I still think
that we'd better fix that too before merging (not on the PR's
contributor though), but here again the ci is of great help for
everyone.

So if committers can contribute by either pushing directly to git.a.o
(almost like before) or using github, and we don't let github dictate
our policies, and github also allows for more contributors (thus more
people to potentially become committers), what are your reserves
still?


Regards;
Yann.

Re: backports

[Eric Covener]

> 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 *the* objective status of healthiness of our branches.
> Not because I am a Travis fanboy, but because we had nothing in the
> project before that was available to every team member.
>
> Speaking as RM, I will *never* make a release on a branch that is
> not "green". That would be unprofessional. As it is not the task
> of an RM to make it green, it already needs to be that way.
>
> As a developer, I very much prefer to commit to a "green" branch and
> see that it stays green with my changes. On a red branch, this becomes
> harder to analyse. The recent example of the async handshake showed
> that it become more and more difficult to isolate the breaking
> changes and progress for everyone was hindered by this.
>
> Now, that does not mean Travis CI is the end of all efforts. But
> it is a good start and it is worth expanding on, IMO.
>
> Also we need to realise that aligning our way of working more to
> what is now common practise in the field actually *lowers* the
> barriers for participation.

+1

Re: backports

[Stefan Eissing]

> 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 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 *the* objective status of healthiness of our branches.
Not because I am a Travis fanboy, but because we had nothing in the
project before that was available to every team member.

Speaking as RM, I will *never* make a release on a branch that is
not "green". That would be unprofessional. As it is not the task
of an RM to make it green, it already needs to be that way.

As a developer, I very much prefer to commit to a "green" branch and
see that it stays green with my changes. On a red branch, this becomes
harder to analyse. The recent example of the async handshake showed
that it become more and more difficult to isolate the breaking 
changes and progress for everyone was hindered by this.

Now, that does not mean Travis CI is the end of all efforts. But
it is a good start and it is worth expanding on, IMO.

Also we need to realise that aligning our way of working more to
what is now common practise in the field actually *lowers* the 
barriers for participation.

Kind Regards,
Stefan

Re: backports

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

Re: backports

[Graham Leggett]

On 08 Mar 2022, at 10:29, Joe Orton  wrote:

>> “No need to patch/compile locally" is not a good idea - currently the 
>> travis tests target Ubuntu only, and this is a practical limitation 
>> forced upon us by the nature of the Travis service. I want to see 
>> reviewers try out the patch on different architectures. I for example 
>> work on MacOS, but deploy to Redhat, so those are my two environments. 
>> Others will have different environments.
>> 
>> Our testing needs to be wide and diverse.
> 
> Definitely +1 on the sentiment and I'm keen to help with any effort to 
> add more diversity to the CI.  Travis natively supports a bunch of 
> non-Linux platforms so if someone cares about that they should be able 
> to hook it up by tweaking the .travis.yml. 
> https://docs.travis-ci.com/user/reference/overview/ 
> 

Please don’t underestimate just how much ongoing work is involved first of all 
achieving the diversity of platforms, and then keeping them working on an 
ongoing basis.

I have spent a very long time getting code to work on COPR, which targets 
Fedora/Redhat derivatives. The COPR service is excellent, but I have yet to get 
any non trivial piece of code to build on all targets. Apart from the arbitrary 
differences between platforms, there is regular instability. In some cases 
there is platform breakage (dependencies suddenly 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 lot of time fixing bugs in open source projects, the pattern is I 
find something broken, I dive in, rip it to bits, fix the error handling, then 
fix the problem, and then submit upstream, then to distros. In some cases I 
have been waiting years for bugfixes to be picked up by projects, and it’s 
often because their CI is broken and so nobody will give the PR a second glance 
without significant prodding. In the collectd case the whole project was locked 
out.

Having one less place where “broken computer says no” would make our project 
far more welcoming.

> (I'll note the empty APLOGNO() check in question here was added because 
> some Windows build broke for that case and it blocked a release, IIRC.)

I would far rather the empty APLOGNO check was part of the build.

Vastly simpler.

Regards,
Graham
—

Re: backports

[Ruediger Pluem]

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:

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests

Regards

Rüdiger

Re: backports

[Joe Orton]

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 to 
> merge a single PR for months and months because their CI broke and nobody had 
> access to fix it. Github presented a “computer says no” button and the 
> project ground to a complete halt. The project is now so backlogged that the 
> chances of getting anything reviewed are slim.
> 
> https://www.mail-archive.com/search?l=colle...@verplant.org=subject:%22Re%5C%3A+%5C%5Bcollectd%5C%5D+SNMPv3%5C%2BDTLS+support+for+collectd%5C-snmp%22=newest=1
> 
> It is inevitable that at some point the generosity of the people 
> supplying the CI will run out, and CI will stop working. We cannot 
> allow ourselves to be jammed up because of this.

I assume the ASF infra budget is still paying for Travis capacity since 
there is no free service there any more (beyond an initial N thousand 
hours per account), and they were in the past:

https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci

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?

Regards, Joe

Re: backports

[Joe Orton]

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 to patch/compile locally" is not a good idea - currently the 
> travis tests target Ubuntu only, and this is a practical limitation 
> forced upon us by the nature of the Travis service. I want to see 
> reviewers try out the patch on different architectures. I for example 
> work on MacOS, but deploy to Redhat, so those are my two environments. 
> Others will have different environments.
> 
> Our testing needs to be wide and diverse.

Definitely +1 on the sentiment and I'm keen to help with any effort to 
add more diversity to the CI.  Travis natively supports a bunch of 
non-Linux platforms so if someone cares about that they should be able 
to hook it up by tweaking the .travis.yml. 
https://docs.travis-ci.com/user/reference/overview/

(I'll note the empty APLOGNO() check in question here was added because 
some Windows build broke for that case and it blocked a release, IIRC.)

> This way we learn far more than what Github will give to us. Has my 
> patch been broken by another backport ahead of it and is now stale? 
> Very useful to know. It would be nice to be told “your patch is stale” 
> in CI rather than finding that out when the backport is applied.

You get this in Github PRs at least if mergeability test fails.

Regards, Joe

Re: backports

[Joe Orton]

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 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 same thought a few times this week. But I was hesitant
> > to reopen that thread/discussion because I'm pessimistic we can get
> > 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.

+1 for switching to Github.

Regards, Joe

Re: backports

[Jim Jagielski]

> On Mar 7, 2022, at 6:28 AM, 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 to patch/compile locally" is not a good idea - currently the travis 
> tests target Ubuntu only, and this is a practical limitation forced upon us 
> by the nature of the Travis service. I want to see reviewers try out the 
> patch on different architectures. I for example work on MacOS, but deploy to 
> Redhat, so those are my two environments. Others will have different 
> environments.
> 
> Our testing needs to be wide and diverse.

++1

Re: backports

[Graham Leggett]

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 Ubuntu only, and this is a practical limitation forced upon us by 
the nature of the Travis service. I want to see reviewers try out the patch on 
different architectures. I for example work on MacOS, but deploy to Redhat, so 
those are my two environments. Others will have different environments.

Our testing needs to be wide and diverse.

> - see the diff and comment/question on specific lines

We do that now.

I am very happy to be inclusive and allow the use of tools like Github, but I’d 
like the those comments for example gated into our mailing lists so that it is 
not required to use Github.

> - have exactly merged what you looked at

We do that now.

> This is a fair point. github has suspended accounts in the past
> based on criteria the ASF may not find agreeable. 

Going further, if we mandate Github as part of our workflow, we’re telling our 
contributors that they must accept the terms and conditions of an arbitrary 
commercial corporation that is in no way related to us, and has its own mission 
and values. It is not fair on our contributors to force this decision upon them.

> With the 2.4.* and trunk* patterns, we should run the Travis CIs for
> all matching branches. In STATUS, we link the branch/PR.

What I want[1] is to skip Github entirely and run CI off the STATUS file.

It would be far more useful to run each build as 2.4.x branch + proposed patch 
on every v2.4 change. That proposed patch can be a Github PR with no problem, 
but does not have to be.

This way we learn far more than what Github will give to us. Has my patch been 
broken by another backport ahead of it and is now stale? Very useful to know. 
It would be nice to be told “your patch is stale” in CI rather than finding 
that out when the backport is applied.

Right now (to my knowledge) Github runs CI on changes to the PR, not changes to 
the underlying branch.

[1] I am up to my eyeballs in bugs right now, so I recognise talk is cheap and 
I can’t make this happen right now. I do however run CI hardware that can be 
used for this, but will need time to make it happen.

Regards,
Graham
—

Re: backports

[Stefan Eissing]

> Am 07.03.2022 um 02:53 schrieb Yann Ylavic :
> 
> On Sat, Mar 5, 2022 at 12:17 PM Stefan Eissing  wrote:
>> 
>>> 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 straightforward.  The original work, reviews
 and travis results are all in the same place and nothing is copied
 around.
 I have had the same thought a few times this week. But I was hesitant
 to reopen that thread/discussion because I'm pessimistic we can get
 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.
>> 
>> +1
> 
> +1, agreed that it will simplify our "daily" and overall workflow.

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.
- see the diff and comment/question on specific lines
- have exactly merged what you looked at

> I wouldn't like that committers/PMC that don't have 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.

This is a fair point. github has suspended accounts in the past
based on criteria the ASF may not find agreeable. 

> But it will always be possible to commit and create branches directly
> in git.a.o anyway, thus propose backports in STATUS still for those
> who want (the ci would run on the backport branch though no github PR
> would be created in this case I think, thus voting would have to stay
> in STATUS and the merge be manual for such backport proposals), yet
> that looks legitimate to me.

With the 2.4.* and trunk* patterns, we should run the Travis CIs for
all matching branches. In STATUS, we link the branch/PR.

> 
> As for the comments/changes/edits/reviews in github I'm not sure that
> they all get forwarded to notifications@ or dev@ today, but that's
> good enough for me so far.
> 
> 
> Regards;
> Yann.

Re: backports

[Yann Ylavic]

On Sat, Mar 5, 2022 at 12:17 PM Stefan Eissing  wrote:
>
> > 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 straightforward.  The original work, reviews
> >> and travis results are all in the same place and nothing is copied
> >> around.
> >> I have had the same thought a few times this week. But I was hesitant
> >> to reopen that thread/discussion because I'm pessimistic we can get
> >> 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.
>
> +1

+1, agreed that it will simplify our "daily" and overall workflow.

I wouldn't like that committers/PMC that don't have 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 be possible to commit and create branches directly
in git.a.o anyway, thus propose backports in STATUS still for those
who want (the ci would run on the backport branch though no github PR
would be created in this case I think, thus voting would have to stay
in STATUS and the merge be manual for such backport proposals), yet
that looks legitimate to me.

As for the comments/changes/edits/reviews in github I'm not sure that
they all get forwarded to notifications@ or dev@ today, but that's
good enough for me so far.


Regards;
Yann.

Re: backports

[Eric Covener]

>
> 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
reviewers we have today in STATUS) can see test results.

Or is there something else objectionable about doing the work in a PR?

Re: backports

[Graham Leggett]

On 04 Mar 2022, at 12:08, 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 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 checks
> - Jim applied the voted on backport patch
> - CI failed
> No one did anything really wrong. We did just not apply the CI tools 
> available until the damage was done.

Just to confirm - no damage was done.

We have a thorough, multistep process that ensures damage is not done. We do 
the work first on trunk and our CI, then we propose it for backport on trunk 
and it is tested again by multiple people through their votes. Then it hits our 
stable branch and then it gets tested by even more people, and our CI. Then 
it’s tested again when we propose a release. If we slip through all that, only 
then is damage done.

> As noted in the related thread, backport proposal should really be PRs on 
> github. Those are checked by
> our CI and a PR can easily be improved by adding submits to the branch it is 
> based on. In addition, we
> get the github UI for review and comments. Should be a win for all.

Github PRs are easy to use, and it’s entirely reasonable to use github to 
handle a backport if you choose to do so.

Github PRs also have simple interfaces, like this one:

curl https://[url-of-pr].diff | patch -p1

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 to 
merge a single PR for months and months because their CI broke and nobody had 
access to fix it. Github presented a “computer says no” button and the project 
ground to a complete halt. The project is now so backlogged that the chances of 
getting anything reviewed are slim.

https://www.mail-archive.com/search?l=colle...@verplant.org=subject:%22Re%5C%3A+%5C%5Bcollectd%5C%5D+SNMPv3%5C%2BDTLS+support+for+collectd%5C-snmp%22=newest=1

It is inevitable that at some point the generosity of the people supplying the 
CI will run out, and CI will stop working. We cannot allow ourselves to be 
jammed up because of this.

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

[Jacob Champion]

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

[Jim Jagielski]

> 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 straightforward.  The original work, reviews
>> and travis results are all in the same place and nothing is copied
>> around.
>> I have had the same thought a few times this week. But I was hesitant
>> to reopen that thread/discussion because I'm pessimistic we can get
>> 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.
> 

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.

Re: backports

[Giovanni Bechis]

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 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 same thought a few times this week. But I was hesitant
> > to reopen that thread/discussion because I'm pessimistic we can get
> > 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.
> 
+1 to switch.
 Giovanni


signature.asc
Description: PGP signature

Re: backports

[Stefan Eissing]

> 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 straightforward.  The original work, reviews
>> and travis results are all in the same place and nothing is copied
>> around.
>> I have had the same thought a few times this week. But I was hesitant
>> to reopen that thread/discussion because I'm pessimistic we can get
>> 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.

+1

Re: backports

[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 straightforward.  The original work, reviews
> and travis results are all in the same place and nothing is copied
> around.
> I have had the same thought a few times this week. But I was hesitant
> to reopen that thread/discussion because I'm pessimistic we can get
> 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.

Roy

Re: backports

[Eric Covener]

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 same thought a few times this week. But I was hesitant
to reopen that thread/discussion because I'm pessimistic we can get
anywhere on it.

Re: backports

[Jim Jagielski]

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 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 checks
> - Jim applied the voted on backport patch
> - CI failed
> No one did anything really wrong. We did just not apply the CI tools 
> available until the damage was done.
> 
> As noted in the related thread, backport proposal should really be PRs on 
> github. Those are checked by
> our CI and a PR can easily be improved by adding submits to the branch it is 
> based on. In addition, we
> get the github UI for review and comments. Should be a win for all.
> 
> Kind Regards,
> Stefan
> 
> 

Re: Backports from trunk to 2.2 proxy-balancers

[Rainer Jung]

On 06.05.2009 14:39, Jim Jagielski wrote:
 It would certainly be easier to maintain a 2.2-proxy branch, with the
 intent of it actually being folded *into* 2.2, if the branch used the
 same dir structure as trunk, that is, a separate directory 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 improvements into 2.2, we also need to backport the dir
 structure as well, is that OK? I don't want to work down that
 path only to have it wasted work because people think that such a
 directory restructure doesn't make sense within a 2.2.x release.
 
 PS: NO, I am not considering this for 2.2.12! :)

I guess at the heart of this is the question, how likely we break some
part of the users build process for 2.2.x. My feeling is, that the
additional sub directory for the balancing method implementations is a
small change and users build process should not break due to this
additional one directory.

On the positive side apart from easier backports: the new subdirectory
might make people more curious on how to add a custom balancing method,
so we get a slightly better visibility for the existing provider interface.

Regards,

Rainer

Re: Backports from trunk to 2.2 proxy-balancers

[Jim Jagielski]

On May 6, 2009, at 9:09 AM, Rainer Jung wrote:


On 06.05.2009 14:39, Jim Jagielski wrote:

It would certainly be easier to maintain a 2.2-proxy branch, with the
intent of it actually being folded *into* 2.2, if the branch used the
same dir structure as trunk, that is, a separate directory 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 improvements into 2.2, we also need to backport the dir
structure as well, is that OK? I don't want to work down that
path only to have it wasted work because people think that such a
directory restructure doesn't make sense within a 2.2.x release.

PS: NO, I am not considering this for 2.2.12! :)


I guess at the heart of this is the question, how likely we break some
part of the users build process for 2.2.x. My feeling is, that the
additional sub directory for the balancing method implementations is a
small change and users build process should not break due to this
additional one directory.

On the positive side apart from easier backports: the new subdirectory
might make people more curious on how to add a custom balancing  
method,
so we get a slightly better visibility for the existing provider  
interface.




My thoughts as well... :)

Re: Backports from trunk to 2.2 proxy-balancers

[Plüm, Rüdiger, VF-Group]

 

 -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, with the
  intent of it actually being folded *into* 2.2, if the 
 branch used the
  same dir structure as trunk, that is, a separate directory 
 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 improvements into 2.2, we also need to backport the dir
  structure as well, is that OK? I don't want to work down that
  path only to have it wasted work because people think that such a
  directory restructure doesn't make sense within a 2.2.x release.
  
  PS: NO, I am not considering this for 2.2.12! :)
 
 I guess at the heart of this is the question, how likely we break some
 part of the users build process for 2.2.x. My feeling is, that the
 additional sub directory for the balancing method implementations is a
 small change and users build process should not break due to this
 additional one directory.
 
 On the positive side apart from easier backports: the new subdirectory
 might make people more curious on how to add a custom 
 balancing method,
 so we get a slightly better visibility for the existing 
 provider interface.

The problem is that this breaks existing configurations for 2.2.x
as the balancers are now in separate modules. Thus I am -0.5 on
backporting this directory structure to 2.2.x.

Regards

Rüdiger

Re: Backports from trunk to 2.2 proxy-balancers

[jean-frederic clere]

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

branch, with the
intent of it actually being folded *into* 2.2, if the 

branch used the
same dir structure as trunk, that is, a separate directory 

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 improvements into 2.2, we also need to backport the dir
structure as well, is that OK? I don't want to work down that
path only to have it wasted work because people think that such a
directory restructure doesn't make sense within a 2.2.x release.

PS: NO, I am not considering this for 2.2.12! :)

I guess at the heart of this is the question, how likely we break some
part of the users build process for 2.2.x. My feeling is, that the
additional sub directory for the balancing method implementations is a
small change and users build process should not break due to this
additional one directory.

On the positive side apart from easier backports: the new subdirectory
might make people more curious on how to add a custom 
balancing method,
so we get a slightly better visibility for the existing 
provider interface.


The problem is that this breaks existing configurations for 2.2.x
as the balancers are now in separate modules. Thus I am -0.5 on
backporting this directory structure to 2.2.x.


May be we could keep the file structure but change the logic to the new one.
For the external proxy_balancer_method we could detect old and new ones 
no? (We have the NULL for that).


Cheers

Jean-Frederic



Regards

Rüdiger

Re: Backports from trunk to 2.2 proxy-balancers

[Jim Jagielski]

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

[Plüm, Rüdiger, VF-Group]

 

 -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: 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, with the
  intent of it actually being folded *into* 2.2, if the 
  branch used the
  same dir structure as trunk, that is, a separate directory 
  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 improvements into 2.2, we also need to backport the dir
  structure as well, is that OK? I don't want to work down that
  path only to have it wasted work because people think that such a
  directory restructure doesn't make sense within a 2.2.x release.
 
  PS: NO, I am not considering this for 2.2.12! :)
  I guess at the heart of this is the question, how likely 
 we break some
  part of the users build process for 2.2.x. My feeling is, that the
  additional sub directory for the balancing method 
 implementations is a
  small change and users build process should not break due to this
  additional one directory.
 
  On the positive side apart from easier backports: the new 
 subdirectory
  might make people more curious on how to add a custom 
  balancing method,
  so we get a slightly better visibility for the existing 
  provider interface.
  
  The problem is that this breaks existing configurations for 2.2.x
  as the balancers are now in separate modules. Thus I am -0.5 on
  backporting this directory structure to 2.2.x.
 
 May be we could keep the file structure but change the logic 
 to the new one.
 For the external proxy_balancer_method we could detect old 
 and new ones 
 no? (We have the NULL for that).

How so?
The new structure makes them separate modules which require separate
LoadModule lines for each them. Thus existing configurations simply
get broken. IMHO the logic structure (them being providers) is not
different between 2.2.x and trunk.

Regards

Rüdiger

Re: Backports from trunk to 2.2 proxy-balancers

[Plüm, Rüdiger, VF-Group]

 

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

Exactly. This is an unpleasant surprise for someone updating an
existing installation from 2.2.a to 2.2.b.

Regards

Rüdiger

Re: Backports from trunk to 2.2 proxy-balancers

[Jim Jagielski]

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


Exactly. This is an unpleasant surprise for someone updating an
existing installation from 2.2.a to 2.2.b.



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 sub-modules :) )

Re: Backports from trunk to 2.2 proxy-balancers

[Plüm, Rüdiger, VF-Group]

 

 -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: 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 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?
 
  Exactly. This is an unpleasant surprise for someone updating an
  existing installation from 2.2.a to 2.2.b.
 
 
 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 sub-modules :) )
 
Sounds fine to me. I am not opposed to the directory structure and
separate files per se. Maybe we just link them into mod_proxy_balancer
on 2.2.x whereas we keep them as separate modules on trunk.

Regards

Rüdiger

Re: Backports from trunk to 2.2 proxy-balancers

[Jim Jagielski]

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 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 sub-modules :) )

Re: Backports from trunk to 2.2 proxy-balancers

[jean-frederic clere]

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


Exactly. This is an unpleasant surprise for someone updating an
existing installation from 2.2.a to 2.2.b.



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 sub-modules :) )


+1

Cheers

Jean-Frederic

Re: Backports from trunk to 2.2 proxy-balancers

[Jim Jagielski]

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 sub-modules :) )


+1



This is now done... if we add any other balancers, we can put
them in the ./balancers/ subdir; the current 3 are in sep files
for ease of backporting but are not sub-modules but rather
linked support files ;)