Discussion:
Perception of Fossil
(too old to reply)
Ron W
2018-06-14 20:51:08 UTC
Permalink
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?
Thomas
2018-06-14 20:59:12 UTC
Permalink
Post by Ron W
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.
Thomas
2018-06-14 22:04:18 UTC
Permalink
Post by Thomas
Post by Ron W
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.
Warren Young
2018-06-14 22:09:47 UTC
Permalink
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.
Thomas
2018-06-14 22:27:56 UTC
Permalink
Post by Warren Young
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".

;-(
Thomas
2018-06-14 22:37:27 UTC
Permalink
Post by Warren Young
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".

:-(
Chad Perrin
2018-06-14 23:30:18 UTC
Permalink
Post by Thomas
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 ]
Chad Perrin
2018-06-14 23:32:00 UTC
Permalink
Post by Thomas
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 ]
Thomas
2018-06-14 23:55:34 UTC
Permalink
Post by Chad Perrin
Post by Thomas
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.
Chad Perrin
2018-06-15 19:58:05 UTC
Permalink
Post by Thomas
Post by Chad Perrin
Post by Thomas
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 ]
Olivier R.
2018-06-15 13:23:42 UTC
Permalink
Post by Chad Perrin
Post by Thomas
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
David Mason
2018-06-15 17:02:29 UTC
Permalink
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
Post by Chad Perrin
Post by Thomas
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2018-06-15 17:35:13 UTC
Permalink
Post by David Mason
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
***@sqlite.org
jungle Boogie
2018-06-15 18:45:40 UTC
Permalink
All very, very lovely thinking! I just have one comment/question...
Post by Richard Hipp
Post by David Mason
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)
(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.
Post by Richard Hipp
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.
Post by Richard Hipp
--
D. Richard Hipp
--
Richard Hipp
2018-06-15 19:05:37 UTC
Permalink
Post by jungle Boogie
Post by Richard Hipp
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
***@sqlite.org
Chad Perrin
2018-06-15 20:03:35 UTC
Permalink
Post by Richard Hipp
(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.
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 ]
Richard Hipp
2018-06-15 20:39:20 UTC
Permalink
Post by Chad Perrin
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
***@sqlite.org
Richard Hipp
2018-06-15 20:44:55 UTC
Permalink
Post by Richard Hipp
Post by Chad Perrin
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
***@sqlite.org
John Found
2018-06-15 20:55:27 UTC
Permalink
On Fri, 15 Jun 2018 16:44:55 -0400
Post by Richard Hipp
fossil contribute
fossil bequest
fossil bestow
fossil proffer
fossil propose
--
http://fresh.flatassembler.net
http://asm32.info
John Found <***@asm32.info>
Olivier R.
2018-06-16 06:02:37 UTC
Permalink
Post by John Found
On Fri, 15 Jun 2018 16:44:55 -0400
Post by Richard Hipp
fossil contribute
fossil bequest
fossil bestow
fossil proffer
fossil propose
fossil commit-request
fossil ci-rq (as shorcut)
Tony Papadimitriou
2018-06-16 13:29:48 UTC
Permalink
-----Original Message-----
From: Richard Hipp
Post by Richard Hipp
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)
Steve Landers
2018-06-16 13:55:45 UTC
Permalink
fossil submit

Steve
Post by Tony Papadimitriou
-----Original Message-----
From: Richard Hipp
Post by Richard Hipp
fossil contribute
fossil bequest
fossil bestow
fossil proffer
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Chad Perrin
2018-06-17 03:59:48 UTC
Permalink
Post by Richard Hipp
Post by Chad Perrin
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 ]
Olivier R.
2018-06-15 20:26:14 UTC
Permalink
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
Post by Richard Hipp
Post by David Mason
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)
(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.
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).
David Mason
2018-06-15 22:40:55 UTC
Permalink
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
Post by Richard Hipp
Post by David Mason
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
Post by David Mason
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
Post by David Mason
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
Post by David Mason
a way to delete the patch branches (whether included into the trunk or
not)
(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.
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
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Eduardo Morras
2018-06-16 15:05:48 UTC
Permalink
On Fri, 15 Jun 2018 13:35:13 -0400
Post by Richard Hipp
Post by David Mason
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)
(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.
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)
Post by Richard Hipp
--
D. Richard Hipp
--- ---
Eduardo Morras <***@yahoo.es>
Chad Perrin
2018-06-17 04:06:50 UTC
Permalink
Post by Eduardo Morras
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 ]
Eduardo Morras
2018-06-17 15:27:19 UTC
Permalink
On Sun, 17 Jun 2018 04:06:50 +0000
Post by Chad Perrin
Post by Eduardo Morras
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.
Post by Chad Perrin
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.
Post by Chad Perrin
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
--- ---
Eduardo Morras <***@yahoo.es>
Olivier R.
2018-06-17 06:36:12 UTC
Permalink
Post by Eduardo Morras
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
Karel Gardas
2018-06-17 18:49:25 UTC
Permalink
On Fri, 15 Jun 2018 13:35:13 -0400
Post by Richard Hipp
(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
John Found
2018-06-17 21:01:33 UTC
Permalink
On Sun, 17 Jun 2018 20:49:25 +0200
Post by Eduardo Morras
On Fri, 15 Jun 2018 13:35:13 -0400
Post by Richard Hipp
(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 <***@asm32.info>
Karel Gardas
2018-06-18 12:39:59 UTC
Permalink
On Mon, 18 Jun 2018 00:01:33 +0300
Post by John Found
Post by Karel Gardas
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!
Eduard
2018-06-18 14:13:37 UTC
Permalink
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).
Post by Karel Gardas
On Mon, 18 Jun 2018 00:01:33 +0300
Post by John Found
Post by Karel Gardas
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.
Post by John Found
Post by Karel Gardas
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
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.
John Found
2018-06-15 17:18:46 UTC
Permalink
On Fri, 15 Jun 2018 15:23:42 +0200
Post by Olivier R.
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 <***@asm32.info>
Kevin Walzer
2018-06-15 01:39:19 UTC
Permalink
Post by Thomas
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
Stephan Beal
2018-06-14 21:01:14 UTC
Permalink
Post by Ron W
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
Warren Young
2018-06-14 21:12:17 UTC
Permalink
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.
Joerg Sonnenberger
2018-06-14 21:37:58 UTC
Permalink
Post by Ron W
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
Thomas
2018-06-14 21:44:24 UTC
Permalink
Post by Joerg Sonnenberger
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.
Joerg Sonnenberger
2018-06-14 22:19:52 UTC
Permalink
Post by Joerg Sonnenberger
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
Thomas
2018-06-14 22:53:47 UTC
Permalink
Post by Joerg Sonnenberger
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.
Ron W
2018-06-15 19:17:30 UTC
Permalink
Date: Fri, 15 Jun 2018 13:35:13 -0400
Subject: Re: [fossil-users] Perception of Fossil
(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?
Richard Hipp
2018-06-15 19:39:54 UTC
Permalink
On Fri, Jun 15, 2018 at 2:58 PM,
Date: Fri, 15 Jun 2018 13:35:13 -0400
Subject: Re: [fossil-users] Perception of Fossil
(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
***@sqlite.org
Nicola Vitacolonna
2018-06-15 19:27:31 UTC
Permalink
Post by Chad Perrin
Post by Thomas
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!
Chad Perrin
2018-06-15 19:54:49 UTC
Permalink
Post by Nicola Vitacolonna
Post by Chad Perrin
Post by Thomas
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 ]
Nicola Vitacolonna
2018-06-15 19:46:28 UTC
Permalink
Post by Nicola Vitacolonna
Git does have its own method (`git am`).
Sorry, that should be `git request-pull`.

Nicola
Richard Hipp
2018-06-15 19:59:45 UTC
Permalink
Post by Nicola Vitacolonna
Post by Nicola Vitacolonna
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
***@sqlite.org
Continue reading on narkive:
Loading...