Re: [fossil-users] [fossil-dev] About to merge the forum-v2 branch
On 01.08.18 23:43, John P. Rouillard wrote: Hi all: In message <23ebb036-9e71-4e02-b496-1361e3852...@etr-usa.com>, Warren Young writes: On Jul 31, 2018, at 7:47 AM, Richard Hipp wrote: The intent is to replace this mailing list Are you also going to import all the old content, so that people can clone the forum repo — assuming you still plan to keep the forum and code as separate repos — and get a locally-searchable archive? According to the comment above, it looks like the forum will be a separate fossil instance from the source code. I must have missed that if it was stated. Since I clone the fossil repo to my RasPI I am really not interested in cloning the forum/mailing list along with the source code. I throw away 99+% of the traffic on the mailing list after reading it. I don't really want to have to keep all of that on disk. A method that allows syncing without forum artifacts or a command to purge forum artifacts would be helpful. This would allow clones to not download or not permanently store possibly large forum discussions in their repo. +1 Have a great day. -- -- rouilj John Rouillard === My employers don't acknowledge my existence much less my opinions. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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] About to merge the forum-v2 branch
On 02.08.18 10:38, Steve Landers wrote:> On 31 Jul 2018, 9:47 PM +0800, Richard Hipp , wrote: >> I am about ready to merge the forum-v2 branch into trunk. If there >> are any objections, voice them quickly. > > An observation (not a criticism) is that (at its current state of development) the forum does not work too well on mobile devices. And so IMO it isn’t yet a replacement for the mailing list. >> Steve > having not followed the development/discussion too closely, admittedly, but regarding "forum vs. mailing list" for the fossil project itself (and in view of a couple of other comments having some misgivings regarding replacement of email by forum which I share) I would argue for running them in parallel for the foreseeable future so people can vote with their feet (or rather fingers/keyboards) what makes more sense to them for communication: mailing list or forum. I could easily envision a situation where the forum option would suit me fine for personal/small/modest projects where I also would actually _want_ to keep the whole communication with some colleagues as part of the project, and "foreign", bigger ones (fossil, tcl, sqlite, ...) where I most definitely would not be interested in doing that and also probably would prefer to use a mailing list acessed by a reasonable mail client that allows me to sort/delete/search/flag (and highlight unread) messages etc. more flexible/better (probably...) than what the forum functionality could reasonably provide. br/joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] About to merge the forum-v2 branch
On 02.08.18 17:33 , Jungle Boogie wrote: > On Thu 02 Aug 2018 11:02 AM, joerg van den hoff wrote: >> On 02.08.18 10:38, Steve Landers wrote:> On 31 Jul 2018, 9:47 PM +0800, >> Richard Hipp , wrote: >>>> I am about ready to merge the forum-v2 branch into trunk. If there >>>> are any objections, voice them quickly. >>> >> >> I could easily envision a situation where the forum option would suit me >> fine for personal/small/modest projects where I also would actually _want_ >> to keep the whole communication with some colleagues as part of the project, >> and "foreign", bigger ones (fossil, tcl, sqlite, ...) where I most >> definitely would >> not be interested in doing that and also probably would prefer to use a >> mailing list acessed by a reasonable mail client that allows me to >> sort/delete/search/flag (and highlight unread) messages etc. more >> flexible/better (probably...) than what the forum functionality could >> reasonably provide. > > > > If folks will remember back just a couple months ago, this is kind of what > started this discussion. DRH shutdown the sqlite mailing list for a day or two > because of spam. During that time many folks disucssed forums, slack channels, > discord, irc, and of course, mailing lists. > > After the mailing list was patched, the discussion continued on about how > fossil, with a forum or some kind of email delivery system, could work better > with push/pull requests. Fossil bundles were discussed, but many folks still > wanted to see a github style pull request system with email notifications and > abilities to make comments within the fossil repo, aside from wikis, tech notes, > and tickets. Dr. Hipp quickly developed email notifications for commits to the > repo, and a few ways to store the emails. > > I enjoy mailing lists, having a copy of the mail and being able to reply from > mutt (which I'm doing now), but I think what's been implemented within fossil is > something we can all appreciate and find use of. A small project may not use > tickets, the wiki, or tech notes. That project probably won't have a mailing > list either. > Now there's another feature, for free, that they also may not use - a forum. from DRH's mail of july 31: "The intent is to replace this mailing list, as well as various other mailing lists (fossil-users, sqlite-users, sqlite-dev, sqlite-announce) with the new forum feature. I hope to shut down the mailing lists and bring the forums all live within about a week. So if you have concerns, voice them soon." that's it: the concern is not that there will be "another feature" (although: whether the forum feature is a desirable one, depends on circumstances/taste and whether "pollution" of the actual repo (and also the working copy) with the forum archive/db can be avoided if the user is not interested in carrying the forum archive around. IIRC, the forum content is going to reside in a separate db, which sure will help, but I actually would prefer if that db does not materialize in my checkout without a means/setting to prevent just that (or to empty it...). the specific _concern_ here is the contemplated shutdown of this mailing list and mandatory(!) migration of all questions/discussions to the planned/upcoming fossil-scm forum. if that's what going to happen: so be it. but I would prefer otherwise. > >> br/joerg > > > > Just my opinion on this subject. Please refer to the mailing list archive for a > more accurate account for the discussion, but this is how I remember it > happening/taking place. > ___ > 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
[fossil-users] strange delay and messages during `fossil (uv) sync'
I see substantial delay (order of many seconds to minute(s)) when
executing
`fossil sync' or `fossil uv sync'
between a clone and a "remote" repository residing on the same file system and communicating via
ssh. the command finally succeeds and completes (but it really takes time...) with the message
multiple calls to backoffice_run() received: 0
server did not reply
done, sent: 660 received: 807 ip: {hostname}
I think this is closely related to
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27987.html
but might not be quite the same thing. so I thought it OK to report it again.
just in case...
seen with 2.6 [74c908e709] 2018-08-03 21:06:57 UTC
thank you
joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 06.08.18 22:19, Richard Hipp wrote:
> Here is the technical problem I am having difficulty with. My
> currently solution is (probably) what is causing the delays and errors
> you are seeing. Suggestions from you are any mailing list reader on
> how to solve this problem are appreciated.
I've read through your explanations below but there are sure no
suggestion from my side... I hardly understand the nature of the
problem. especially I am at a loss where all this backoffice machinery
interferes with CLI/ssh communication between two repos (or cloning, see
below).
however, I would like to augment the list of problems I am experiencing
right now (this is with version [71260ba2] as proposed by you earlier
today):
* fossil uv sync no longer works correctly. I did try it this evening
(still accessing our server via ssh but now over the wire from home
rather than from wihtin the file system (if this makes any difference)
and was not able to get one new uv file that was added to the server
repo sync to my labtop.
* I then tried to re-clone the whole repo. cloning failed completely with
multiple calls to backoffice_run() received: 113
server did not reply
Clone done, sent: 676 received: 364935 ip: {our_server}
server returned an error - clone aborted
I also want to emphasize that these problems all happen without ever
opening the fossil ui or trying to communicate via https. this is a pure
CLI/ssh scenario.
so this all is rather bad. it is also the first time in years that I can
remember that the tip of trunk is not working essentially without any
serious problems.
I would appreciate being pointed to the most recent (or thereabouts)
checkin on trunk that is not experiencing these problems in order to
get fossil back to working as nicely as it usually does.
If I can provide any further information or help otherwise in tracking
the present problems down, I would of course be happy to do so.
overall, I really hope that not too much complexity is currently added
to fossil that could lead to a situation where fossil no longer excels
by ease of use and stability/absence of problems or serious bugs as it
has done now for so many years, thankfully.
thank you,
joerg
>
> Basically: Fossil needs to run some operations in the background.
>
> With the introduction of email notification, some computations need to
> be performed in the background on the Fossil server. Right now, the
> only background operation is sending email alerts to subscribers. In
> the future, I'll probably want to add automatic synchronization to
> peer servers and maybe other things.
>
> I call the module that does background processing the "backoffice".
> The name comes from the analogy of a business where an order is placed
> at the counter in the front of the store, but the actually fulfillment
> of the order takes place in the "back office", out of sight of the
> customer.
>
> Backoffice rules:
>
> (1) Only a single process should be running backoffice processing at a
> time. There can be multiple processes serving up web pages, but there
> is only a single process sending email notification. Serialization of
> backoffice processing is handled by making atomic updates to the entry
> in the repository CONFIG table with name='backoffice'.
>
> (2) Backoffice processing should happen independently of webpage
> generation. The results of an HTTP request should not need to wait
> for some backoffice process to complete.
>
> (3) Once one backoffice process completes, no other should run for
> another 60 seconds or so. In other words, backoffice processes should
> be rate limited.
>
> (4) At least one backoffice process should be run within about 60
> seconds after the any successful HTTP request. A single backoffice
> run can satisfy this requirement for any number of HTTP requests. So,
> for example, if there is a flurry of 1000 HTTP requests then 5 seconds
> later there is a single backoffice run, then that one run of the
> backoffice is sufficient for all 1000 HTTP requests.
>
> (5) If there are no HTTP request in the past minute or two, then there
> should not be any backoffice processes running or waiting to run. The
> idea here is that a website like sqlite.org has literally about a
> hundred separate Fossil repositories. SQLite is very busy and it
> would be ok to have a persistent backoffice process running for it.
> But many of the other 99 repos are accessed much less frequently, and
> we don't want 99 processes waiting around for activity for days on
> end. Also, I want to be able to upgrade the Fossil executable by
> simply overwriting it, and then have any backoffice processes
> eventually (within a minute or two) switch over to using the new
> executable.
>
> (6) In keeping with the easy-to-setup goal of Fossil, running the
> backoffice process should not require any special setup or
> configuration by the site administrator. It should just work.
>
> The way the above is implemented
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 07.08.18 00:36, Richard Hipp wrote: > On 8/6/18, joerg van den hoff wrote: >> question: the observation that it seemingly is related specifically to >> repos holding uv files is unimportant/irrelevant? or does that have >> implications where to look? > > This is not much help in debugging. But it is helpful to you in > bisecting, because it allows you to quickly and easily determine if a > particular various is working or not. > > BTW, when doing the bisect, be sure to use the same Fossil version on > both ends of the SSH connection. We do not know on which end the > problem exists, so it is better to eliminate that variable. > >> then I do wish you much success with achieving that, of course. > > Your assistance in bisecting the delay problem is a step in that > direction. Thanks. this is what I've got: bisect complete 1 BAD 2018-07-31 23:38:39 71260ba25e79f4aa # error message, clone fails 5 BAD 2018-07-24 22:01:12 42d821a714d092a8 # error message, clone fails 7 BAD 2018-07-19 18:54:39 ac6657e2d35c974d # clone hangs infinitely, no error message 9 BAD 2018-07-19 17:22:04 ada7ecde5bf91e18 # clone hangs infinitely, no error message 10 BAD 2018-07-19 16:27:51 f525b6d5e9dcb775 # clone hangs infinitely, no error message 11 BAD 2018-07-19 15:58:36 a32a92d227be5663 CURRENT # clone hangs infinitely, no error message 8 GOOD2018-07-19 15:52:43 aa17077eafbbad37 6 GOOD2018-07-18 19:22:31 752ea432d1cf20fa 4 GOOD2018-07-14 20:11:37 023ce4edde8ceb2d 3 GOOD2018-06-23 15:48:49 aeb98be80f1d51f5 2 GOOD2018-01-07 21:38:26 5b558bc76bb9fb5f so the last good one is aa17077eafbbad37. NOTE: 1. I ran this with another repo not holding any uv files and still got the errors. so my previous observation (only affecting uv sync seems spurious or at least not true for all repos) 2. the bisect is true for the scenario: use ssh-transport from a local machine over the wire to the remote server. it does *not* happen (with this repo) if I do the same while being logged in to the server holding the remote repo. in the latter case the clone suceeds with tip of trunk... 3. I have added comments in the bisect log which refer to the checkin _above_ the comment. the point I want to stress is that the BAD behaviour changes during the bisect: initially after the last GOOD checkin, the clone just hangs and never comes back, later/more recently the error messages and manifest "clone aborted/failed" messages appear. 4. the bisect was performed on the (linux/ubuntu) server while keeping the local (osx) labtop version of fossil constant (on 71260ba25e79f4aa, I believe). so I think this proves that the problem is happening "on the other side", not locally). hth, joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 07.08.18 15:53 , Richard Hipp wrote: Please build the from the tip of the forum-v2 branch and let me know whether or not it is working for you. if the server machine is running that version, yes it does indeed. thanks a lot for looking into this issue ... I see from the checkin message that the "fix" is achieved by "Disable the backoffice for SSH client". whatever the actual interaction between backoffice and ssh client: why did I see the problem only when actually cloning from another machine, whereas a clone using ssh while being loggedin to the server machine still worked? in both cases the ssh communication should be the same, no? On 8/7/18, joerg van den hoff wrote: On 07.08.18 00:36, Richard Hipp wrote: > On 8/6/18, joerg van den hoff wrote: >> question: the observation that it seemingly is related specifically to >> repos holding uv files is unimportant/irrelevant? or does that have >> implications where to look? > > This is not much help in debugging. But it is helpful to you in > bisecting, because it allows you to quickly and easily determine if a > particular various is working or not. > > BTW, when doing the bisect, be sure to use the same Fossil version on > both ends of the SSH connection. We do not know on which end the > problem exists, so it is better to eliminate that variable. > >> then I do wish you much success with achieving that, of course. > > Your assistance in bisecting the delay problem is a step in that > direction. Thanks. this is what I've got: bisect complete 1 BAD 2018-07-31 23:38:39 71260ba25e79f4aa # error message, clone fails 5 BAD 2018-07-24 22:01:12 42d821a714d092a8 # error message, clone fails 7 BAD 2018-07-19 18:54:39 ac6657e2d35c974d # clone hangs infinitely, no error message 9 BAD 2018-07-19 17:22:04 ada7ecde5bf91e18 # clone hangs infinitely, no error message 10 BAD 2018-07-19 16:27:51 f525b6d5e9dcb775 # clone hangs infinitely, no error message 11 BAD 2018-07-19 15:58:36 a32a92d227be5663 CURRENT # clone hangs infinitely, no error message 8 GOOD2018-07-19 15:52:43 aa17077eafbbad37 6 GOOD2018-07-18 19:22:31 752ea432d1cf20fa 4 GOOD2018-07-14 20:11:37 023ce4edde8ceb2d 3 GOOD2018-06-23 15:48:49 aeb98be80f1d51f5 2 GOOD2018-01-07 21:38:26 5b558bc76bb9fb5f so the last good one is aa17077eafbbad37. NOTE: 1. I ran this with another repo not holding any uv files and still got the errors. so my previous observation (only affecting uv sync seems spurious or at least not true for all repos) 2. the bisect is true for the scenario: use ssh-transport from a local machine over the wire to the remote server. it does *not* happen (with this repo) if I do the same while being logged in to the server holding the remote repo. in the latter case the clone suceeds with tip of trunk... 3. I have added comments in the bisect log which refer to the checkin _above_ the comment. the point I want to stress is that the BAD behaviour changes during the bisect: initially after the last GOOD checkin, the clone just hangs and never comes back, later/more recently the error messages and manifest "clone aborted/failed" messages appear. 4. the bisect was performed on the (linux/ubuntu) server while keeping the local (osx) labtop version of fossil constant (on 71260ba25e79f4aa, I believe). so I think this proves that the problem is happening "on the other side", not locally). hth, joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 07.08.18 16:16 , Andy Bradford wrote: > Thus said joerg van den hoff on Tue, 07 Aug 2018 16:10:15 +0200: > >> why did I see the problem only when actually cloning from another >> machine, whereas a clone using ssh while being loggedin to the server >> machine still worked? in both cases the ssh communication should be >> the same, no? > > How were you cloning while logged in to the server machine? What > commands did you use while loggged in to the server to clone? uups, you are right, sorry for me spreading "misinformation": actually the clone while being logged in to the server (via ssh ... ;)) was done via file system transport, _not_ via ssh transport (I simply used `fossil clone /path/to/repo.fossil ...'). that of course explains it, I presume... again, sorry for the noise, joerg > > Thanks, > > Andy > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] `set uv-syn on' only partly honoured (again)
with current tip of trunk fossil set uv-sync on is not honoured by `clone', i.e. without explicit `clone -u', the uv files are not cloned. a subsequent `sync' (w/o the `-u'), however, does indeed initiate transfer of the uv-files from remote repo into the new clone. according to manpage the same should happen with `clone' if uv-sync is "on". ___ 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] This mailing list is now deprecated
On 08.08.18 14:40 , Richard Hipp wrote: Please discontinue use of this mailing list except as an emergency back-up to the forum in case the forum stops working. If forum is not working, you can also send email directly to me. well no luck here. this: An email has been sent to "veedeeh...@gmail.com". That email contains a hyperlink that you must click on in order to activate your subscription. simply has not happened so far (>5-10 minutes since subscribe). br/joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
