On Fri, Jun 15, 2018 at 01:35:13PM -0400, Richard Hipp wrote: > > 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. > > 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).
Just one correction: This would not technically be a "pull request". It would be a "merge request". The branch would already be pushed to the upstream repo, but not yet merged. In a technical pull request, a request is sent to the upstream repo to pull from the downstream repo, which I believe you can already do with Fossil (albeit not automagically like GitHub allows). I would call that feature either "merge request", as I already called it, or "push request" if there is some perceived need for "pull request" similarity for buzzword compliance purposes. I think it is important to ensure our commands and features have names that reflect what they actually do as much as that is reasonably possible to ensure. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
