Re: [fossil-users] Perception of Fossil
A lot of people allow wiki append by anonymous on their repos. You may choose not to. Maybe PR should get its own capability so you may restrict to authenticated or particular users (or not). On June 18, 2018 8:39:59 AM EDT, Karel Gardas wrote: >On Mon, 18 Jun 2018 00:01:33 +0300 >John Found wrote: > >> > Please no, this would be real security nightmare. Anyone can attack >any fossil public repo then by simple DoS. Do not ever allow anonymous >to play with your pristine repository! If anon needs to "push" >something, then he/she needs to make his/her repo public and *you* can >investigate the patch of her/him first. >> > >> > Thanks, >> > Karel >> >> At first it seems you underestimate the ability of fossil to >withstand high load. But then, there are many ways to overload web >server without pushing bundles. My experience is that fossil is pretty >hard to be overloaded, even on very lightweight servers. > >I've not been talking about DoS using CPU consumption, but rather about >DoS based on disk size consumption. Is it that hard to create a bundle >automatically and then push that to the remote server and do that in >loop to consume all the drive space? Let's see then how underlying OS >stops logging into /var/log due to partition shared with /fossil data. >Will all the important daemons survived 0 available space etc. etc. > >By openning option to upload data somewhere for anyone, you put >yourself on very danger land indeed. IMHO! >___ >fossil-users mailing list >fossil-users@lists.fossil-scm.org >http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Mon, 18 Jun 2018 00:01:33 +0300 John Found wrote: > > Please no, this would be real security nightmare. Anyone can attack any > > fossil public repo then by simple DoS. Do not ever allow anonymous to play > > with your pristine repository! If anon needs to "push" something, then > > he/she needs to make his/her repo public and *you* can investigate the > > patch of her/him first. > > > > Thanks, > > Karel > > At first it seems you underestimate the ability of fossil to withstand high > load. But then, there are many ways to overload web server without pushing > bundles. My experience is that fossil is pretty hard to be overloaded, even > on very lightweight servers. I've not been talking about DoS using CPU consumption, but rather about DoS based on disk size consumption. Is it that hard to create a bundle automatically and then push that to the remote server and do that in loop to consume all the drive space? Let's see then how underlying OS stops logging into /var/log due to partition shared with /fossil data. Will all the important daemons survived 0 available space etc. etc. By openning option to upload data somewhere for anyone, you put yourself on very danger land indeed. IMHO! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Sun, 17 Jun 2018 20:49:25 +0200 Karel Gardas wrote: > On Fri, 15 Jun 2018 13:35:13 -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. > > Please no, this would be real security nightmare. Anyone can attack any > fossil public repo then by simple DoS. Do not ever allow anonymous to play > with your pristine repository! If anon needs to "push" something, then he/she > needs to make his/her repo public and *you* can investigate the patch of > her/him first. > > Thanks, > Karel At first it seems you underestimate the ability of fossil to withstand high load. But then, there are many ways to overload web server without pushing bundles. My experience is that fossil is pretty hard to be overloaded, even on very lightweight servers. At second, it can be made a little bit different: The permission to push bundles to be assigned to the self-registered users and to be limited by number of requests per day and/or the maximal size of the bundle pushed. This way the abusers can be banned effectively. -- http://fresh.flatassembler.net http://asm32.info John Found ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Fri, 15 Jun 2018 13:35:13 -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. Please no, this would be real security nightmare. Anyone can attack any fossil public repo then by simple DoS. Do not ever allow anonymous to play with your pristine repository! If anon needs to "push" something, then he/she needs to make his/her repo public and *you* can investigate the patch of her/him first. Thanks, Karel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Sun, 17 Jun 2018 04:06:50 + Chad Perrin wrote: > On Sat, Jun 16, 2018 at 05:05:48PM +0200, Eduardo Morras wrote: > > > > 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) > > I think that's a matter for configuration, just like whether to allow > people to self-register through the web UI and what initial > permissions a registered user should have. It is not, in my > estimation, a matter of whether or not this is a desirable feature > *at all*. I'm not against the feature, I was pointing security defects that Dr. Hipps didn't describe in his feature description and could end being a bad implementation. Discovering them after or by third persons could destroy fossil credibility. > This could, in fact, be a very important feature for some team > workflows where there may be some devs who are allowed to do this, > and others who are allowed to commit/push directly (and given the > ability to handle a contributed branch like this, to merge or > otherwise accept). Yes, the concept of core developers with commit bit and developers that submit patches to pr or bugtrack system for commit aproval is common in opensource projects. I'm a freebsd / openbsd fan and it's how those projects work. As fossil has the bug tracking inside it's logical to add this feature. > -- > Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] --- --- Eduardo Morras ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
Le 16/06/2018 à 17:05, Eduardo Morras a écrit : 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. The idea is not to allow anonymous to commit or merge. It’s to allow anonymous to send a bundle that doesn’t modify the code or the history. The package is a way to ask to commit some code. But yes, there should be a way to limit the bundle size and a way to limit the overall size allowed to store these bundles. And obviously, an option to disable the feature would be useful too. Olivier ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Sat, Jun 16, 2018 at 05:05:48PM +0200, Eduardo Morras wrote: > > 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) I think that's a matter for configuration, just like whether to allow people to self-register through the web UI and what initial permissions a registered user should have. It is not, in my estimation, a matter of whether or not this is a desirable feature *at all*. This could, in fact, be a very important feature for some team workflows where there may be some devs who are allowed to do this, and others who are allowed to commit/push directly (and given the ability to handle a contributed branch like this, to merge or otherwise accept). -- 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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 04:39:20PM -0400, Richard Hipp wrote: > On 6/15/18, Chad Perrin wrote: > > > > This would not technically be a "pull request". It would be a "merge > > request". > > Good point. It should not be called "pull-request" as pulling does > not come into play. > > On the other hand, it is not necessary a request to merge. Often a > merge is implied, but the reviewer instead might prefer to accept the > changes but leave them on a branch. In that case it might be called > "push-request". Once the branch gets pushed, then merging can come > later. You make a good point about the intention not necessarily being a merge per se. Of all the suggestions I've seen so far, I think the best so far are: * contribute - describes the sender's intention very generally * push-request - matches format of "pull request" * submit - describes the sender's action very specifically The downside of push-request, of course, is that it imperfectly describes what is going on. The push has already been accomplished at that point, though it was pushed to a sort of "pending" status. I submit that all three of these, for various reasons, have sufficient merit for this purpose, and I propose that bikeshedding the name be tabled in favor of one of these as a "working title" for the feature, with the proviso that it may be changed at some point before there is a working/testable, presumably-final-form feature in development. YMMV, as always. -- 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
Re: [fossil-users] Perception of Fossil
On Fri, 15 Jun 2018 13:35:13 -0400 Richard Hipp wrote: > On 6/15/18, David Mason 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
fossil submit Steve On 16 Jun 2018, 9:30 PM +0800, Tony Papadimitriou , wrote: > -Original Message- > From: Richard Hipp > > > Other ideas for what to name this (hypothetical and unimplemented) command: > > > > fossil contribute > > fossil bequest > > fossil bestow > > fossil proffer > > Some more ideas (in random order): > > fossil chip-in (shortest possible is ch) > fossil enqueue (shortest: en) and it could be matched by a fossil queue > (shortest: q) command to quickly check the pending queue > fossil inbound (shortest: inb) > fossil try-request (shortest: tr) > fossil consider (shortest: cons) > fossil evaluate (shortest: ev) > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
-Original Message- From: Richard Hipp Other ideas for what to name this (hypothetical and unimplemented) command: fossil contribute fossil bequest fossil bestow fossil proffer Some more ideas (in random order): fossil chip-in (shortest possible is ch) fossil enqueue (shortest: en) and it could be matched by a fossil queue (shortest: q) command to quickly check the pending queue fossil inbound (shortest: inb) fossil try-request (shortest: tr) fossil consider (shortest: cons) fossil evaluate (shortest: ev) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
Le 15/06/2018 à 22:55, John Found a écrit : On Fri, 15 Jun 2018 16:44:55 -0400 Richard Hipp wrote: Other ideas for what to name this (hypothetical and unimplemented) command: fossil contribute fossil bequest fossil bestow fossil proffer fossil propose fossil commit-request fossil ci-rq (as shorcut) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
Yup! Looks good. (I read the whole thread, but this seemed like best message to which to reply. I think Jungle-Boogie's comment about being able to accept directly from the UI for things like text updates would be great... but it could be added later.) Will need a bit of documentation to help people understand the workflow. The user might have made some changes and committed to their local trunk before they realize that they have a contribution to make, so a command to move all changes in the local repo that are different from the remote repo into a new branch would help with that: `fossil delta`? and then `fossil contribute-delta` (which has contribute as a prefix and is therefore better than push-delta because that has an existing (related) command as prefix) would be a natural way to contribute it to the repo. (The delta might be just for the branch they are on... e.g. there is a normal branch that one of the committers is working on called foo, and the user might have made changes to foo and trunk... so they should do 2 deltas - one for the foo branch and one for the trunk.) I think this would significantly address the "no pull-request" complaint that seems to be the leading excuse - other than "it's not GIT". ../Dave On 15 June 2018 at 13:35, Richard Hipp wrote: > On 6/15/18, David Mason 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). > > -- > 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 > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Fri, 15 Jun 2018 16:44:55 -0400 Richard Hipp wrote: > Other ideas for what to name this (hypothetical and unimplemented) command: > >fossil contribute >fossil bequest >fossil bestow >fossil proffer > fossil propose -- http://fresh.flatassembler.net http://asm32.info John Found ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, Richard Hipp wrote: > On 6/15/18, Chad Perrin wrote: >> >> This would not technically be a "pull request". It would be a "merge >> request". > > Good point. It should not be called "pull-request" as pulling does > not come into play. > > On the other hand, it is not necessary a request to merge. Often a > merge is implied, but the reviewer instead might prefer to accept the > changes but leave them on a branch. In that case it might be called > "push-request". Once the branch gets pushed, then merging can come > later. Other ideas for what to name this (hypothetical and unimplemented) command: fossil contribute fossil bequest fossil bestow fossil proffer -- 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
Re: [fossil-users] Perception of Fossil
On 6/15/18, Chad Perrin wrote: > > This would not technically be a "pull request". It would be a "merge > request". Good point. It should not be called "pull-request" as pulling does not come into play. On the other hand, it is not necessary a request to merge. Often a merge is implied, but the reviewer instead might prefer to accept the changes but leave them on a branch. In that case it might be called "push-request". Once the branch gets pushed, then merging can come later. -- 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
Re: [fossil-users] Perception of Fossil
It looks good to me. Actually, implementation details doesn’t really matter as long as it’s easy to contributors to push a “pull-request” (however we call it), easy for admins to check it (being able to do it also via the UI would be very nice) and accept or refuse it, and if it doesn’t make the history unreadable, it’s marvelous. Asking contact information is obviously a good idea. It would be nice also if we could setup the maximum size allowed for a patch (or the overall maximum size allowed for the db to store pull-requests) to prevent data-bombing. Olivier Le 15/06/2018 à 19:35, Richard Hipp a écrit : On 6/15/18, David Mason 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). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 12:55:34AM +0100, Thomas wrote: > On 2018-06-15 00:32, Chad Perrin wrote: > >> Pull requests are not supported, hence the software can't be used for > >> community driven open source. > > > > The pull request interface on GitHub is a feature of GitHub, not of Git. > > While it would be nice to have a similar feature built into the Fossil > > web UI, doing it the same way would require having a centralized website > > on which to implement it. Something similar could theoretically be > > supported in Fossil itself, but would not be identical to the way > > GitHub's pull request feature works. > > Yes, sorry for the ambiguity. When people talk about git they > automatically mean github. s/people/some people/ You don't need GitHub for open source development. -- 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
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 09:27:31PM +0200, Nicola Vitacolonna wrote: > On 15/06/2018 01:32, Chad Perrin wrote: > > On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: > >> > >> Pull requests are not supported, hence the software can't be used for > >> community driven open source. > > > > The pull request interface on GitHub is a feature of GitHub, not of Git. > > While it would be nice to have a similar feature built into the Fossil > > web UI, doing it the same way would require having a centralized website > > on which to implement it. Something similar could theoretically be > > supported in Fossil itself, but would not be identical to the way > > GitHub's pull request feature works. > > FWIW, GitHub pull requests have been harshly criticised by Linus > Torvalds himself [1]. Git does have its own method (`git am`). Maybe, > Fossil could implement something along the lines of `git am`. > > [1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674 I don't know that I'd describe the GitHub pull request concept in such strictly negative terms as Linus does, but it does have shortcomings for some purposes. It might also be nice to have a merge-by-email feature in Fossil similar to Git's (which is more of a "merge request" than a "pull request"). On the other hand, it's already pretty easy to "hand-craft" a pull request for Fossil, if I'm not mistaken, as long as you have a repository that's actually accessible to the recipient of the request. Just send an email or other message with the pull URI for your changes, and let the recipient use the `fossil pull` command. Is there something important I'm missing for this approach? -- 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
Re: [fossil-users] Perception of Fossil
On 6/15/18, Nicola Vitacolonna wrote: >> Git does have its own method (`git am`). > > Sorry, that should be `git request-pull`. From the manpage, it appears that the "git request-pull" command is less automatic than my proposed "fossil pullrequest" command. The git-request-pull expects the upstream reviewer to do a pull of the changes, which implies that the requester must have access to a repository that the reviewer can reach. The "fossil pullrequest" goes ahead and bundles all the changes into a neat self-contained package and sends them upstream, so that the requester does not need to host his own server. -- 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
Re: [fossil-users] Perception of Fossil
> Git does have its own method (`git am`). Sorry, that should be `git request-pull`. Nicola ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, Ron W wrote: > On Fri, Jun 15, 2018 at 2:58 PM, > > wrote: > >> >> Date: Fri, 15 Jun 2018 13:35:13 -0400 >> From: Richard Hipp >> Subject: Re: [fossil-users] Perception of Fossil >> >> An alternative design sketch: >> >> (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. >> > > How does the bundle get transmitted to the server? If via a push, making > the bundle seems like extra work.. The user types "fossil pullrequest" and the changes get sent up to the server. Why does it matter what steps Fossil undertakes behind the scenes to make this happen? -- 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
Re: [fossil-users] Perception of Fossil
On 15/06/2018 01:32, Chad Perrin wrote: > On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: >> >> Pull requests are not supported, hence the software can't be used for >> community driven open source. > > The pull request interface on GitHub is a feature of GitHub, not of Git. > While it would be nice to have a similar feature built into the Fossil > web UI, doing it the same way would require having a centralized website > on which to implement it. Something similar could theoretically be > supported in Fossil itself, but would not be identical to the way > GitHub's pull request feature works. FWIW, GitHub pull requests have been harshly criticised by Linus Torvalds himself [1]. Git does have its own method (`git am`). Maybe, Fossil could implement something along the lines of `git am`. [1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674 Nicola PS: recent Fossil fan, list subscriber and first-time poster here. Thanks for not treating me as a bot! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Fri, Jun 15, 2018 at 2:58 PM, wrote: > > Date: Fri, 15 Jun 2018 13:35:13 -0400 > From: Richard Hipp > Subject: Re: [fossil-users] Perception of Fossil > > An alternative design sketch: > > (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. > How does the bundle get transmitted to the server? If via a push, making the bundle seems like extra work.. Would it make sense to enhance Fossil to (optionally) accept only non-truck branches - and so in a way that makes them purge-able like the branch created from an imported bundle is purge-able? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, jungle Boogie wrote: > >> 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? No. Identification policies would be contained in configuration settings on the server and (automatically) downloaded when the repo is cloned. Then when Anonymous runs "fossil pullrequest", Fossil will check those identification policies and prompt the user to enter the necessary information. The identification information would be included with the bundle in the bconfig table. Of course, Anonymous has complete control over the bundle and might forge information so it is up to the reviewers to ensure that the information is complete, accurate, and acceptable to the project policies. -- 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
Re: [fossil-users] Perception of Fossil (dumb idea for pull requests)
On Thu, Jun 14, 2018 at 08:17:47PM -0600, Warren Young wrote: > > Back when I proposed the feature set that became bundles, I proposed > that it include a way for the outside contributor to create a ticket > from a bundle, which would be pushed to the remote repository for > disposition by someone with a commit bit. > > That never happened, but now I think it’s another good reason for > Fossil to have a forum feature. Someone with a forum login on a > repository but lacking a commit bit could say > > $ fossil bundle push --branch my-new-feature > > and have their un-sync’d my-new-feature branch bundled and pushed > to a sub-forum dedicated to accepting unsolicited outside > contributions. > > Effectively, the new “push” verb is “fossil bundle export > && send to contribution sub-forum,” with the local Fossil instance > transferring it directly to the remote just as with the normal push > feature. > > Someone with a commit bit could then do a one-click integration of the > bundle branch from the forum UI, presumably after testing it locally > on their machine. > > There are several advantages to doing it through Fossil UI instead of > the current mechanism: > > 1. fossil bundle import && test && fossil bundle import --publish && > send email is more involved than fossil up my-new-feature && test && > click “Integrate” in Fossil UI. > > 2. Like closing a ticket combined merging a branch with --integrate, > clicking that button would auto-close both the forum thread and the > branch. > > 3. By integrating it so tightly, the committer doesn’t need to > explicitly involve the local filesystem at all. The local Fossil > instance gets a copy of the bundled branch with the next sync past the > outside contributor’s push, and the integrate happens using that > same contributed bundle. There’s no need to rm > ~/Downloads/my-new-feature.bundle after integrating the bundle, nor > the bulky email containing it. > > 4. Now we’d have pull requests to shut the Git fans up, except > that they’d actually be push requests. :) I'm not a fan of functionality that isn't specifically about a GUI being implemented only in the GUI. Give me a command-line way to handle it as well, at least. In fact, I would be happier with CLI-only than with GUI-only (which in this case would be web-only). -- 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
Re: [fossil-users] Perception of Fossil
All very, very lovely thinking! I just have one comment/question... On 15 June 2018 at 10:35, Richard Hipp wrote: > On 6/15/18, David Mason 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
Re: [fossil-users] Perception of Fossil
On 6/15/18, David Mason 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). -- 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
Re: [fossil-users] Perception of Fossil
On Fri, 15 Jun 2018 15:23:42 +0200 "Olivier R." wrote: > When someone clones the repo, make one or several commit(s), then push > to the repo without having the right to change it, this commit could be > queued somewhere (in a temporary branch maybe?), then the > administrator(s) may apply it as it is or with modifications, or refuse > it. To avoid spams and useless commits, it should be allowed to delete > unwanted changes waiting in the queue. > > Olivier The big drawback of such workflow is that the cloned repository will quickly become very different from the base repository. But with some modification, this can be avoided - it is enough to allow such pull-requests (or push attempts?) to be possible only on the private branches. The pushed to the central repository branches will still remain private until approved. This way, the developers will keep their work branches private and will get the approved changes through the usual sync. -- http://fresh.flatassembler.net http://asm32.info John Found ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
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) ../Dave On 15 June 2018 at 09:23, Olivier R. wrote: > Le 15/06/2018 à 01:32, Chad Perrin a écrit : > >> On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: >> >>> >>> Pull requests are not supported, hence the software can't be used for >>> community driven open source. >>> >> >> The pull request interface on GitHub is a feature of GitHub, not of Git. >> While it would be nice to have a similar feature built into the Fossil >> web UI, doing it the same way would require having a centralized website >> on which to implement it. Something similar could theoretically be >> supported in Fossil itself, but would not be identical to the way >> GitHub's pull request feature works. >> > > I also feel that PR is missing in Fossil. Giving rights to unknown people > to allow them to modify the repo is annoying. > > When someone clones the repo, make one or several commit(s), then push to > the repo without having the right to change it, this commit could be queued > somewhere (in a temporary branch maybe?), then the administrator(s) may > apply it as it is or with modifications, or refuse it. To avoid spams and > useless commits, it should be allowed to delete unwanted changes waiting in > the queue. > > Olivier > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
Le 15/06/2018 à 01:32, Chad Perrin a écrit : On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: Pull requests are not supported, hence the software can't be used for community driven open source. The pull request interface on GitHub is a feature of GitHub, not of Git. While it would be nice to have a similar feature built into the Fossil web UI, doing it the same way would require having a centralized website on which to implement it. Something similar could theoretically be supported in Fossil itself, but would not be identical to the way GitHub's pull request feature works. I also feel that PR is missing in Fossil. Giving rights to unknown people to allow them to modify the repo is annoying. When someone clones the repo, make one or several commit(s), then push to the repo without having the right to change it, this commit could be queued somewhere (in a temporary branch maybe?), then the administrator(s) may apply it as it is or with modifications, or refuse it. To avoid spams and useless commits, it should be allowed to delete unwanted changes waiting in the queue. Olivier ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil (dumb idea for pull requests)
On Jun 14, 2018, at 5:50 PM, John P. Rouillard wrote: > > In message <20180614213758.ga7...@britannica.bec.de>, > Joerg Sonnenberger writes: >> >> >> How do I develop a patch locally and send it to someone for review? > > Would some combination of: > > bundle > > published via > > uv mechanism Back when I proposed the feature set that became bundles, I proposed that it include a way for the outside contributor to create a ticket from a bundle, which would be pushed to the remote repository for disposition by someone with a commit bit. That never happened, but now I think it’s another good reason for Fossil to have a forum feature. Someone with a forum login on a repository but lacking a commit bit could say $ fossil bundle push --branch my-new-feature and have their un-sync’d my-new-feature branch bundled and pushed to a sub-forum dedicated to accepting unsolicited outside contributions. Effectively, the new “push” verb is “fossil bundle export && send to contribution sub-forum,” with the local Fossil instance transferring it directly to the remote just as with the normal push feature. Someone with a commit bit could then do a one-click integration of the bundle branch from the forum UI, presumably after testing it locally on their machine. There are several advantages to doing it through Fossil UI instead of the current mechanism: 1. fossil bundle import && test && fossil bundle import --publish && send email is more involved than fossil up my-new-feature && test && click “Integrate” in Fossil UI. 2. Like closing a ticket combined merging a branch with --integrate, clicking that button would auto-close both the forum thread and the branch. 3. By integrating it so tightly, the committer doesn’t need to explicitly involve the local filesystem at all. The local Fossil instance gets a copy of the bundled branch with the next sync past the outside contributor’s push, and the integrate happens using that same contributed bundle. There’s no need to rm ~/Downloads/my-new-feature.bundle after integrating the bundle, nor the bulky email containing it. 4. Now we’d have pull requests to shut the Git fans up, except that they’d actually be push requests. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/14/18 4:59 PM, Thomas wrote: Pull requests are not supported, hence the software can't be used for community driven open source. The Tcl/Tk project uses Fossil, and it's a rather large project with a decent-sized community: http://core.tcl.tk/tcl/wiki?name=Index http://core.tcl.tk/tk/timeline?y=ci Pull requests are only one way to handle patches. A developer can fork Tcl or Tk into a branch, change it, test it, and then merge it back into the main line of development. That works well if you are one of the developers with commit access, which isn't too hard to get. If you don't have a commit bit, well, you can still send a patch to one of the core maintainers such as myself: that method has worked well since the early 1990s and is still valid. I'm happy to commit a patch that improves some aspect of Tk. A lot of what we're seeing here is a generational dispute about development methodologies: greybeards like myself are fine with patches and mailing lists, while younger folks prefer Github, pull requests, and forums. I've dabbled a bit with Github, send a few pull requests and managed a couple of projects there, but I'm not really sold on it; mainly I prefer Fossil for my own projects as well as for Tcl/Tk. Fossil is absolutely beautiful for smaller projects such as my own, which allows me to self-host Fossil on a shared GoDaddy server with a single binary installation. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-15 00:32, Chad Perrin wrote: Pull requests are not supported, hence the software can't be used for community driven open source. The pull request interface on GitHub is a feature of GitHub, not of Git. While it would be nice to have a similar feature built into the Fossil web UI, doing it the same way would require having a centralized website on which to implement it. Something similar could theoretically be supported in Fossil itself, but would not be identical to the way GitHub's pull request feature works. Yes, sorry for the ambiguity. When people talk about git they automatically mean github. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote: > > Pull requests are not supported, hence the software can't be used for > community driven open source. The pull request interface on GitHub is a feature of GitHub, not of Git. While it would be nice to have a similar feature built into the Fossil web UI, doing it the same way would require having a centralized website on which to implement it. Something similar could theoretically be supported in Fossil itself, but would not be identical to the way GitHub's pull request feature works. -- 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
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 11:04:18PM +0100, Thomas wrote: > > I forgot to mention that self-registration is something that comes along > the same line. I haven't managed to get this working with Fossil yet either. > > As far as I can see until now you got to create an account for every > contributor yourself. There's a checkbox setting on the admin "Access" page that reads as follows: [ ] Allow users to register themselves Allow users to register themselves through the HTTP UI. The registration form always requires filling in a CAPTCHA (auto-captcha setting is ignored). Still, bear in mind that anyone can register under any user name. This option is useful for public projects where you do not want everyone in any ticket discussion to be named "Anonymous". -- 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
Re: [fossil-users] Perception of Fossil (dumb idea for pull requests)
Hi all:
In message <20180614213758.ga7...@britannica.bec.de>,
Joerg Sonnenberger writes:
>On Thu, Jun 14, 2018 at 04:51:08PM -0400, Ron W wrote:
>> In another forum I follow,a commented claims that Fossil is designed for
>> "cathedral development" not "bazaar development", so would be of little
>> interest to anyone. Unfortunately, the poster did not elaborate on why.
>>
>> Except maybe possible issues scaling to a large number of contributors, I
>> don't see how Fossil is less suitable for "bazaar development" than git or
>> Hg.
>
>How do I develop a patch locally and send it to someone for review? The
>pull request model is kind of stupid and works only for a centralized
>system (the irony...), but integration of something like "patchbomb" or
>even just bundles is quite handy for this.
Would some combination of:
bundle
published via
uv mechanism
and announced via some url on the upstream fossil (e.g. fossil/pull)
work? The pull requests could be manipulated by the primary developers
similar to how wiki pages can be moderated.
So my thought is:
fossil bundle export --publish implement_pull_method.bundle --branch pull
which because of the --publish does a:
fossil uv add implement_pull_method.bundle
which then automatically sends a post to:
https://www.fossil-scm.org/pull
user: rou...@example.com
url: https://my.fossil.repo/fossil/uv/implement_pull_method
description: {derived from last checkin message maybe}
then doing a get on:
https://www.fossil-scm.org/pull
(or running fossil pull list ) for somebody logged in and allowed to
see pull requests can run:
fossil bundle import https://my.fossil.repo/fossil/uv/implement_pull_method
test, publish, purge etc
Verbs like:
fossil pull list - list name/owner/artfact_id ... for all pull requests
fossil pull allow - make available for sync (c.f. moderator approval of wiki)
fossil pull delete artifact_id - delete pull request
fossil pull describe artifact_id - show description/url and other info
to round out management of the pull request.
Thoughts?
--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-14 23:19, Joerg Sonnenberger wrote: Can you please just stop trolling? Everyone else, please ignore "Thomas". I wasn't aware that communism has taken over Germany or the US yet. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-14 23:09, Warren Young wrote: On Jun 14, 2018, at 4:04 PM, Thomas wrote: As far as I can see until now you got to create an account for every contributor yourself. I think that’s a feature in a web service that, currently, has no way to do email verification. Else, spammers again. One presumes that if Fossil gets a forum feature with email gatewaying, *optional* self-registration will come along with it. Many Fossil instance admins will want to turn such a feature off, since invite-only is how they want it in the first place. That's the way I see it too. Fossil has many issues that prevent it from being used for first-time users, or git users. Once they start off the're struggling to get it working they expect it to. That's not because the software is bad (the opposite is the case, in my opinion it's much better than most of the other version control systems) but it lacks what standard users require. It claims to be an all-in-one solution but doesn't allow self-registration and doesn't support pull requests -> That makes it a no-go for open-source projects. Most news users expect this to be a "that goes without saying". It claims to be easy to install and set up but doesn't come with a pre-defined exclusion list -> Leaving newbies with megabytes of useless and even private data in their fresh repositories they can't get rid of easily again. I remember that it took me over 80 hours to understand the principles and finally get rid of all the crap in the repository left after the first few check-ins. There's not even a single source of information that would tell you how to permanently delete files that were never meant to be in the repository. That's a no-go for open-source projects. Then you get this, just a few minutes ago: "Can you please just stop trolling? Everyone else, please ignore "Thomas". :-( ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-14 23:09, Warren Young wrote: On Jun 14, 2018, at 4:04 PM, Thomas wrote: As far as I can see until now you got to create an account for every contributor yourself. I think that’s a feature in a web service that, currently, has no way to do email verification. Else, spammers again. One presumes that if Fossil gets a forum feature with email gatewaying, *optional* self-registration will come along with it. Many Fossil instance admins will want to turn such a feature off, since invite-only is how they want it in the first place. That's the way I see it too. Fossil has many issues that prevent it from being used for first-time users, or git users. Once they start off the're struggling to get it working they expect it to. That's not because the software is bad (the opposite is the case, in my opinion it's much better than most of the other version control systems) but it lacks what standard users require. It claims to be an all-in-one solution but doesn't allow self-registration and doesn't support pull requests -> That makes it a no-go for open-source projects. Most news users expect this to be a "that goes without saying". It claims to be easy to install and set up but doesn't come with a pre-defined exclusion list -> Leaving newbies with megabytes of useless and even private data in their fresh repositories they can't get rid of easily again. I remember that it took me over 80 hours to understand the principle and finally get rid of all the crap in the repository left after the first few check-ins. There's not even a single source of information that would tell you how to permanently delete files that were never meant to be in the repository. That's a no-go for open-source projects. Then you get this, just a minute ago: "Can you please just stop trolling? Everyone else, please ignore "Thomas". ;-( ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 10:44:24PM +0100, Thomas wrote: > On 2018-06-14 22:37, Joerg Sonnenberger wrote: > > How do I develop a patch locally and send it to someone for review? The > > pull request model is kind of stupid and works only for a centralized > > system (the irony...), but integration of something like "patchbomb" or > > even just bundles is quite handy for this. > > The pull request is exactly this. Sending a patch via mail or mailing list > like the dinosaurs did is not going to make it more appealing. Can you please just stop trolling? Everyone else, please ignore "Thomas". Thanks. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Jun 14, 2018, at 4:04 PM, Thomas wrote: > As far as I can see until now you got to create an account for every > contributor yourself. I think that’s a feature in a web service that, currently, has no way to do email verification. Else, spammers again. One presumes that if Fossil gets a forum feature with email gatewaying, *optional* self-registration will come along with it. Many Fossil instance admins will want to turn such a feature off, since invite-only is how they want it in the first place. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-14 21:59, Thomas wrote: On 2018-06-14 21:51, Ron W wrote: In another forum I follow,a commented claims that Fossil is designed for "cathedral development" not "bazaar development", so would be of little interest to anyone. Unfortunately, the poster did not elaborate on why. Except maybe possible issues scaling to a large number of contributors, I don't see how Fossil is less suitable for "bazaar development" than git or Hg. Thoughts? Pull requests are not supported, hence the software can't be used for community driven open source. I forgot to mention that self-registration is something that comes along the same line. I haven't managed to get this working with Fossil yet either. As far as I can see until now you got to create an account for every contributor yourself. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-14 22:37, Joerg Sonnenberger wrote: How do I develop a patch locally and send it to someone for review? The pull request model is kind of stupid and works only for a centralized system (the irony...), but integration of something like "patchbomb" or even just bundles is quite handy for this. The pull request is exactly this. Sending a patch via mail or mailing list like the dinosaurs did is not going to make it more appealing. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 04:51:08PM -0400, Ron W wrote: > In another forum I follow,a commented claims that Fossil is designed for > "cathedral development" not "bazaar development", so would be of little > interest to anyone. Unfortunately, the poster did not elaborate on why. > > Except maybe possible issues scaling to a large number of contributors, I > don't see how Fossil is less suitable for "bazaar development" than git or > Hg. > > Thoughts? How do I develop a patch locally and send it to someone for review? The pull request model is kind of stupid and works only for a centralized system (the irony...), but integration of something like "patchbomb" or even just bundles is quite handy for this. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Jun 14, 2018, at 2:51 PM, Ron W wrote: > > In another forum I follow,a commented claims that Fossil is designed for > "cathedral development" not "bazaar development” That’s the official stance, not some rand-o’s opinion: https://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki > so would be of little interest to anyone The conclusion does not follow from the premise, else most software would never be written, which we can see from the fact that most software is not written in a bazaar style. The last time I saw stats on this, it was ~95% written for internal purposes of some sort, with only 5% published. That was before app stores and the explosion of open source, however. On the other hand, it was also before proprietary web apps, which are often built cathedral-style. > Unfortunately, the poster did not elaborate on why. Fossil wants contributors to have logins on the repository, not to be unknown outsiders. That in turn suggests an invite-only style of development, which means that a contributor must earn some amount of trust before being given a login. The above-linked page also talks about contributor agreements and license implications, which I don’t buy as necessary consequences of the Fossil user model, but these concepts are frequent companions, to be sure. You see this in Fossil’s patch and bundle mechanisms, which are much more rarely used than direct commits. In my own public projects, I take patches and bundles as letters of introduction, which I use in deciding whether to offer someone a login on the repository. Contrast Git, where the fork-and-PR model is very common, and only the closest inner circle may have direct commit rights on the official repository. That’s bazaar-style. > Except maybe possible issues scaling to a large number of contributors, I > don't see how Fossil is less suitable for "bazaar development" than git or > Hg. I think it’s an uninteresting argument for most projects, where 90+% of the code is going to be written by the inner circle anyway, no matter how you structure it, so it doesn’t matter if you call it cathedral-style or something else. Bazaar style development is only common on projects popular with developers, where many skilled people are likely to make valuable contributions. Even then, it’s not a necessary pairing, as we can see with SQLite itself, where commits are typically allowed only by a very small number. The Fossil project is more open than SQLite, but even so, only 27% of commits come from anonymous or “other,” with only two people having double-digit percentage commit rates. That’s cathedral-style, right there. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On Thu, Jun 14, 2018 at 10:51 PM Ron W wrote: > In another forum I follow,a commented claims that Fossil is designed for > "cathedral development" not "bazaar development", so would be of little > interest to anyone. Unfortunately, the poster did not elaborate on why. > Maybe he's just young and full of beans. Maybe he's equating "bazaar" with one of its more extreme implementations, "github". Or maybe he's not aware of the scope of the term "bazaar", which, n this context, predates all DVCSs that i can find record of via: https://en.wikipedia.org/wiki/Distributed_version_control#History That term was already in use by the time ESR popularized it[^1], at a time when CVS (centrally administered, like Fossil) was still king. [1] = https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar -- - stephan beal http://wanderinghorse.net/home/stephan/ "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 2018-06-14 21:51, Ron W wrote: In another forum I follow,a commented claims that Fossil is designed for "cathedral development" not "bazaar development", so would be of little interest to anyone. Unfortunately, the poster did not elaborate on why. Except maybe possible issues scaling to a large number of contributors, I don't see how Fossil is less suitable for "bazaar development" than git or Hg. Thoughts? Pull requests are not supported, hence the software can't be used for community driven open source. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Perception of Fossil
In another forum I follow,a commented claims that Fossil is designed for "cathedral development" not "bazaar development", so would be of little interest to anyone. Unfortunately, the poster did not elaborate on why. Except maybe possible issues scaling to a large number of contributors, I don't see how Fossil is less suitable for "bazaar development" than git or Hg. Thoughts? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
