All very, very lovely thinking! I just have one comment/question... On 15 June 2018 at 10:35, Richard Hipp <d...@sqlite.org> wrote: > On 6/15/18, David Mason <dma...@ryerson.ca> wrote: >> I heartily agree with this... A flag to allow a person (including >> Anonymous) to make a commit that would automatically go into a new branch >> like "Patch-1" (each one incrementing the branch number) is (a) better than >> emailed patches, and (b) better than pull requests. Primarily because it >> puts it into Fossil so you can use all your standard workflows. >> >> The "Patch-?" branches should not be automatically synced, and if you do a >> sync with some special flag, it should offer each of the existing patch >> branches and allow you to agree to sync it, or not. Then there needs to be >> a way to delete the patch branches (whether included into the trunk or not) > > An alternative design sketch: > > (1) Anonymous clones repo CoolApp > > (2) Anonymous makes changes to CoolApp and checks those changes into a > branch named "anon-patch" on her private clone. Repeat this step as > necessary to get anon-patch working. > > (3) Anonymous runs the command "fossil pullrequest anon-patch" > > (4) The pullrequest command creates a "bundle" out of the "anon-patch" > branch and then transmits that bundle back to the server from which > the clone originated. > > (5) The server accepts the bundle and parks it in a separate holding > table, but does not merge it or otherwise make it available to average > passers by. The server then sends email notifications to developers > with appropriate privileges to let them know that a pull request has > arrived. > > (6) Developers who receive notification of the pull request can run a > command that pulls down the bundle and applies it as a private branch > on their own personal clones of the repo. Developers can then either > approve of the pull request by publishing it (marking it non-private) > and pushing it back to the server. Or they can reject the pull > request which erases it from their clone. They might also cause the > pull request to be erased from the holding table on the server. >
Some changes may not need to be tested in a personal repo on their local machine. Would it be possible to see the changes and approve within the fossil UI? For instance, anything involving text can likely be read from a diff - spelling updates, grammar, more/less word. I know that might be getting too deep into the centralized view of a decentralize server, but it's a thought that occurred to me. > Additional notes: > > Prior to step (3), Fossil might require Anonymous to provide contact > information so that developers can get in touch in case there are > questions or requests for clarification. Anonymous might also be > asked to sign a contributors agreement to be included in the bundle > (as an entry in the bconfig table). That's a very nice thought. What is another Anonymous person were to submit a pull request, would it assume it's the same user and use the same contact info? I don't think you would want it to have a confirmation message that displays the previous Anonymous user email address. > > -- > D. Richard Hipp > d...@sqlite.org -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
