Add note that LLDB changes should be cherry-picked to swift/master

[martinboehme]

This was previously missing -- the doc mentioned only swift/master-next and release branches.

[martinboehme]

@swift-ci Please smoke test

[gribozavr]

LGTM, but I would like us to get a review from someone working on Swift-enabled LLDB like @fredriss.

[martinboehme]

@swift-ci Please smoke test Linux

[fredriss]

I don't think this reflects how anyone is working today. We work mainly on swift/master and move to swift/release/x.y when it branches. For sake of the discussion, here are the current relevant automergers:

• llvm.org:master -> github/apple:apple/master -> github/apple:swift/master-next
• github/apple:apple/stable/20200801 -> swift/release/5.3 -> swift/master

The forwarding to swift/master will disappear later in the release cycle.

The rule of thumb we use for LLDB is:

• If something is generic enough, do it upstream on llvm.org. It will end-up in swift/master-next automatically. Then cherry-pick to the appropriate branch, depending on which release it's targeted at. For changes to go into 5.3, this branch is apple/stable/20200801.
• If it cannot do it upstream, do it on either the release branch or swift/master and cherry-pick it to swift/master-next.

It would be nice to be able to live on master-next, but we're not there yet.

[martinboehme]

I don't think this reflects how anyone is working today.
[...]
If it cannot do it upstream, do it on either the release branch or swift/master and cherry-pick it to swift/master-next.

Thanks for the input!

Just to confirm: This means that the current doc (without my PR) is also already wrong, as it says

"Changes that depend on Swift (this only applies to LLDB): new commits go to swift/master-next".

You're saying this should instead read

"New commits go to swift/master"

Correct?

[fredriss]

You're saying this should instead read

"New commits go to swift/master"

Correct?

In essence, yes. But it's a little more nuanced than this. There's nothing really wrong with committing first to swift/master-next. The issue is that the branch is not fully livable yet, so people don't work on it.

The really important thing is that commits should go to both swift/master (either directly or through the current release branch), and swift/master-next. The order doesn't really matter. But given the current state of things I think it's fine to document that commits should go to swift/master first.

[martinboehme]

In essence, yes. But it's a little more nuanced than this. There's nothing really wrong with committing first to swift/master-next. The issue is that the branch is not fully livable yet, so people don't work on it.

The really important thing is that commits should go to both swift/master (either directly or through the current release branch), and swift/master-next. The order doesn't really matter. But given the current state of things I think it's fine to document that commits should go to swift/master first.

Thanks, got it!

I've changed the wording in the doc accordingly -- WDYT?

All of this is very relevant to me right now, BTW, since I'm preparing a (Swift-dependent) change for LLDB (not surprisingly, this is what triggered me to make this change to the doc). I've currently got it on swift/master-next, so I may well go ahead with committing from there first.

[martinboehme]

@swift-ci Please smoke test

[fredriss]

This looks good with one last tweak (sorry!). The current release branches are not named swift/swift-x.y-branch anymore, but swift/release/x.y.

[martinboehme]

This looks good with one last tweak (sorry!). The current release branches are not named swift/swift-x.y-branch anymore, but swift/release/x.y.

No problem. How does this look now?

[martinboehme]

@swift-ci Please smoke test

[martinboehme]

@swift-ci Please smoke test