Mailing List Archive

> On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
>
> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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

> Am 04.03.2022 um 18:40 schrieb Roy T. Fielding <fielding@gbiv.com>:
>
>> On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
>>
>> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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

On Fri, Mar 04, 2022 at 09:40:49AM -0800, Roy T. Fielding wrote:
> > On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
> >
> > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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

> On Mar 4, 2022, at 12:40 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>
>> On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
>>
>> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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.

On Sat, Mar 5, 2022, 11:47 AM Jim Jagielski <jim@jagunet.com> 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

On Sat, Mar 5, 2022 at 12:17 PM Stefan Eissing <stefan@eissing.org> wrote:
>
> > Am 04.03.2022 um 18:40 schrieb Roy T. Fielding <fielding@gbiv.com>:
> >
> >> On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
> >>
> >> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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.

> Am 07.03.2022 um 02:53 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>
> On Sat, Mar 5, 2022 at 12:17 PM Stefan Eissing <stefan@eissing.org> wrote:
>>
>>> Am 04.03.2022 um 18:40 schrieb Roy T. Fielding <fielding@gbiv.com>:
>>>
>>>> On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
>>>>
>>>> On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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.

On Fri, Mar 04, 2022 at 09:40:49AM -0800, Roy T. Fielding wrote:
> > On Mar 4, 2022, at 6:17 AM, Eric Covener <covener@gmail.com> wrote:
> >
> > On Fri, Mar 4, 2022 at 9:05 AM Jim Jagielski <jim@jagunet.com> 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

On 07 Mar 2022, at 11:21, Stefan Eissing <stefan@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/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
—

> On Mar 7, 2022, at 6:28 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>
> On 07 Mar 2022, at 11:21, Stefan Eissing <stefan@eissing.org <mailto:stefan@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/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

On Mon, Mar 07, 2022 at 01:28:19PM +0200, Graham Leggett wrote:
> On 07 Mar 2022, at 11:21, Stefan Eissing <stefan@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/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

On 08 Mar 2022, at 10:29, Joe Orton <jorton@redhat.com> 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/ <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
—

> On Mar 8, 2022, at 7:58 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>
>
> I would far rather the empty APLOGNO check was part of the build.
>
> Vastly simpler.
>

I agree w/ that...

> Am 08.03.2022 um 14:34 schrieb Jim Jagielski <jim@jaguNET.com>:
>
>> On Mar 8, 2022, at 7:58 AM, Graham Leggett <minfrin@sharp.fm> 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

> 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

On Tue, Mar 8, 2022 at 1:59 PM Graham Leggett <minfrin@sharp.fm> 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.

On Tue, Mar 8, 2022 at 2:34 PM Jim Jagielski <jim@jagunet.com> wrote:
>
>> On Mar 8, 2022, at 7:58 AM, Graham Leggett <minfrin@sharp.fm> 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 :)

> Am 09.03.2022 um 13:11 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>
> On Tue, Mar 8, 2022 at 2:34 PM Jim Jagielski <jim@jagunet.com> wrote:
>>
>>> On Mar 8, 2022, at 7:58 AM, Graham Leggett <minfrin@sharp.fm> 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! ;)

On 3/9/22 1:11 PM, Yann Ylavic wrote:
> On Tue, Mar 8, 2022 at 2:34 PM Jim Jagielski <jim@jagunet.com> wrote:
>>
>>> On Mar 8, 2022, at 7:58 AM, Graham Leggett <minfrin@sharp.fm> 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

On 3/8/22 4:15 PM, Stefan Eissing wrote:
>
>
>> Am 08.03.2022 um 14:34 schrieb Jim Jagielski <jim@jaguNET.com>:
>>
>>> On Mar 8, 2022, at 7:58 AM, Graham Leggett <minfrin@sharp.fm> 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