On Fri, 15 Jun 2018 13:35:13 -0400 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. > > 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). I partially disagree. If you allow anonymous people to pull / commit / merge data to your 'central repository', you can get easily spammed. If I pull-request 100 images of 10MB your system will go down. Multiply it by several 'funny guys' on more than one repository and fossil credibility / reputation will be -1. People that could pull anything to any repository must be trust people. (Don't know if it's correct phrase) > -- > D. Richard Hipp > d...@sqlite.org --- --- Eduardo Morras <emorr...@yahoo.es> _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
