Date   

Re: Find some consensus

Randall Wood <rhwood@...>
 

Regarding blocking a PR by requesting changes, and requiring that PRs not have changes requested before merging: it's possible for an owner to override that and merge anyways.

Regarding indicating a PR is ready to merge: it is an assumption built into the GitHub model that PRs are ready to merge unless otherwise indicated (i.e. by using WIP in the title, failing a CI check, does not contain sufficient approving reviews), so we do not need any other markers that a PR is ready to merge.

Regarding the use of labels: special privileges are required to set labels, so we can’t depend on their use by new or occasional contributors, so I would avoid using them in any workflow at this time.

On 25-Jul-2020, at 23:07, Paul Bender <paul.bender@...> wrote:


On Jul 25, 2020, at 9:42 PM, danielb987 <db123@...> wrote:

Ok. I see what you mean. I approve your changes and I withdraw my suggestion.
Your suggestion is a good one, I just don’t have any ideas on how disputes of this nature should be handled.

I am open to ideas.

Paul



Some cases to consider

Bob Jacobsen
 

A couple people have written and called me privately with questions. Based on the questions received, I’ve pulled some points together to share with the group. I haven’t been following jmri-developers for a while, pending whatever consensus arises. So the following might not be quite on-point for the discussion. Use these as you wish.



First, lets consider some cases where people might or might not have common views about how to deal with contributed code:

1) Somebody contributes a self-contained new feature which seems to work, doesn’t change or break anything existing, has lots of test coverage, passes the CI screens, and the code looks nice and clean. - This ones an easy no-brainer to start with, and I expect people think it clearly should be merged.

2) Same as (1), except it doesn’t have any tests at all. Should it be merged to get that feature in people’s hands? Should the author have to write tests before that happens? Just 1 (to pass CI), or lots (to improve various metrics)? Or should somebody else step up and add tests? Who? One of the advocates of complete testing? Somebody who agrees it’s a cool feature?

3) Same as (1), except that it doesn’t pass a bunch of the code-style CI tests, i.e. maybe unused variables or javadoc warnings or unchecked casts or …. Should the author have to cleanly fix all these & get CI passing? Or will somebody who really cares about those step up and fix them? Or would it be OK to just put @Suppress statements in the package-info.java files, suppress them all, and move on?

4) Same as (1), except that even though it has tests and passes CI, the code doesn’t look so good: Massive cut and paste, lots of casting, uses every number from 0 to 158 as a bare constant, sometimes in decimal and sometimes in hexadecimal, throws exceptions for normal returns across levels, Yet it’s a really cool feature much loved by users. Now what? Who does what?



Now a similar range on tooling/infrastructure changes:

A) A developer wants to include a new developer tool that requires _no_ change at all by others - it just works, has documentation, does not change any existing process, etc. I.e. a new Javadoc doclet that produces prettier output and can be distributed from JMRI GitHub. What needs to be considered before merging this?

B) As (A), but there’s no documentation about how to use it. Is that needed before merge? Does the author need to write it, or should somebody else step up? How good does it have to be?

C) As (A), but it requires installation and/or setup of some utilities to use it. E.g. another IDE that somebody wants to support or a tool for (optional) testing. Does that need documentation? Anything else?

D) As (A), except it’s a mandatory step. E.g. another preprocessor that has to be run to convert some new-format text for compilation, needed on every clean build. If this requires every developer to install something, is there some cost-benefit balance done? By who? What counts as cost? What counts as benefit?

E) As (A), but it’s a new “primary build tool”, which has the side effect of making existing build tools no longer equivalent. i.e. the change to IDE X means that command-line Maven builds are not longer building the same thing, or Ant builds are, or whatever. Is there some cost-benefit balance done here? By who? What counts as cost? What counts as benefit?

(I was discussing A-E with a developer yesterday, and he said “And what if I get burned by somebody breaking Eclipse build setup again, because I was away long enough to miss the discussion?”)



Sometimes there’s an overlap of the cases, when somebody wants to make a cross-cutting change that touches 50% or 80% or 100% of the files, either now or eventually. How is that evaluated?

i) A light syntactic migration, such as `new AList<Foo>` changed to `new AList<>`. Is it OK to make a migration like this in big chunks of files, even all at once? Just a few files? If somebody starts with just a few, do they have an obligation to complete it so that the code “has a consistent form”? Or does somebody else?

ii) A heavier syntactic migration, where tastes may differ. For example, changing anonymous inner classes to lambdas, or changing loops to functional stream operations. Should people just make these conversions as they write new code? Is it ok to migrate old code? Code that other people are known to be continuously working on, even if they don’t agree the new form is clearer? Can people still write the old forms if that makes them more productive? When is the new coolness a mandatory good, when is it a matter of taste and choice, and when is it a pretentious pain that we should kill with fire?

iii) We’ve had a convention for handing functional migration through deprecation cycles. But when do we have to wait the cycle and when can we just get on with making the changes? Should we mark the code someway to separate those? If so, who’s going to do that work for all that code? Is it the people advocating for this, or will some other people be encouraged / imposed on to do it as they work on the code? Do we need a new release system, and if so, will the proponents of that do the work of setting it set up, tested, documented, etc or should somebody else be expected to do that, including being criticized afterwards?

iv) If there’s a functional migration that’s universal, like a change to logging or an interface in the jmri package or the version of some run-time or test library, how does that get done? Should the proponents be given the very large burden of making the change all at once? That’s a lot of work. It’s even more work to do it slowly, one bit at a time, because of coordination and communication burdens. But that spreads it out in time, or across people. But _how_ do you equitably spread this work across people who don’t necessarily value the change over the things they actually want to work on? When can something be imposed, and when is it not worth it?



That’s a lot of items, probably too many to think through. Maybe you can tell what I think about them, maybe not, but I encourage you all to consider each one. They’re not hypothetical. Every single one of those has a concrete example in JMRI’s history. Some were routine, a few more were easy, but some of these were very very hard. People want to make changes, and other people don’t want to get stuck with the work and/or side-effects. And that happens in lots and lots of ways. It would be good to consider them now so as to have come context when the next time one comes up.


Underlying the differences of opinion seems to be a larger question:

What it the relative importance of each of the following in the future direction of JMRI:
- cool new CS features, structures and tools in use
- clean library structure that’s usable externally
- more tested and certified code as a part to the future
- cool new app features for model railroaders


100% of any of one those four is not OK. But is 25%/25%/25%/25% the goal? If at least half should be on features and future is important, are we talking 10%/10%/20%/50%? If some developers are interested in using JMRI to learn about new techniques and cool tools, does that mean 25%/25%/10%/40% is the goal?

And once you have an idea of which is important, are there any more things that can be added to the list? What fraction of the future direction should be assigned to each of your new ones?

Bob



Bob Jacobsen
@BobJacobsen


Re: Find some consensus

Paul Bender
 

On Jul 25, 2020, at 9:42 PM, danielb987 <db123@...> wrote:

Ok. I see what you mean. I approve your changes and I withdraw my suggestion.
Your suggestion is a good one, I just don’t have any ideas on how disputes of this nature should be handled.

I am open to ideas.

Paul


Re: Find some consensus

danielb987
 

Ok. I see what you mean. I approve your changes and I withdraw my suggestion.

Daniel

2020-07-26 02:41 skrev Paul Bender:

On 7/25/20 6:10 PM, danielb987 wrote:
I agree with the changes.
As I wrote in the PR, I suggest an additional point in the section
"Merging a PR":
If there are a review requesting changes, but the author and the
reviewer cannot resolve their dispute, then ????????
Note: I write question marks since I'm not sure how this should be
handled.
I am not either and I am especially not sure what to do when your
dispute is with one of the projects owners, or worse that a dispute is
between two of the project owners.  There are currently 5 of them,
though only 2 have really been active in any way in the last several years.
A dispute with one of the owners over a PR is at least in part what
started this thread in the first place, and I don't want to go down that
path again.
Paul


Re: Find some consensus

Paul Bender
 

On 7/25/20 6:10 PM, danielb987 wrote:
I agree with the changes.

As I wrote in the PR, I suggest an additional point in the section
"Merging a PR":
If there are a review requesting changes, but the author and the
reviewer cannot resolve their dispute, then ????????

Note: I write question marks since I'm not sure how this should be
handled.
I am not either and I am especially not sure what to do when your
dispute is with one of the projects owners, or worse that a dispute is
between two of the project owners.  There are currently 5 of them,
though only 2 have really been active in any way in the last several years.

A dispute with one of the owners over a PR is at least in part what
started this thread in the first place, and I don't want to go down that
path again.

Paul


Re: Find some consensus

danielb987
 

I agree with the changes.

As I wrote in the PR, I suggest an additional point in the section "Merging a PR":
If there are a review requesting changes, but the author and the reviewer cannot resolve their dispute, then ????????

Note: I write question marks since I'm not sure how this should be handled.

I agree with @rhwood that some PRs should never be merged, for different reasons, but I'm also concerned if a single reviewer can veto a PR that the rest of us wants to be merged.

Daniel


2020-07-25 20:53 skrev Paul Bender:

All,
Just to get this back on the right thread,
Daniel asked in another thread if I would get us a starting point for
the conversation on rules for PR reviews.
It turns out we already have a page documenting the PR merging process
we should be following. The existing page is here:
https://www.jmri.org/help/en/html/doc/Technical/gitadmin.shtml
I opened a PR to update that page with the items we have been
discussing about The PR approval process:
https://github.com/JMRI/JMRI/pull/8865
Please comment here about the changes suggested.
Paul
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/4001
[2] https://groups.io/mt/75535614/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged


Re: 4.20 Release notes

Randall Wood <rhwood@...>
 

Yes, if the release notes need to be updated, go ahead and do so.

Randall

On Jul 25, 2020, at 13:44, Dan Boudreau <daboudreau@...> wrote:



The latest release notes states that there’s a known problem with 4.20, but says that it was fixed in 4.19.2. Does this note need to be removed?  I need to add some known operations issues with 2.20, so I could remove this note and add the new ones.  Can I just edit website/releasenotes/jmri4.20.shtml?  The known problem note:

 

The program might fail to start if there's a consist.xml file in the preferences directory. The workaround is to remove that file. This is fixed in the JMRI 4.19.2 test release.

 

Dan


Re: Find some consensus

Paul Bender
 

All,

Just to get this back on the right thread,

Daniel asked in another thread if I would get us a starting point for the conversation on rules for PR reviews.  

It turns out we already have a page documenting the PR merging process we should be following. The existing page is here:


I opened a PR to update that page with the items we have been discussing about The PR approval process:


Please comment here about the changes suggested.

Paul


4.20 Release notes

Dan Boudreau
 

The latest release notes states that there’s a known problem with 4.20, but says that it was fixed in 4.19.2. Does this note need to be removed?  I need to add some known operations issues with 2.20, so I could remove this note and add the new ones.  Can I just edit website/releasenotes/jmri4.20.shtml?  The known problem note:

 

The program might fail to start if there's a consist.xml file in the preferences directory. The workaround is to remove that file. This is fixed in the JMRI 4.19.2 test release.

 

Dan


Re: Merge other developers PRs?

Dave Heap
 

Paul,

On 25 Jul 2020, at 10:18 PM, Paul Bender <paul.bender@...> wrote:

If I were still in the maintainers group, I would be merging the Open PRs that have passed the required status checks.
Thanks for that opinion. I'm thinking the same way.

Dave


Re: Regarding property "intermediateSignal" proposed (bug fix?) change......

wombat_rrnut
 

Thank you Dave for that explanation.

I have learned something important.

(i.e. don’t muck with it).

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Friday, July 24, 2020 9:50 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Regarding property "intermediateSignal" proposed (bug fix?) change......

 

Greg,

 

The intermediateSignal property is only used with the intermediateSection property which is only use by Dispatcher and only occurs when the signal mast logic and related signal mast based sections are automatically generated which means manually aded turnouts are not relevant.

 

These properties are specific to a particular process within Dispatcher and are not part of the public API.

 

Dave Sand

 

 

 

----- Original message -----

From: wombat_rrnut <gbedlek001@...>

Subject: [jmri-developers] Regarding property "intermediateSignal" proposed (bug fix?) change......

Date: Friday, July 24, 2020 8:42 PM

 

To the person "in charge" of DefaultSignalMastLogicManager....(and its ilk)

 

I'm fairly new to JMRI development, so far I'm only been only in my own "world"

(i.e. I'm the "new" CTC guy).

 

Now I attempt to venture forth to other JMRI worlds, only to find possibly a VERY

minor discrepancy IMHO.

 

I'm writing my own "topology" for automatic discovery of Traffic Locking

Routes/Rules (when using LayoutEditor) for my CTC "stuff", and I came across (courtesy of Dave Sand)

a property in "DefaultSignalMastLogicManager" called "intermediateSignal".

 

Issue:

IMHO, there is a piece of code missing in the statement (in 2 places in the code):

 

if (sml.getDestinationList().size() == 1 && sml.getAutoTurnouts(sml.getDestinationList().get(0)).isEmpty()) {

 

These codes forget to check "getTurnouts"isEmpty() also, in case the user put in a MANUAL turnout.

 

Am I correct?  Even if wrong, some of the below still applies (#1, #2):

 

 

Now there are three problems:

 

#1) This property "intermediateSignal" doesn't "search" in the on-line documentation

at "https://www.jmri.org/JavaDoc/doc".  So how is a person to find this unless it is

documented?  This begs the question: Where should such things be documented?

I'd suggest NOT in DefaultSignalMastLogicManager (where it is created/removed) but in

"SignalMast" where most people would use and look for it.  But I'm not smart

enough to make that determination.

 

#2) Shouldn't this property have a "constant" defined somewhere like:

public static final String SML_PROPERTY_INTERMEDIATE_SIGNAL = "intermediateSignal";

so that if this property's name changed, other source code in the wider JMRI program wouldn't

have to be changed also (such as my own similar statement in my Topology.java file)?

 

#3) Should this change happen?  How do I know if people "in the field", say coded a

.py (Python) source code to use this, and expect it to only include "auto turnouts" and NOT

"manual" turnouts?  How does one publish to the wider world that I'm

seriously mucking with something?

 

As there has been discussion about "code review techniques", this makes my asking this

of the person who knows more about these items than me MORE important still.

 

I can do the code changes if pointed in the right places, or you (the expert) can.

I'm still (however) asking for "guidance" regarding the topics mentioned, so I don't step

on toes along the way......  :-) :-) :-) And I make everyone happy by being a good

citizen of this (new) wider JMRI world....... :-) :-) :-)

 

Sincerely

Gregory Bedlek

 

 


Re: Merge other developers PRs?

Paul Bender
 

Dave,


On Jul 25, 2020, at 12:00 AM, Dave Heap <dgheap@...> wrote:
All this discussion about reviews, consensus etc. is good and fine.

However, we now have 111 merged and at least 4 open PRs with milestone 4.21.1 merged into master.

Do we just continue with merging 4.21.1 milestones into master until such time as we have resolved our discussions and then pick up the new process by varying https://github.com/JMRI/JMRI/issues/8831 so that we lock and merge master back into dev-minor for the release of 4.21.1, thence proceeding with the new process?

That's what I'd like to know before merging any more PRs into master (although some other maintainers have already done so in the past couple of days).

If I were still in the maintainers group, I would be merging the Open PRs that have passed the required status checks.

Paul


Re: Merge other developers PRs?

Dave Heap
 

All this discussion about reviews, consensus etc. is good and fine.

However, we now have 111 merged and at least 4 open PRs with milestone 4.21.1 merged into master.

Do we just continue with merging 4.21.1 milestones into master until such time as we have resolved our discussions and then pick up the new process by varying https://github.com/JMRI/JMRI/issues/8831 so that we lock and merge master back into dev-minor for the release of 4.21.1, thence proceeding with the new process?

That's what I'd like to know before merging any more PRs into master (although some other maintainers have already done so in the past couple of days).

Dave

On 24 Jul 2020, at 3:19 PM, Dave Heap via groups.io <dgheap@...> wrote:

If it can be made clear what we are doing for 4.21.1 that would be very helpful. Are we still going to use "master"?

Once this is made clear, I'll not only proceed to raise my PR(s) but also look at merging existing PRs with milestone 4.21.1, pending appropriate review/potential impact/discussion.

Given the current climate, I'm not happy to do anything until it's made clear (preferably by Bob) how we are proceeding at this stage.


Re: Regarding property "intermediateSignal" proposed (bug fix?) change......

Dave Sand
 

Greg,

The intermediateSignal property is only used with the intermediateSection property which is only use by Dispatcher and only occurs when the signal mast logic and related signal mast based sections are automatically generated which means manually aded turnouts are not relevant.

These properties are specific to a particular process within Dispatcher and are not part of the public API.

Dave Sand



----- Original message -----
From: wombat_rrnut <gbedlek001@...>
Subject: [jmri-developers] Regarding property "intermediateSignal" proposed (bug fix?) change......
Date: Friday, July 24, 2020 8:42 PM

To the person "in charge" of DefaultSignalMastLogicManager....(and its ilk)

 

I'm fairly new to JMRI development, so far I'm only been only in my own "world"

(i.e. I'm the "new" CTC guy).

 

Now I attempt to venture forth to other JMRI worlds, only to find possibly a VERY

minor discrepancy IMHO.

 

I'm writing my own "topology" for automatic discovery of Traffic Locking

Routes/Rules (when using LayoutEditor) for my CTC "stuff", and I came across (courtesy of Dave Sand)

a property in "DefaultSignalMastLogicManager" called "intermediateSignal".

 

Issue:

IMHO, there is a piece of code missing in the statement (in 2 places in the code):

 

if (sml.getDestinationList().size() == 1 && sml.getAutoTurnouts(sml.getDestinationList().get(0)).isEmpty()) {

 

These codes forget to check "getTurnouts"isEmpty() also, in case the user put in a MANUAL turnout.

 

Am I correct?  Even if wrong, some of the below still applies (#1, #2):

 

 

Now there are three problems:

 

#1) This property "intermediateSignal" doesn't "search" in the on-line documentation

at "https://www.jmri.org/JavaDoc/doc".  So how is a person to find this unless it is

documented?  This begs the question: Where should such things be documented?

I'd suggest NOT in DefaultSignalMastLogicManager (where it is created/removed) but in

"SignalMast" where most people would use and look for it.  But I'm not smart

enough to make that determination.

 

#2) Shouldn't this property have a "constant" defined somewhere like:

public static final String SML_PROPERTY_INTERMEDIATE_SIGNAL = "intermediateSignal";

so that if this property's name changed, other source code in the wider JMRI program wouldn't

have to be changed also (such as my own similar statement in my Topology.java file)?

 

#3) Should this change happen?  How do I know if people "in the field", say coded a

.py (Python) source code to use this, and expect it to only include "auto turnouts" and NOT

"manual" turnouts?  How does one publish to the wider world that I'm

seriously mucking with something?

 

As there has been discussion about "code review techniques", this makes my asking this

of the person who knows more about these items than me MORE important still.

 

I can do the code changes if pointed in the right places, or you (the expert) can.

I'm still (however) asking for "guidance" regarding the topics mentioned, so I don't step

on toes along the way......  :-) :-) :-) And I make everyone happy by being a good

citizen of this (new) wider JMRI world....... :-) :-) :-)

 

Sincerely

Gregory Bedlek

 



Regarding property "intermediateSignal" proposed (bug fix?) change......

wombat_rrnut
 

To the person "in charge" of DefaultSignalMastLogicManager....(and its ilk)

 

I'm fairly new to JMRI development, so far I'm only been only in my own "world"

(i.e. I'm the "new" CTC guy).

 

Now I attempt to venture forth to other JMRI worlds, only to find possibly a VERY

minor discrepancy IMHO.

 

I'm writing my own "topology" for automatic discovery of Traffic Locking

Routes/Rules (when using LayoutEditor) for my CTC "stuff", and I came across (courtesy of Dave Sand)

a property in "DefaultSignalMastLogicManager" called "intermediateSignal".

 

Issue:

IMHO, there is a piece of code missing in the statement (in 2 places in the code):

 

if (sml.getDestinationList().size() == 1 && sml.getAutoTurnouts(sml.getDestinationList().get(0)).isEmpty()) {

 

These codes forget to check "getTurnouts"isEmpty() also, in case the user put in a MANUAL turnout.

 

Am I correct?  Even if wrong, some of the below still applies (#1, #2):

 

 

Now there are three problems:

 

#1) This property "intermediateSignal" doesn't "search" in the on-line documentation

at "https://www.jmri.org/JavaDoc/doc".  So how is a person to find this unless it is

documented?  This begs the question: Where should such things be documented?

I'd suggest NOT in DefaultSignalMastLogicManager (where it is created/removed) but in

"SignalMast" where most people would use and look for it.  But I'm not smart

enough to make that determination.

 

#2) Shouldn't this property have a "constant" defined somewhere like:

public static final String SML_PROPERTY_INTERMEDIATE_SIGNAL = "intermediateSignal";

so that if this property's name changed, other source code in the wider JMRI program wouldn't

have to be changed also (such as my own similar statement in my Topology.java file)?

 

#3) Should this change happen?  How do I know if people "in the field", say coded a

.py (Python) source code to use this, and expect it to only include "auto turnouts" and NOT

"manual" turnouts?  How does one publish to the wider world that I'm

seriously mucking with something?

 

As there has been discussion about "code review techniques", this makes my asking this

of the person who knows more about these items than me MORE important still.

 

I can do the code changes if pointed in the right places, or you (the expert) can.

I'm still (however) asking for "guidance" regarding the topics mentioned, so I don't step

on toes along the way......  :-) :-) :-) And I make everyone happy by being a good

citizen of this (new) wider JMRI world....... :-) :-) :-)

 

Sincerely

Gregory Bedlek

 


Re: Merge other developers PRs?

danielb987
 

2020-07-24 19:39 skrev Paul Bender:
I could write something up tonight as a starting point for circulation
if the group would like.
Yes, sounds good.

I think the discussion of how we release ( semantic versioning or the
previous method ) should be a separate discussion from the how do we
work together discussion.
I agree.

Daniel


Re: Merge other developers PRs?

Paul Bender
 

On Jul 24, 2020, at 10:11 AM, Ken Cameron <@KenC57> wrote:

Once upon a time we tried things like having WIP in the name for the PR
until we thought it read to merge. You removed the WIP when it was ready.
We still use the WIP in the title to indicate this.

I think what I have been reading is that it takes more than one set of eyes
on a PR to make it ready to merge. But for issues beyond that, I'm unsure of
what we have agreed with.
I don’t know that we have agreed to much else yet.

It boils down to now we need to decide:
1) What are we going to set as ground rules for PR approvals?
2) Are we going to open any additional communication channels?

I could write something up tonight as a starting point for circulation if the group would like.

I think the discussion of how we release ( semantic versioning or the previous method ) should be a separate discussion from the how do we work together discussion.

Paul


Re: Merge other developers PRs?

Steve Todd
 

Could we create and use "labels" for communicating amongst the group? 

"Needs Review", "Ready to Merge", etc.? 

Seems like something other teams would have come up with a standard for.

--SteveT


Re: Merge other developers PRs?

Ken Cameron
 

Once upon a time we tried things like having WIP in the name for the PR
until we thought it read to merge. You removed the WIP when it was ready. We
also used the comments and flat out said "ready to merge" too.

The way I read what Bob J had said left me with the feeling he'd hold off on
some of the work in the hopes we could discuss and get more convergence on
things. IE, he was taking a short holiday to let us figure out a few things.
While the discussions have been good, I'm not sure where we stand on any
convergence of ideas.

I think what I have been reading is that it takes more than one set of eyes
on a PR to make it ready to merge. But for issues beyond that, I'm unsure of
what we have agreed with.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Re: Merge other developers PRs?

Dave Heap
 

Daniel,

On 24 Jul 2020, at 2:29 PM, danielb987 <db123@...> wrote:

Since Bob Jacobsen focuses on his signalling project which he deserves to do, it seems that there is no one merging other developers PRs at the moment.

I'm afraid that the result is a big buildup of unmerged PRs waiting to be merged, with all the problems that may bring with it, for example collissions between PRs.

I'm not a maintainer so I can't merge PRs, but I think we should deal with it before we get too many unmerged PRs.
I've got quite a bit of ESU-specific decoder XML to merge but I've held off even raising a PR pending the possible changes and hence not being sure which branch/tag to start with and which branch to PR against.

If it can be made clear what we are doing for 4.21.1 that would be very helpful. Are we still going to use "master"?

Once this is made clear, I'll not only proceed to raise my PR(s) but also look at merging existing PRs with milestone 4.21.1, pending appropriate review/potential impact/discussion.

Given the current climate, I'm not happy to do anything until it's made clear (preferably by Bob) how we are proceeding at this stage.

Dave.