doc: Separate repository for the gui

MarcoFalke commented at 4:47 pm on May 26, 2020: member

🥅 Goals

Splitting up the GUI (and splitting out modules in general) has been brought up often in recent years. Now that the GUI is primarily connected through (internal) interfaces with the node, it seems an appropriate time to revive this discussion.

Before looking for solutions, we should define a set of goals that we want to achieve. I will start with some ideas to get started and I hope that others will chime in to share and prioritize their goals.

Separate issue and patch management

It is currently not possible to subscribe to only a subset of modules in Bitcoin Core, or exclude modules from issue and patch notifications. While it is possible to reactively mute conversations in the stream of all ongoing discussions, there is no way to proactively achieve this. Moreover, the list of open issues and pull request will always include GUI related ones by default. Only with filters it is possible to hide them.

More focused review and interests

Long term goals of the GUI are partially unclear #17395 . Bitcoin Core developers are generally fluent on the command line. Thus, they might not be interested or motivated to review improvements to the GUI, which might not affect their workflow on the command line at all. Splitting up the GUI will hopefully attract similar minded people to a project whose primary goal is to build and improve the GUI.

Maintain high quality assurance

The quality of the GUI (and even more importantly Bitcoin Core in general) must not degrade. This means that code review itself is not negatively affected by splitting the GUI, but also the integration of the GUI into the rest of Bitcoin Core. One issue could arise when arbitrary version-combinations are allowed. We are struggling hard to test against all supported versions of Boost. Making the GUI version another dimension is going to make testing impossible.

The GUI is Bitcoin Core

When a user downloads Bitcoin Core from our website (or another package manager) they expect the GUI to be included. This should not change (at least not as a result of splitting up the GUI into another project).

Similarly, when building Bitcoin Core, the gui should still be built when --with-gui is specified.

🌳 Proposed solution: Monotree

TLDR. Everything stays the same, the development process for the GUI changes slightly.

Long version:

An exact mirror of the master development branch is hosted at bitcoin-core/gui. The new repository is used to track gui-only issues and pull requests. Global changes that happen to touch gui code still go to the main repo.
All pull requests will be merged into bitcoin/bitcoin.
Decision making process and maintainers will be identical for both repos.

Disadvantages

Review activity might decrease?
It doesn’t go far enough. bitcoin/bitcoin#3440 is proposing a modularized Bitcoin Core. The GUI could be an “add-on”, connected over RPC or capnproto (bitcoin/bitcoin#10102). Thus, the gui could even be hosted as a subtree or completely separate project.

Advantages

Review activity might increase? It is impossible to predict the future, but for example the libsecp256k1 subtree has a lot of domain specific experts, maintainers and reviewers. I think longer term it makes sense to at least try this route for the gui as well.
A smaller step is easier to undo when it turns out to come with any unforeseen downsides.
No substantial changes to the decision making progress.
Nothing changes in how developers set up their dev environment or how users build from the source. Also, the release binaries and process will stay exactly the same. No version drift. Finally, code sharing between the GUI and Bitcoin Core is not made any harder.
The organizational side. There are 72 open issues (~14%) and 61 open PRs (~16%) with the GUI label. If moved to its own repo, non-GUI developers wouldn’t have to be distracted with GUI-only issues and PRs and GUI enhancements. GUI developers have their own repo to focus on GUI development exclusively.

Implementation (outstanding TODOs)

Adjust maintainer merge script https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/57
Create bitcoin-core/gui repository (empty or with master branch only)
Assign all existing bitcoin core maintainers to the new repo
Celebrate? :partying_face:
Long-term: Think how long the grace period is for existing GUI related issues and pull requests. Issues can be transferred with a script after a grace period of some months?

MarcoFalke added the label Brainstorming on May 26, 2020

MarcoFalke commented at 4:51 pm on May 26, 2020: member

There are some unrelated doc changes that I will need to split out.

Also, thanks to everyone who provided feedback or ideas that lead to this proposal!

jonatack commented at 6:17 pm on May 26, 2020: member

YMMV, and I’m surely lacking important context behind this, but here’s an anecdote. I was lead maintainer in a team of four maintainers of a popular open source database search engine from 2013-2016. About a year after I decided to move on, it was decided to do something similar to this proposal for a part of the project. Some time was spent to separate it. After that, the split-off part of the codebase saw much less attention and love. Its contributors and maintainers lost motivation. Two years after the split-off, it was decided to reintegrate it back into the project as before. Dev time and resources went into these transitions. /fin

laanwj commented at 7:15 pm on May 26, 2020: member

Concept ACK. While I agree with @jonatack’s point that tracking too many different repositories adds a burden, if it’s all just the same people, I think we’ve been running against against code review bottleneck for this repository for a long time.

The GUI is a suitably separate thing that it’d warrant being maintained separately. It could use some fresh energy (with some different maintainers enthusiastic about it, I’d hope) and I don’t think that can happen as long as it’s part of this repository.

This doesn’t get us there, but it’s at least a step.

kristapsk commented at 7:47 pm on May 26, 2020: contributor

Couldn’t git submodules be used to separate GUI to separate repository, but still allow to build GUI together with everything else?

in CONTRIBUTING.md:78 in aea6f10750 outdated

70@@ -50,9 +71,17 @@ To contribute a patch, the workflow is as follows:
71   1. Create topic branch
72   1. Commit patches
73 
74+For GUI related issues or pull requests, the https://github.com/bitcoin-core/gui repository should be used.
75+For all other issues and pull requests, the https://github.com/bitcoin/bitcoin main repository should be used.
76+
77+For global refactoring or other global changes that touche GUI code, as well as
78+non-GUI code, the main repository should be used.

flack commented at 7:49 pm on May 26, 2020:

So if a PR only adds a new GUI feature, but needs to touch a couple of lines in other areas for that, does it go into the main repo or the gui one? (and would drahtbot be able to detect conflicts if it goes to the gui one?)

MarcoFalke commented at 0:13 am on May 27, 2020:

I will run DrahtBot on the gui repo when it is created. Given that the GUI speaks with the node over interfaces, there shouldn’t be too many inter-repo conflicts.

MarcoFalke commented at 11:32 am on June 1, 2020:

Clarified, hopefully.

jonasschnelli commented at 7:47 am on May 27, 2020: contributor

Thanks for bringing this up. Concept ACK (in the long run, unsure about the way to proceed).

I think as long as the GUI is still welded together with the Core part, a submodule-ish approach (like libsecp256k1) makes little sense.
The hoped benefits are currently not git related but GitHub/Communication related. Therefore we should always question how much actual source code changes are worth implementing to bypass a communication platform issue (not saying this PR does that).
Unsure if the described mono-tree approach brings a relief in communication. Things like For global refactoring or other global changes that touche GUI code, as well as non-GUI code, the main repository should be used. makes it even more complex where to do what and how to change it if a PR suddenly needs to touch Core code.
Also unsure if the good experience we made with domain specific experts working on libsecp256k1 would also happen with the GUI. Libsecp256k1 is useful for a lot of projects (1:n) where the Bitcoin-Core-GUI would only have a specific use case (1:1). Testing the GUI and working on the GUI needs good insights into the Core repository as well (not the case for libsecp256k1).

Splitting of the GUI code and communication is probably undoubtable a great long term achievement. I just think we first need better isolation/seperation for the GUI. A feasible “API contract” how the GUI can asynchronously work with the Core part in a separate process is IMO a precondition to split the GUI into a separate repository. Otherwise I see the risk of actually increase the complexity and work-load on both sides.

MarcoFalke commented at 11:33 am on May 27, 2020: member

Looking at the last 15 or so gui related pull requests, the only one that was not gui-only was one pull request involving cs_main (#19011). For that reason it needed to also touch the node interface code.

I might do a review of all open pull requests that have “qt” or “gui” in the title, but my impression is that most are already gui-only (only changing code in the src/qt directory).

fanquake commented at 12:14 pm on May 27, 2020: member

One issue could arise when arbitrary version-combinations are allowed.

Why would the split out GUI require versioning? It’s still tightly coupled (build system, dependencies, qt version, minimum requirements wise etc) to the main repo, and the GUI repo would have no scope to change anything significant in that regard. Or do you mean this would be an issue if the GUI actually was to become an entirely separate project?

Review activity might decrease? Review activity might increase?

My guess is decrease. The libsecp256k1 repo is very different. It’s critical infrastructure, has contributors that are active across it, bitcoin/bitcoin, and many other projects, and there’s far less scope for the type of bike-shedding/personal opinion (my distro does X!) type discussion that would undoubtedly occur in a GUI only-repo. I’d assume that while some of the reviewers that may have worked on GUI PRs, may also head to the alt repo, most may just stay and migrate to different parts of the codebase.

A smaller step is easier to undo when it turns out to come with any unforeseen downsides.

Do you mean a small step change to the GUI? If we’re going to have to start reverting GUI merges because not enough people looked at the other repo before something was merged here, that would not be an improvement to the workflow of this repository or the project in general.

The organizational side. There are 72 open issues (~14%) and 61 open PRs (~16%)

Looking at the last 15 or so gui related pull requests, the only one that was not gui-only was one pull request involving cs_main (#19011). For that reason it needed to also touch the node interface code.

Looking at the open GUI tagged PRs: #18927, #18542, #18165, #18027, #17993, #17227, #16883, #16549 are some that touch areas outside the GUI.

Long-term: Think how long the grace period is for existing GUI related issues and pull requests. Issues can be transferred with a script after a grace period of some months?

I don’t think we want a long grace period. Otherwise we’re just living in the worst of both worlds. It also means a longer time for cross-referencing (in issues) to build up between the two repos, and discussions to be(come) fragmented.

Moving the GUI out of this repo is something I’ve thought about for quite some time, so Concept ACK, even though as mentioned, this would just be a partial step in (hopefully) the right direction.

Honestly I think it’s unlikely that I would want to follow the new GUI repo issue/PR discussion (i.e fully subscribed as I am here), or review and merge changes from it. Although that’s probably a little dependent on what they end up looking like.

MarcoFalke commented at 1:27 pm on May 27, 2020: member

Or do you mean this would be an issue if the GUI actually was to become an entirely separate project?

Yes, this is only a theoretical concern, if the GUI should ever become a separate software project/git tree.

If we’re going to have to start reverting GUI merges because not enough people looked at the other repo before something was merged here, that would not be an improvement to the workflow of this repository or the project in general.

One of the goals is to maintain high quality assurance. Thus, the proposed solution explicitly does not change the decision making process and the maintainers from the status quo.

I don’t think we want a long grace period. Otherwise we’re just living in the worst of both worlds. It also means a longer time for cross-referencing (in issues) to build up between the two repos, and discussions to be(come) fragmented.

To clarify, the grace period would only affect “grandfathered” pull requests, not new ones. I would feel uncomfortable closing all gui related pull requests in this repo over night (even the ones that are almost ready for merge). I think we should give each pull request that has already been filed against this repo a chance to make progess and get finalized (merged or closed) before transferring it to the new repo. Otherwise it will be the exact outcome that you try to avoid. (“discussions to be(come) fragmented”)

Looking at the open GUI tagged PRs: #18927, #18542, #18165, #18027, #17993, #17227, #16883, #16549 are some that touch areas outside the GUI.

#18927 bilingual_str is an interface to provide translations. Primarily for the GUI, but other tools could also use them. So this interface pull request should be handled in bitcoin/bitcoin, I think.
#18542 here as well, the only “non-gui” change is interface related. Maybe we could extend the rule from “gui-only means src/qt” to include changes in the interfaces folder, but I’ll leave that up for discussion.
#18165 is a “global refactoring” affecting GUI and RPC code. The goal of this pull is to share pure utility methods between both components. This pull would be correctly filed against bitcoin/bitcoin.
#18027 The non-gui changes (psbt and wallet changes that affect rpc) should be split out. This is already the policy today, unless I am mistaken?
#17993 Only interface changes. See #18542 above.
#17227, #16883 At the very least the build system changes are not strictly GUI related and should stay in this repo.
#16549 The non-gui changes (psbt and wallet changes that affect rpc) should be split out. This is already the policy today, unless I am mistaken?

MarcoFalke commented at 1:32 pm on May 27, 2020: member

Maybe we could extend the rule from “gui-only means src/qt” to include changes in the interfaces folder, but I’ll leave that up for discussion.

Added a TODO to allow for some time to think about this.

jb55 commented at 4:26 pm on May 27, 2020: member

Concept ACK, the linux-like monotree model makes a lot of sense. I mainly use email to track issues and review code, so having things split up like how lkml does it would be great. Right now it is a bit overwhelming with the number of PRs. Splitting out into separate topics might help with that and improve focus/ for each subsystem. I’m not sure it would make sense to have any other repos like one for network, etc. but one for gui seems reasonable.

practicalswift commented at 7:21 pm on May 27, 2020: contributor

Concept ACK: allowing for increased specialization is good :)

DrahtBot commented at 7:54 pm on May 27, 2020: member

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

in CONTRIBUTING.md:79 in 992f5b5619 outdated

75@@ -76,6 +76,8 @@ For all other issues and pull requests, the https://github.com/bitcoin/bitcoin m
76 
77 For global refactoring or other global changes that touche GUI code, as well as
78 non-GUI code, the main repository should be used.
79+Also, for GUI related build system changes, the main repository should be used

Sjors commented at 8:26 am on May 28, 2020:

992f5b56195c0bb3d4a12c1fc7f2af7de39d6cdd nit: “Consider making two separate pull requests.”

in CONTRIBUTING.md:80 in 220a822b9f outdated

76@@ -77,6 +77,8 @@ For all other issues and pull requests, the https://github.com/bitcoin/bitcoin m
77 For global refactoring or other global changes that touche GUI code, as well as
78 non-GUI code, the main repository should be used.
79 
80+TODO Decide what to do with interface changes (src/interfaces)

Sjors commented at 8:27 am on May 28, 2020:

If you leave the todo, point it to #19071

MarcoFalke commented at 10:29 am on May 28, 2020:

I am hoping that someone comes up with a guideline here. Otherwise I will flip a coin.

Sjors commented at 10:35 am on May 28, 2020:

I would stick to defining interfaces in the main repo for now.

in CONTRIBUTING.md:77 in aea6f10750 outdated

71@@ -72,7 +72,10 @@ To contribute a patch, the workflow is as follows:
72   1. Commit patches
73 
74 For GUI related issues or pull requests, the https://github.com/bitcoin-core/gui repository should be used.
75-For all other issues and pull requests, the https://github.com/bitcoin/bitcoin repository should be used.
76+For all other issues and pull requests, the https://github.com/bitcoin/bitcoin main repository should be used.
77+
78+For global refactoring or other global changes that touche GUI code, as well as

Sjors commented at 8:27 am on May 28, 2020:

nit: “touch”

MarcoFalke commented at 11:36 am on June 1, 2020:

Thanks, fixed.

Sjors approved

Sjors commented at 8:32 am on May 28, 2020: member

Concept ACK

It’s the most light-weight way to move to a new repository. Later on I image we’ll use a submodule or some other way to separate the codebase itself, but for now we don’t have to commit to the exact method.

Regarding #16549 UI external signer support (e.g. hardware wallet):

The non-gui changes (psbt and wallet changes that affect rpc) should be split out. This is already the policy today, unless I am mistaken?

Most of that is already separated into #16546. But e.g. 858d9555e27576b6abd618101f5717715839b723 adds a method to src/interfaces/wallet.h which isn’t needed by the RPC. So that would have to go into another PR in this new scheme, which is fine by me.

That PR requires constant rebasing on the non-GUI changes it needs. With a monotree which tracks master, that’s not a problem. But if we end up splitting the project more strongly, then it’s important that interface changes are available to the GUI repo quickly.

Can @DrahtBot still work between the two repositories?

harding commented at 7:25 pm on May 28, 2020: contributor

Concept ACK.

MarcoFalke commented at 8:06 pm on May 28, 2020: member

There has been some discussion on IRC: http://www.erisian.com.au/bitcoin-core-dev/log-2020-05-28.html#l-406

Touched a lot of points, but the relevant part for the changes in this pull are that ./src/interfaces is considered node code.

MarcoFalke renamed this:
~~[WIP RFC DONOTMERGE] meta: Separate repository for the gui~~
doc: [meta] Separate repository for the gui
on Jun 1, 2020

MarcoFalke renamed this:
~~doc: [meta] Separate repository for the gui~~
doc: Separate repository for the gui
on Jun 1, 2020

MarcoFalke removed the label Brainstorming on Jun 1, 2020

MarcoFalke added the label Docs on Jun 1, 2020

MarcoFalke force-pushed on Jun 1, 2020

MarcoFalke marked this as ready for review on Jun 1, 2020

MarcoFalke force-pushed on Jun 1, 2020

practicalswift commented at 11:39 am on June 1, 2020: contributor

ACK fa2f6ce5d8eef23edcfa38c220d4ac7468acd126: worth testing and easy to revert in the future if we don’t achieve the stated goals

hebasto approved

hebasto commented at 11:40 am on June 1, 2020: member

ACK fa2f6ce5d8eef23edcfa38c220d4ac7468acd126, but couldn’t verify links to https://github.com/bitcoin-core/gui :)

Let’s try it!

MarcoFalke force-pushed on Jun 1, 2020

MarcoFalke commented at 11:28 am on June 3, 2020: member

(Force pushed a minor reword since the previous review)

in .github/PULL_REQUEST_TEMPLATE.md:7 in fa5e306432 outdated

2@@ -3,6 +3,10 @@
3 
4 Pull requests without a rationale and clear improvement may be closed
5 immediately.
6+
7+GUI related pull requests should be opened against

jonatack commented at 11:34 am on June 3, 2020:

s/GUI related/GUI-related/ here and in the other docs in this PR

in CONTRIBUTING.md:90 in fa5e306432 outdated

83@@ -84,6 +84,22 @@ To contribute a patch, the workflow is as follows:
84   1. Create topic branch
85   1. Commit patches
86 
87+For GUI related issues or pull requests, the https://github.com/bitcoin-core/gui repository should be used.
88+For all other issues and pull requests, the https://github.com/bitcoin/bitcoin main repository should be used.
89+
90+As a rule of thumb, everything that only modifies `src/qt` is a gui-only pull request. However,

jonatack commented at 11:35 am on June 3, 2020:

s/gui/GUI/ (either all in uppercase, or all in lowercase, except for repository names and urls)

jonatack commented at 11:36 am on June 3, 2020:

s/However,/However:/ (or “More specifically:”)

in CONTRIBUTING.md:95 in fa5e306432 outdated

90+As a rule of thumb, everything that only modifies `src/qt` is a gui-only pull request. However,
91+* Global refactoring or other global changes that touch GUI code, as well as
92+  non-GUI code, the main repository should be used.
93+* For GUI related build system changes, the main repository should be used because
94+  the change needs review by the build systems reviewers.
95+* Changes in `src/interfaces` need to go to the main repository because they

jonatack commented at 11:37 am on June 3, 2020:

these three bullet points should have consistent EOL punctuation

in CONTRIBUTING.md:92 in fa5e306432 outdated

83@@ -84,6 +84,22 @@ To contribute a patch, the workflow is as follows:
84   1. Create topic branch
85   1. Commit patches
86 
87+For GUI related issues or pull requests, the https://github.com/bitcoin-core/gui repository should be used.
88+For all other issues and pull requests, the https://github.com/bitcoin/bitcoin main repository should be used.
89+
90+As a rule of thumb, everything that only modifies `src/qt` is a gui-only pull request. However,
91+* Global refactoring or other global changes that touch GUI code, as well as
92+  non-GUI code, the main repository should be used.

jonatack commented at 11:39 am on June 3, 2020:

“other global” could be “other transversal”
can omit “that touch…as non-GUI code,”
s/the main … be used./should be opened in bitcoin/bitcoin./

in CONTRIBUTING.md:88 in fa5e306432 outdated

83@@ -84,6 +84,22 @@ To contribute a patch, the workflow is as follows:
84   1. Create topic branch
85   1. Commit patches
86 
87+For GUI related issues or pull requests, the https://github.com/bitcoin-core/gui repository should be used.
88+For all other issues and pull requests, the https://github.com/bitcoin/bitcoin main repository should be used.

jonatack commented at 11:41 am on June 3, 2020:

for clarity and to promote the idea of decentralisation, would suggest avoiding the term “main” in favor of bitcoin-core/gui and bitcoin/bitcoin

MarcoFalke commented at 3:18 pm on June 3, 2020:

“main repository” seems like a good way to abbreviate “bitcoin/bitcoin repository” or “non-gui repository”.

Switched to “core repository”. Hope that’s ok as well

in CONTRIBUTING.md:98 in fa5e306432 outdated

93+* For GUI related build system changes, the main repository should be used because
94+  the change needs review by the build systems reviewers.
95+* Changes in `src/interfaces` need to go to the main repository because they
96+  might affect other components like the wallet
97+
98+It is recommended to first open a pull request against the GUI repository with

jonatack commented at 11:43 am on June 3, 2020:

suggestions:

use active rather than passive voice
begin by stating in which case this applies

in README.md:28 in fa5e306432 outdated

24@@ -25,9 +25,14 @@ information or see https://opensource.org/licenses/MIT.
25 Development Process
26 -------------------
27 
28-The `master` branch is regularly built (see doc/build-*.md for instructions) and tested, but is not guaranteed to be
29+The `master` branch is regularly built (see `doc/build-*.md` for instructions) and tested, but is not guaranteed to be

jonatack commented at 11:45 am on June 3, 2020:

missing verb: s/but is/but it is/ (or omit the comma)

in CONTRIBUTING.md:87 in fa5e306432 outdated

83@@ -84,6 +84,22 @@ To contribute a patch, the workflow is as follows:
84   1. Create topic branch
85   1. Commit patches
86 
87+For GUI related issues or pull requests, the https://github.com/bitcoin-core/gui repository should be used.

jonatack commented at 11:51 am on June 3, 2020:

I think it may be worthwhile to state here from the start that the bitcoin-core/gui repo master branch is identical to the master branch in bitcoin/bitcoin. This may avoid some confusion while reading the rest of the section.

jonatack commented at 11:52 am on June 3, 2020: member

Some suggested changes below.

MarcoFalke force-pushed on Jun 3, 2020

MarcoFalke commented at 3:21 pm on June 3, 2020: member

Addressed @jonatack’s feedback

MarcoFalke force-pushed on Jun 3, 2020

practicalswift commented at 6:57 pm on June 3, 2020: contributor

ACK fae0fe0f6e7bee941dd107241d378081f68945fc

jonatack commented at 7:08 pm on June 3, 2020: member

ACK modulo terminology nit s/“node”/“bitcoin/bitcoin”/. I am unsure if separating the repos will be beneficial but (a) I know there is much that I don’t know, and (b) I empathise with the sentiments and logic expressed by the maintainers and long-term contributors in favor of doing so, or at least trying it.

troygiorshev commented at 8:00 pm on June 3, 2020: contributor

ACK, with the following nit In https://raw.githubusercontent.com/bitcoin/bitcoin/master/.github/ISSUE_TEMPLATE.md#L12 

a removal of comment in brackets and an addition of something like:

0GUI-related issues should be opened against
1https://github.com/bitcoin-core/gui
2first. See CONTRIBUTING.md

doc: Add redirect for GUI issues and pull requests faceed753a

doc: Mention repo split in the READMEs 66666d55b1

MarcoFalke force-pushed on Jun 8, 2020

MarcoFalke commented at 2:08 pm on June 8, 2020: member

Added note as requested by @troygiorshev

ACK modulo terminology nit s/“node”/“bitcoin/bitcoin”/

Is there an issue with “node”? To me it seems an appropriate choice to abbreviate bitcoin/bitcoin, so I left it as is for now.

laanwj added this to the "Blockers" column in a project

fjahr commented at 12:16 pm on June 12, 2020: member

ACK 66666d55b16603287d30ee672061ced8fc6752ab

I am curious to see how this plays out. Generally, I share @jonatack ’s concerns but unless the major GUI contributors are against it (which does not seem to be the case), it is certainly worth a try. Are there already thoughts on how and when this should be evaluated to decide if this is a success or a failure?

MarcoFalke commented at 12:21 pm on June 12, 2020: member

I was planning to open a re-evaluation issue to collect concerns and feedback over time. If the negative feedback outweighs the positive feedback, it should be reverted without having to wait for an explicit re-evaluation point.

Though, I am also happy to host a topic in the IRC meeting in 6 months and 12 months to re-evaluate the move and consider re-adjustments.

Sjors commented at 12:28 pm on June 12, 2020: member

ACK 66666d55b16603287d30ee672061ced8fc6752ab

hebasto approved

hebasto commented at 12:29 pm on June 12, 2020: member

re-ACK 66666d55b16603287d30ee672061ced8fc6752ab

promag commented at 12:33 pm on June 12, 2020: member

ACK

troygiorshev commented at 1:00 pm on June 12, 2020: contributor

re-ACK 66666d5

practicalswift commented at 1:07 pm on June 12, 2020: contributor

re-ACK 66666d55b16603287d30ee672061ced8fc6752ab

MarcoFalke commented at 6:19 pm on June 18, 2020: member

Ok, going to merge this. Let’s continue discussion in https://github.com/bitcoin-core/gui/issues/5

MarcoFalke merged this on Jun 18, 2020

MarcoFalke closed this on Jun 18, 2020

MarcoFalke deleted the branch on Jun 18, 2020

laanwj removed this from the "Blockers" column in a project

ErikThiart commented at 8:43 pm on June 18, 2020: none

Wow, awesome.

sidhujag referenced this in commit e593102316 on Jul 7, 2020

DrahtBot locked this on Feb 15, 2022

doc: Separate repository for the gui #19071

🥅 Goals

Separate issue and patch management

More focused review and interests

Maintain high quality assurance

The GUI is Bitcoin Core

🌳 Proposed solution: Monotree

Disadvantages

Advantages

Implementation (outstanding TODOs)

Conflicts