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] A fossil library
On Jun 15, 2018, at 4:46 PM, Stephan Beal wrote: > > - refactoring to a lib is a huge effort. That’s the real trick, I think: the library needs to be part of Fossil proper, so that it stays up to date. That in turn means finding and maintaining a strong boundary between whatever your conception of “less Fossil” is from “whole Fossil.” If such a clear boundary doesn’t already exist, refactoring Fossil until such a boundary appears will be difficult, but perhaps worthwhile on its own merits, even if your liblessfossil is never used. More than once, people have proposed applications of Fossil that could use this liblessfossil, where arm-twisting whole Fossil into the role was not sensible. ___ 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] A fossil library
i will write a longer response when i'm back on the PC, but short version: - refactoring to a lib is a huge effort. - up until late 2014 i was actively working on a library port and had most of the core features working. - RSI struck me down and has since effectively removed me from the programming world, so libfossil has remained unmaintained and is not longer compatible since the addition of non-SHA1 hashes (and i have no estimate for what it would take to bring it up to date). More details upcoming about that first point in the morning. - stephan Sent from a mobile device, possibly left-handed from bed. Please excuse brevity, typos, and top-posting. On Fri, Jun 15, 2018, 22:26 Sam Putman wrote: > First post. Hi! > > I've been lurking along, following the discussion here. > > Common thread is a desire for 'more fossil'. I'm in this camp myself. > > But I see the attraction of the core fossil application. It works perfectly > for a fairly close-knit community, and it follows a philosophy that's been > working for decades now. One that is, if anything, more effective as it > becomes less fashionable. > > Let me make a suggestion: what we need is not more fossil, it is less > fossil. > > I wrote Dr. Richard Hipp about this earlier, his response was positive > enough > that I felt encouraged to bring it to the community. > > For my own projects, I've switched to fossil. It's the obvious choice, > we're > using SQLite in preference to the old pile o' files already. > > The fossil codebase has all the core algorithms for storing deltas in a > single database file, merging, deduplication, Merkle hashing, key signature > management, extensible metadata... I don't have to sell you on the virtues > of this VCS! > > I would benefit greatly from being able to use this excellent collection of > SQLite best practices and algorithms, the same way I use SQLite: as a > static > or linked library, one which can be wrapped in various FFIs for VMs, or > linked > directly from a systems language. > > My own case would call this from LuaJIT, what matters is everyone can be > happy. fossil proper can stay attuned to the SQLite/Tcl/Tk alliance, as it > should, and adventurers could wire it to mailing lists, wikis, forums. > > I think this would help fossil really stand out. Just the fact that here > we > have tools to read and write git to a single-file database, that's huge! > > Tools for revision control would be a real boon to applications already > using > SQLite as an AFF. I could go on. > > I always feel some trepidation towards what amounts to asking other people > for > free work. I feel this refactoring could benefit fossil as well as my own > software. I'd be a part of such an effort as soon as anything halfway > plausible > was compiling, if invited. > > Sincerely, > > -Sam Putman > -- > Special Circumstances > ___ > 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
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
[fossil-users] A fossil library
First post. Hi! I've been lurking along, following the discussion here. Common thread is a desire for 'more fossil'. I'm in this camp myself. But I see the attraction of the core fossil application. It works perfectly for a fairly close-knit community, and it follows a philosophy that's been working for decades now. One that is, if anything, more effective as it becomes less fashionable. Let me make a suggestion: what we need is not more fossil, it is less fossil. I wrote Dr. Richard Hipp about this earlier, his response was positive enough that I felt encouraged to bring it to the community. For my own projects, I've switched to fossil. It's the obvious choice, we're using SQLite in preference to the old pile o' files already. The fossil codebase has all the core algorithms for storing deltas in a single database file, merging, deduplication, Merkle hashing, key signature management, extensible metadata... I don't have to sell you on the virtues of this VCS! I would benefit greatly from being able to use this excellent collection of SQLite best practices and algorithms, the same way I use SQLite: as a static or linked library, one which can be wrapped in various FFIs for VMs, or linked directly from a systems language. My own case would call this from LuaJIT, what matters is everyone can be happy. fossil proper can stay attuned to the SQLite/Tcl/Tk alliance, as it should, and adventurers could wire it to mailing lists, wikis, forums. I think this would help fossil really stand out. Just the fact that here we have tools to read and write git to a single-file database, that's huge! Tools for revision control would be a real boon to applications already using SQLite as an AFF. I could go on. I always feel some trepidation towards what amounts to asking other people for free work. I feel this refactoring could benefit fossil as well as my own software. I'd be a part of such an effort as soon as anything halfway plausible was compiling, if invited. Sincerely, -Sam Putman -- Special Circumstances ___ 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] Back on-line. Was: Mailing list shutting down...
On Fri, Jun 15, 2018 at 11:32:41AM +, Pietro Cerutti wrote: > > Oh so it looks they don't offer proper mailing lists (the ones people > can subscribe and reply to) but only newsletters, which they call > mailing lists, so sorry for the noise and my confusion. I also worked on a project for a MailChip client at one point and the business practices around MailChimp turned out to be somewhat suspect in terms of providing consistent service. It handled mass email management fine, but it did some rather weird stuff with how it changed its services and notification of changes and so on that left me with a bad taste in my mouth. -- 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] fossil-users Digest, Vol 125, Issue 33
On Thu, Jun 14, 2018 at 5:20 PM, wrote: > > Date: Thu, 14 Jun 2018 15:12:17 -0600 > From: Warren Young > Subject: 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. > I agree that "designed for cathedral development" should not imply "little interest to anyone". While I dislike "marketing", I know that it is very important. To that end, I think it might be better to drop mention of "bazaar development" and "cathedral development". Also, to focus on describing the features that make Fossil different from git (and, hopefully, better. For example: * Robust SQLite datastore * Branches are "full citizens" (like in Hg), rather than "local bookmarks" * Auto-sync (enabled by default) between a clone and its upstream repository * ... etc Basically, make it appealing to "upgrade" to Fossil. ___ 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] Back on-line. Was: Mailing list shutting down...
On Jun 15 2018, 07:51 UTC, Pietro Cerutti wrote: On Jun 14 2018, 13:05 UTC, Richard Hipp wrote: On 6/13/18, Richard Hipp wrote: Unfortunately, I'm going to need to shut down this mailing list due to robot harassment. I am working to come up with a fix or an alternative now Mailing lists are now back on-line and once again accepting subscriptions. I have implemented measures to block the subscription robots and to better log subscription activity to better detect future mischief. I consider this to be a stop-gap measure that will buy me some time to implement and test a better log-term solution. The current setup will change. But the temporary measure I implemented this morning do at least get us back to a functional mailing list while work on the improved solution proceeds. Not sure whether (any of) you follow crypto-gram. This just came out today. I'd say, if it's good enough for him... "Important: Crypto-Gram Is Moving to MailChimp" https://www.schneier.com/crypto-gram/archives/2018/0615.html#1 Oh so it looks they don't offer proper mailing lists (the ones people can subscribe and reply to) but only newsletters, which they call mailing lists, so sorry for the noise and my confusion. -- Pietro Cerutti signature.asc Description: PGP signature ___ 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] Back on-line. Was: Mailing list shutting down...
On Jun 14 2018, 13:05 UTC, Richard Hipp wrote: On 6/13/18, Richard Hipp wrote: Unfortunately, I'm going to need to shut down this mailing list due to robot harassment. I am working to come up with a fix or an alternative now Mailing lists are now back on-line and once again accepting subscriptions. I have implemented measures to block the subscription robots and to better log subscription activity to better detect future mischief. I consider this to be a stop-gap measure that will buy me some time to implement and test a better log-term solution. The current setup will change. But the temporary measure I implemented this morning do at least get us back to a functional mailing list while work on the improved solution proceeds. Not sure whether (any of) you follow crypto-gram. This just came out today. I'd say, if it's good enough for him... "Important: Crypto-Gram Is Moving to MailChimp" https://www.schneier.com/crypto-gram/archives/2018/0615.html#1 -- Pietro Cerutti signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
