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

Reply via email to