Discussion:
opening more than one ui on localhost
(too old to reply)
Boruch Baum
2016-02-12 15:22:57 UTC
Permalink
I'm evaluating Fossil:

1] How can I keep more than project repository UI open on localhost for
web interfacing. In my case, the two of interest were my test project
and the fossil documentation project. It would seem a reasonable and
common request to have more than one project open.

2] How to submit a bug or issue ticket to fossil itself without being
logged in. In my case, I wanted to submit a ticket to the fossil-scm.org
site, and even logging in anonymously didn't seem to give me access to
ticket submission. From my test project, it seems the method is to
assign permission "t (Tkt-Report)" to user "nobody", but how would one
submit a ticket to fossil (eg, #1, above)? Does the project want to
accept input from this mailin list?
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Stephan Beal
2016-02-12 15:41:56 UTC
Permalink
Post by Boruch Baum
1] How can I keep more than project repository UI open on localhost for
web interfacing. In my case, the two of interest were my test project
and the fossil documentation project. It would seem a reasonable and
common request to have more than one project open.
Try:

fossil ui

from both trees. Fossil will dynamically select a port, starting at 8080,
and start the browser with the proper port number.
Post by Boruch Baum
2] How to submit a bug or issue ticket to fossil itself without being
logged in.
This list.
Post by Boruch Baum
submit a ticket to fossil (eg, #1, above)? Does the project want to
accept input from this mailin list?
Yes :).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"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
Richard Hipp
2016-02-12 15:50:40 UTC
Permalink
Post by Stephan Beal
Post by Boruch Baum
2] How to submit a bug or issue ticket to fossil itself without being
logged in.
This list.
Post by Boruch Baum
submit a ticket to fossil (eg, #1, above)? Does the project want to
accept input from this mailin list?
Yes :).
To clarify: We used to allow people to submit tickets anonymously.
But that feature was heavily misused, and in some cases abused, so we
turned it off. The policy now is that you have to bring up an issue
on the mailing list, and if it cannot be resolved there, then one of
the maintainers will create the ticket.
--
D. Richard Hipp
***@sqlite.org
Boruch Baum
2016-02-12 17:33:52 UTC
Permalink
Post by Richard Hipp
Post by Stephan Beal
Post by Boruch Baum
2] How to submit a bug or issue ticket to fossil itself without being
logged in.
This list.
Post by Boruch Baum
submit a ticket to fossil (eg, #1, above)? Does the project want to
accept input from this mailin list?
Yes :).
To clarify: We used to allow people to submit tickets anonymously.
But that feature was heavily misused, and in some cases abused, so we
turned it off. The policy now is that you have to bring up an issue
on the mailing list, and if it cannot be resolved there, then one of
the maintainers will create the ticket.
ׂGot it. Your answer made me think of the use of a forum as an
alternative to e-mail, and then I checked and see that a forum seems to
be the only thing missing from fossil. Is that intentional? The
advantages of a forum include the ease of finding and continuing past
threads on similar subjects; grouping of threads into topics; and a
place to keep a written record of project related discussions among
developers that span any notion of a single 'ticket'. A lot of the
functionality -could- be kludged by using the current 'ticket' if there
were the ability to add ticket type categories. Could this be done?

I do see a url:
http://localhost:8081/tktsetup_tab
that allows editing the ticket table Schema, but I don't see how to add
to the ENUM values of a schema entry (ie. "type")

From the url:
http://localhost:8081/tktsetup_newpage
I see:
<th1>combobox type $type_choices 1</th1>
But I don't see how to modify that.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Warren Young
2016-02-12 18:24:05 UTC
Permalink
Post by Boruch Baum
Your answer made me think of the use of a forum as an
alternative to e-mail, and then I checked and see that a forum seems to
be the only thing missing from fossil. Is that intentional?
Given that ticket spam is pretty much the same problem as forum spam, I’d say it probably is intentional.

Email has its problems, but there’s an awful lot of antispam infrastructure around it that would have to be recreated to allow fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent protections.

There are people working on this problem (e.g. Discourse) but I have yet to see anything compelling. Even if Discourse did someday become thoroughly awesome — which it very much is not today — it still isn’t going to be integrated into Fossil, due to the latter’s single-binary philosophy.

drh has publicly stated a desire to write his own email server. (See the FLOSS Weekly interview.) Perhaps he wishes to reinvent mailing lists and web archives, too, so he could drop Mailman and whatever SMTP server he’s using.

Me, I’d rather he stay focused on SQLite and Fossil.
Post by Boruch Baum
The advantages of a forum include the ease of finding and continuing past
threads on similar subjects
The Fossil email list archives are just as usable as any web forum I’ve ever used:

http://www.mail-archive.com/fossil-***@lists.fossil-scm.org/

In fact, I’d say they’re easier because conversations are threaded. Most web forums I’ve used have flat conversations, so it isn’t always easy to see who is responding to who.
Post by Boruch Baum
grouping of threads into topics
That’s why many projects have multiple mailing lists. Fossil has two: this one and fossil-dev.

If Fossil had a web forum, I’d expect it to have two sub-forums instead. So, what’s the difference?
Post by Boruch Baum
a place to keep a written record of project related discussions among
developers that span any notion of a single 'ticket’.
If Fossil ever did grow a mailing list management system, it would be spiffy to be able to drop artifact IDs, wiki references, and such into an email and have them automatically linked to the appropriate page in the Fossil UI.

But that sounds like a pipe dream at this point.
Post by Boruch Baum
<th1>combobox type $type_choices 1</th1>
But I don't see how to modify that.
I think you might find what you want here:

http://localhost:8082/tktsetup_com

Instead of remembering the URL, you can get there via Admin -> Tickets -> Common. Other things under Admin -> Tickets may be interesting to you.

As for the possibility of building a web forum like thing on top of the ticketing system, sure, that could be done. The ticketing system is pretty flexible out of the box, and is scriptable if you need it to do things that the stock one can’t.

The biggest problem I have with all of that is that people don’t seem to be sharing their recipes here on the mailing list, so I suspect there’s a lot of wheel reinvention going on. Some months ago I published my humble recipes in an attempt to solicit other ideas, but got only one response:

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20773.html
Boruch Baum
2016-02-12 18:45:05 UTC
Permalink
Post by Warren Young
I see: <th1>combobox type $type_choices 1</th1> But I don't see how
to modify that.
http://localhost:8082/tktsetup_com
Instead of remembering the URL, you can get there via Admin ->
Tickets -> Common. Other things under Admin -> Tickets may be
interesting to you.
Perfect! At least, for now...
Post by Warren Young
The biggest problem I have with all of that is that people don’t seem
to be sharing their recipes here on the mailing list, so I suspect
there’s a lot of wheel reinvention going on. Some months ago I
published my humble recipes in an attempt to solicit other ideas, but
http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20773.html
Until something fossil-specific comes up, there's always .... smirk ...
github.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Warren Young
2016-02-12 18:58:37 UTC
Permalink
Post by Boruch Baum
Until something fossil-specific comes up, there's always .... smirk ...
github.
You get to choose your bag of problems:

1. Fossil, with no built-in web forum and no built-in way to send email on ticket submission, commits, etc. so that there is no communication between Fossil UI and the mailing list; or

2. Git. :)

I know which bag I want.
Yannick Duchêne
2016-02-12 21:11:52 UTC
Permalink
On Fri, 12 Feb 2016 11:24:05 -0700
Post by Warren Young
Email has its problems, but there’s an awful lot of antispam infrastructure around it that would have to be recreated to allow fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent protections.
But the issue from a user point of view, is near the same: you receive a lot of email on a mailing list, while on a forum, you just follow some threads. Opting-in and out does not really solve the issue, as opting-out means receiving nothing at all any‑more, so not possible to really reply, as no suitable mail to reply to. Also, I'm not sure it's possible to send a mail to mailing list when one has opted‑out (while I've not tested it).

Another alternative beside of forums, is news-groups. And there is a well known web interface for that, which is Google Groups, and it does not require self‑hosting.
--
Yannick Duchêne
Warren Young
2016-02-12 20:54:02 UTC
Permalink
Post by Yannick Duchêne
On Fri, 12 Feb 2016 11:24:05 -0700
Post by Warren Young
Email has its problems, but there’s an awful lot of antispam infrastructure around it that would have to be recreated to allow fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent protections.
But the issue from a user point of view, is near the same: you receive a lot of email on a mailing list
This list averages about 10 messages a day, and that’s including the occasional flame-fest, which you can entirely ignore if you like.

That’s “a lot”?
Post by Yannick Duchêne
while on a forum, you just follow some threads
I see that you’re using Claws Mail. From its features page: "'Ignore thread’ option”, and "Watch marked threads”. Thunderbird and other mailers have such features, too.

Those features aren’t universal, but simply having a thread-aware mailer makes ignoring unwanted threads straightforward. Just skip over threads whose title is uninteresting.

The other key email management practice is filtering messages into per-list folders, so you can choose where in your day you wish to spend time looking at the mailing list for each particular project. Every mailing list manager includes at least one tag in the email to make such filtering easy.

In this case, there are at least three such tags:

Subject: [fossil-users]…
To: fossil-users@…
List-Id: Fossil SCM user's discussion…
Post by Yannick Duchêne
opting-out means receiving nothing at all any‑more
Mailers with thread-kill features still download all the list traffic. They just send it to the bit bucket or otherwise hide it.

Once upon a time, people complained about the ISP costs associated with downloading unwanted email, but it’s lost in the noise in today’s typical IP traffic.
Post by Yannick Duchêne
I'm not sure it's possible to send a mail to mailing list when one has opted‑out
It isn’t possible, on purpose. That’s one of the anti-spam features associated with email: you’re forced to identify yourself in a way that lets the list manager cut you off if you’re determined to be a spammer. Anonymity is the root of much evil.

(Now, now, don’t get all civil libertarian on me. I’m down with anonymity in principle. It just isn’t appropriate for all…ahem, forums of discussion.)

Do you propose that Fossil reinvent distributed identity management, SPF, RBL, etc. just to keep spam out of these hypothetical web forums?
Post by Yannick Duchêne
Another alternative beside of forums, is news-groups. And there is a well known web interface for that, which is Google Groups, and it does not require self‑hosting.
That’s an acceptable solution if your only problem is that the communications don’t happen in a web browser. It doesn’t solve:

1. Isn’t built into Fossil. (Which is what I thought the original complaint was above.)

2. Doesn’t allow anonymous posting. (Need a Google account or an account with another Usenet provider. And the last time I used Usenet, that identifier was an email address anyway!)

3. Doesn’t let you ignore threads. (Other Usenet clients do, but then it isn’t in a browser again, which I suspect is the real problem a lot of people have with mailing lists.)

4. Isn’t the cool new spiffy, like the guy a week or so ago who wanted Fossil to move discussions to Telegram because shiny.
Barry Arthur
2016-02-12 23:59:34 UTC
Permalink
I was going to suggest an alternative approach being through enhancements
to chiselapp.com - but that is not any better than a mailing list if the
forum content is not stored inside the fossil repo for the associated
project, as was the desire of the OP, iiuc.

On the surface, it sounds appealing to have the project discussion stored
alongside the code in the same secure repository. That way a developer
cloning the repo would also have access to the discussion history too, with
the other obvious benefits as mentioned by the OP (understanding and
correct handling of artifact IDs, etc).

Non-developers cloning the repository might not appreciate having to
download years of project discussions, but:
* net is pretty fast these days and discussion would compress well in the
sqlite repo.
* PERHAPS the forum content could be optional when cloning

These concerns would be mitigated with the planned Fossil 2.0 feature of
allowing non-full repository clones.

As Warren says, contributing to the forum would require authentication.
Frustrating, but sadly a necessity.

Not having to hunt down and possibly register for a project's discussion
system -- it's built-in when you clone. Ok, for the authentication need
you'd still need some form of registration, but I haven't thought enough
about that (OpenID?). Not all projects use simple mailing lists and as
Warren pointed out in several posts recently, there are many flashy options
projects could choose from, each requiring their own unique log-in and user
interface and usage philosophy (mailing list vs forum, for example).

Given that Richard has expressed an interest in building his own email
server, maybe the chances of bundling a project's forum within its fossil
repository in the future exceed zero. :-)
Post by Warren Young
Post by Yannick Duchêne
On Fri, 12 Feb 2016 11:24:05 -0700
Email has its problems, but there’s an awful lot of antispam
infrastructure around it that would have to be recreated to allow
fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent
protections.
Post by Yannick Duchêne
But the issue from a user point of view, is near the same: you receive a
lot of email on a mailing list
This list averages about 10 messages a day, and that’s including the
occasional flame-fest, which you can entirely ignore if you like.
That’s “a lot”?
Post by Yannick Duchêne
while on a forum, you just follow some threads
I see that you’re using Claws Mail. From its features page: "'Ignore
thread’ option”, and "Watch marked threads”. Thunderbird and other mailers
have such features, too.
Those features aren’t universal, but simply having a thread-aware mailer
makes ignoring unwanted threads straightforward. Just skip over threads
whose title is uninteresting.
The other key email management practice is filtering messages into
per-list folders, so you can choose where in your day you wish to spend
time looking at the mailing list for each particular project. Every
mailing list manager includes at least one tag in the email to make such
filtering easy.
Subject: [fossil-users]

List-Id: Fossil SCM user's discussion

Post by Yannick Duchêne
opting-out means receiving nothing at all any‑more
Mailers with thread-kill features still download all the list traffic.
They just send it to the bit bucket or otherwise hide it.
Once upon a time, people complained about the ISP costs associated with
downloading unwanted email, but it’s lost in the noise in today’s typical
IP traffic.
Post by Yannick Duchêne
I'm not sure it's possible to send a mail to mailing list when one has
opted‑out
It isn’t possible, on purpose. That’s one of the anti-spam features
associated with email: you’re forced to identify yourself in a way that
lets the list manager cut you off if you’re determined to be a spammer.
Anonymity is the root of much evil.
(Now, now, don’t get all civil libertarian on me. I’m down with anonymity
in principle. It just isn’t appropriate for all
ahem, forums of
discussion.)
Do you propose that Fossil reinvent distributed identity management, SPF,
RBL, etc. just to keep spam out of these hypothetical web forums?
Post by Yannick Duchêne
Another alternative beside of forums, is news-groups. And there is a
well known web interface for that, which is Google Groups, and it does not
require self‑hosting.
That’s an acceptable solution if your only problem is that the
1. Isn’t built into Fossil. (Which is what I thought the original
complaint was above.)
2. Doesn’t allow anonymous posting. (Need a Google account or an account
with another Usenet provider. And the last time I used Usenet, that
identifier was an email address anyway!)
3. Doesn’t let you ignore threads. (Other Usenet clients do, but then it
isn’t in a browser again, which I suspect is the real problem a lot of
people have with mailing lists.)
4. Isn’t the cool new spiffy, like the guy a week or so ago who wanted
Fossil to move discussions to Telegram because shiny.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Boruch Baum
2016-02-14 01:12:01 UTC
Permalink
After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in email-list-style
discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been doing.
Post by Barry Arthur
I was going to suggest an alternative approach being through enhancements
to chiselapp.com - but that is not any better than a mailing list if the
forum content is not stored inside the fossil repo for the associated
project, as was the desire of the OP, iiuc.
On the surface, it sounds appealing to have the project discussion stored
alongside the code in the same secure repository. That way a developer
cloning the repo would also have access to the discussion history too, with
the other obvious benefits as mentioned by the OP (understanding and
correct handling of artifact IDs, etc).
Non-developers cloning the repository might not appreciate having to
* net is pretty fast these days and discussion would compress well in the
sqlite repo.
* PERHAPS the forum content could be optional when cloning
These concerns would be mitigated with the planned Fossil 2.0 feature of
allowing non-full repository clones.
As Warren says, contributing to the forum would require authentication.
Frustrating, but sadly a necessity.
Not having to hunt down and possibly register for a project's discussion
system -- it's built-in when you clone. Ok, for the authentication need
you'd still need some form of registration, but I haven't thought enough
about that (OpenID?). Not all projects use simple mailing lists and as
Warren pointed out in several posts recently, there are many flashy options
projects could choose from, each requiring their own unique log-in and user
interface and usage philosophy (mailing list vs forum, for example).
Given that Richard has expressed an interest in building his own email
server, maybe the chances of bundling a project's forum within its fossil
repository in the future exceed zero. :-)
Post by Warren Young
Post by Yannick Duchêne
On Fri, 12 Feb 2016 11:24:05 -0700
Post by Warren Young
Email has its problems, but there’s an awful lot of antispam
infrastructure around it that would have to be recreated to allow
fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent
protections.
Post by Yannick Duchêne
But the issue from a user point of view, is near the same: you receive a
lot of email on a mailing list
This list averages about 10 messages a day, and that’s including the
occasional flame-fest, which you can entirely ignore if you like.
That’s “a lot”?
Post by Yannick Duchêne
while on a forum, you just follow some threads
I see that you’re using Claws Mail. From its features page: "'Ignore
thread’ option”, and "Watch marked threads”. Thunderbird and other mailers
have such features, too.
Those features aren’t universal, but simply having a thread-aware mailer
makes ignoring unwanted threads straightforward. Just skip over threads
whose title is uninteresting.
The other key email management practice is filtering messages into
per-list folders, so you can choose where in your day you wish to spend
time looking at the mailing list for each particular project. Every
mailing list manager includes at least one tag in the email to make such
filtering easy.
Subject: [fossil-users]…
List-Id: Fossil SCM user's discussion…
Post by Yannick Duchêne
opting-out means receiving nothing at all any‑more
Mailers with thread-kill features still download all the list traffic.
They just send it to the bit bucket or otherwise hide it.
Once upon a time, people complained about the ISP costs associated with
downloading unwanted email, but it’s lost in the noise in today’s typical
IP traffic.
Post by Yannick Duchêne
I'm not sure it's possible to send a mail to mailing list when one has
opted‑out
It isn’t possible, on purpose. That’s one of the anti-spam features
associated with email: you’re forced to identify yourself in a way that
lets the list manager cut you off if you’re determined to be a spammer.
Anonymity is the root of much evil.
(Now, now, don’t get all civil libertarian on me. I’m down with anonymity
in principle. It just isn’t appropriate for all…ahem, forums of
discussion.)
Do you propose that Fossil reinvent distributed identity management, SPF,
RBL, etc. just to keep spam out of these hypothetical web forums?
Post by Yannick Duchêne
Another alternative beside of forums, is news-groups. And there is a
well known web interface for that, which is Google Groups, and it does not
require self‑hosting.
That’s an acceptable solution if your only problem is that the
1. Isn’t built into Fossil. (Which is what I thought the original
complaint was above.)
2. Doesn’t allow anonymous posting. (Need a Google account or an account
with another Usenet provider. And the last time I used Usenet, that
identifier was an email address anyway!)
3. Doesn’t let you ignore threads. (Other Usenet clients do, but then it
isn’t in a browser again, which I suspect is the real problem a lot of
people have with mailing lists.)
4. Isn’t the cool new spiffy, like the guy a week or so ago who wanted
Fossil to move discussions to Telegram because shiny.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
j. van den hoff
2016-02-14 11:22:00 UTC
Permalink
Post by Boruch Baum
After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in email-list-style
discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been doing.
after following this thread loosely these last 1-2 days, just a short
comment: you are proposing a "solution" for exactly which "problem"? I
don't see any and would support the conservative approach here, i.e. "if
it ain't broken, don't fix it": email does the job just fine for the
purpose of this list in my view. I don't see _any_ problem, let alone one,
that switching to some sort of forum would fix (quite to the contrary,
partly). I believe the arguments have been all mentioned already, mainly
by warren young. so what exactly are your remaining gripes with just
continuing to use the present channel of communication (except that it
seems somehow (technically or otherwise) uncool to you ;-)) for
discussions regarding fossil (which is the only purpose of this list...)?

regards,
joerg
Post by Boruch Baum
Post by Barry Arthur
I was going to suggest an alternative approach being through
enhancements
to chiselapp.com - but that is not any better than a mailing list if the
forum content is not stored inside the fossil repo for the associated
project, as was the desire of the OP, iiuc.
On the surface, it sounds appealing to have the project discussion stored
alongside the code in the same secure repository. That way a developer
cloning the repo would also have access to the discussion history too, with
the other obvious benefits as mentioned by the OP (understanding and
correct handling of artifact IDs, etc).
Non-developers cloning the repository might not appreciate having to
* net is pretty fast these days and discussion would compress well in the
sqlite repo.
* PERHAPS the forum content could be optional when cloning
These concerns would be mitigated with the planned Fossil 2.0 feature of
allowing non-full repository clones.
As Warren says, contributing to the forum would require authentication.
Frustrating, but sadly a necessity.
Not having to hunt down and possibly register for a project's discussion
system -- it's built-in when you clone. Ok, for the authentication need
you'd still need some form of registration, but I haven't thought enough
about that (OpenID?). Not all projects use simple mailing lists and as
Warren pointed out in several posts recently, there are many flashy options
projects could choose from, each requiring their own unique log-in and user
interface and usage philosophy (mailing list vs forum, for example).
Given that Richard has expressed an interest in building his own email
server, maybe the chances of bundling a project's forum within its fossil
repository in the future exceed zero. :-)
Post by Warren Young
Post by Yannick Duchêne
On Fri, 12 Feb 2016 11:24:05 -0700
Post by Warren Young
Email has its problems, but there’s an awful lot of antispam
infrastructure around it that would have to be recreated to allow
fossil-scm.org (or sqlite.org) to self-host a web forum with equivalent
protections.
Post by Yannick Duchêne
But the issue from a user point of view, is near the same: you receive a
lot of email on a mailing list
This list averages about 10 messages a day, and that’s including the
occasional flame-fest, which you can entirely ignore if you like.
That’s “a lot”?
Post by Yannick Duchêne
while on a forum, you just follow some threads
I see that you’re using Claws Mail. From its features page: "'Ignore
thread’ option”, and "Watch marked threads”. Thunderbird and other mailers
have such features, too.
Those features aren’t universal, but simply having a thread-aware mailer
makes ignoring unwanted threads straightforward. Just skip over threads
whose title is uninteresting.
The other key email management practice is filtering messages into
per-list folders, so you can choose where in your day you wish to spend
time looking at the mailing list for each particular project. Every
mailing list manager includes at least one tag in the email to make such
filtering easy.
Subject: [fossil-users]…
List-Id: Fossil SCM user's discussion…
Post by Yannick Duchêne
opting-out means receiving nothing at all any‑more
Mailers with thread-kill features still download all the list traffic.
They just send it to the bit bucket or otherwise hide it.
Once upon a time, people complained about the ISP costs associated with
downloading unwanted email, but it’s lost in the noise in today’s typical
IP traffic.
Post by Yannick Duchêne
I'm not sure it's possible to send a mail to mailing list when one has
opted‑out
It isn’t possible, on purpose. That’s one of the anti-spam features
associated with email: you’re forced to identify yourself in a way that
lets the list manager cut you off if you’re determined to be a spammer.
Anonymity is the root of much evil.
(Now, now, don’t get all civil libertarian on me. I’m down with anonymity
in principle. It just isn’t appropriate for all…ahem, forums of
discussion.)
Do you propose that Fossil reinvent distributed identity management, SPF,
RBL, etc. just to keep spam out of these hypothetical web forums?
Post by Yannick Duchêne
Another alternative beside of forums, is news-groups. And there is a
well known web interface for that, which is Google Groups, and it does not
require self‑hosting.
That’s an acceptable solution if your only problem is that the
1. Isn’t built into Fossil. (Which is what I thought the original
complaint was above.)
2. Doesn’t allow anonymous posting. (Need a Google account or an account
with another Usenet provider. And the last time I used Usenet, that
identifier was an email address anyway!)
3. Doesn’t let you ignore threads. (Other Usenet clients do, but then it
isn’t in a browser again, which I suspect is the real problem a lot of
people have with mailing lists.)
4. Isn’t the cool new spiffy, like the guy a week or so ago who wanted
Fossil to move discussions to Telegram because shiny.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Scott Robison
2016-02-14 12:10:49 UTC
Permalink
Post by j. van den hoff
Post by Boruch Baum
After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in email-list-style
discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been doing.
after following this thread loosely these last 1-2 days, just a short
comment: you are proposing a "solution" for exactly which "problem"? I
don't see any and would support the conservative approach here, i.e. "if it
ain't broken, don't fix it": email does the job just fine for the purpose
of this list in my view. I don't see _any_ problem, let alone one, that
switching to some sort of forum would fix (quite to the contrary, partly).
I believe the arguments have been all mentioned already, mainly by warren
young. so what exactly are your remaining gripes with just continuing to
use the present channel of communication (except that it seems somehow
(technically or otherwise) uncool to you ;-)) for discussions regarding
fossil (which is the only purpose of this list...)?


I was under the impression that it was more of a suggestion of something
the OP would like to use and less advocating for the fossil project to
embrace it.

That being said, I can see certain benefits to keeping "all" that
information around in the project repository itself. From the fossil design
Post by j. van den hoff
Fossil should provide in-depth historical and status information about
the project through a web interface
Post by j. van den hoff
{snip} Fossil attempts to better capture "collective intelligence" and
"the wisdom of crowds" {snip}
Post by j. van den hoff
The global state of a fossil repository is kept simple so that it can
endure in useful form for decades or centuries. A fossil repository is
intended to be readable, searchable, and extensible by people not yet born.

There is a lot of intelligence that goes into mailing lists that might not
be captured in the repository without extra effort.

Note that I'm not advocating for change, but part of me likes the idea.
More realistically there can be a lot of noise in forums and mailing lists
and such that you wouldn't necessarily want to keep in the fossil record,
much more so than changes to code or documentation.
j. van den hoff
2016-02-14 13:23:23 UTC
Permalink
On Sun, 14 Feb 2016 13:10:49 +0100, Scott Robison
Post by Boruch Baum
Post by j. van den hoff
Post by Boruch Baum
After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in
email-list-style
discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been
doing.
Post by j. van den hoff
after following this thread loosely these last 1-2 days, just a short
comment: you are proposing a "solution" for exactly which "problem"? I
don't see any and would support the conservative approach here, i.e. "if it
ain't broken, don't fix it": email does the job just fine for the purpose
of this list in my view. I don't see _any_ problem, let alone one, that
switching to some sort of forum would fix (quite to the contrary, partly).
I believe the arguments have been all mentioned already, mainly by warren
young. so what exactly are your remaining gripes with just continuing to
use the present channel of communication (except that it seems somehow
(technically or otherwise) uncool to you ;-)) for discussions regarding
fossil (which is the only purpose of this list...)?
I was under the impression that it was more of a suggestion of something
the OP would like to use and less advocating for the fossil project to
embrace it.
OK, than I've got than wrong. sorry for the noise.
Post by Boruch Baum
That being said, I can see certain benefits to keeping "all" that
information around in the project repository itself. From the fossil design
Post by j. van den hoff
Fossil should provide in-depth historical and status information about
the project through a web interface
Post by j. van den hoff
{snip} Fossil attempts to better capture "collective intelligence" and
"the wisdom of crowds" {snip}
Post by j. van den hoff
The global state of a fossil repository is kept simple so that it can
endure in useful form for decades or centuries. A fossil repository is
intended to be readable, searchable, and extensible by people not yet born.
of course all this seems to refer to the fact that one uses a revision
control system and has access to the commit logs (timeline), rather than
to putting lots of ephemeral stuff somehow into the repo as well, no?
Post by Boruch Baum
There is a lot of intelligence that goes into mailing lists that might not
be captured in the repository without extra effort.
the question seems, whether this would be worth the effort and what could
possibly be gained (in comparison to the present state: the project
documents itself through (hopefully comprehensive) commit messages and its
documentation and source code comments on the one side and there is a
mailing list plus its archive to look for help/additional information on
the other side).
Post by Boruch Baum
Note that I'm not advocating for change, but part of me likes the idea.
More realistically there can be a lot of noise in forums and mailing lists
+1 (my last mail possibly being one example ;-))
Post by Boruch Baum
and such that you wouldn't necessarily want to keep in the fossil record,
much more so than changes to code or documentation.
+1 again... there is such a thing as the signal to noise ratio which needs
to be kept sufficiently high.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Andy Bradford
2016-02-15 00:33:58 UTC
Permalink
Post by Scott Robison
There is a lot of intelligence that goes into mailing lists that might
not be captured in the repository without extra effort.
I don't think it would be much effort to subscribe an email address to a
mailing list that has a filter which take all email that it receives and
adds it as an artifact into a project.

$ cat ~/.qmail-project-bot
| bin/incorporate project

Of course, that could turn out to be a lot of files. And given that
``fossil commit'' supports --date-override it would even be possible to
place emails relative to the timeline retroactively if necesary.

As an interesting note, this mailing list has had almost 11,000 emails
since 2013-04.

Andy
--
TAI64 timestamp: 4000000056c11d19
Scott Robison
2016-02-15 01:28:06 UTC
Permalink
Post by Andy Bradford
Post by Scott Robison
There is a lot of intelligence that goes into mailing lists that might
not be captured in the repository without extra effort.
I don't think it would be much effort to subscribe an email address to a
mailing list that has a filter which take all email that it receives and
adds it as an artifact into a project.
$ cat ~/.qmail-project-bot
| bin/incorporate project
In this case the extra effort is relatively modest and automates what would
otherwise be a tedious manual process. :)
Andy Bradford
2016-02-15 02:07:09 UTC
Permalink
In this case the extra effort is relatively modest and automates what
would otherwise be a tedious manual process. :)
What might become tedious is figuring out how to search through the
content to find relevant information, but if one is simply trying to
correlate dicussions and commits through time, it might not be such a
big problem.

Andy
--
TAI64 timestamp: 4000000056c132f0
ksh: /home/amb/.signatur: not found
Warren Young
2016-02-15 04:11:10 UTC
Permalink
there can be a lot of noise in forums and mailing lists and such that you wouldn't necessarily want to keep in the fossil record, much more so than changes to code or documentation.
I wonder... If you knew that every post you made to the project forum would be sent to everyone who cloned that repository, would you be less likely to write off-topic posts, start flamewars, etc. than the purely social mechanisms we have today?

Email is seen as somewhat ephemeral, despite mail archives, Google, etc. There’s something more…official about committing changes to the project repo.

There are further upsides particular to a natural Fossil-ish implementation of this than just mimicking a classic web forum:

1. A moderator / project admin could shun spam, unwanted posts, etc. Because shunning is handled cooperatively between repos, the bogus inevitable cries of “censorship!” would be easier to dismiss.

2. If forum posts worked like wiki articles, you could edit posts after sending them. The ability to walk back in history would keep people from misusing this feature, evidenced by Stack Exchange, where edits are almost always improvements.

3. Markdown / wiki formatting.

4. You could sync your local clone of the project repo, get on a plane, and answer posts offline. When you get to your destination, you could sync back up, thereby posting your replies. Thus, you get a key benefit of email while still working on a web UI.
Boruch Baum
2016-02-14 12:46:35 UTC
Permalink
Post by j. van den hoff
Post by Boruch Baum
After Warren Young commented on the "flatness" of forum-style
discussions instead of the "threaded" viewing option in email-list-style
discussions, I realized that Wikipedia has had a solution that could be
easily implemented in Fossil projects without any software tweaking -
just create User:talk or Subject:talk pages, like Wikipedia has been doing.
after following this thread loosely
You're right - you've only been following the thread 'loosely'. My
question had nothing to do with the fossil-user mailing list. It was a
question about the lack of some form of forum in fossil itself, and for
me it's been a constructive discussion with two satisfactory suggestions.
Post by j. van den hoff
these last 1-2 days, just a short
comment: you are proposing a "solution" for exactly which "problem"? I
don't see any and would support the conservative approach here, i.e. "if
it ain't broken, don't fix it": email does the job just fine for the
purpose of this list in my view. I don't see _any_ problem, let alone
one, that switching to some sort of forum would fix (quite to the
contrary, partly). I believe the arguments have been all mentioned
already, mainly by warren young. so what exactly are your remaining
gripes with just continuing to use the present channel of communication
Had you been following the thread more than 'loosely', you would not be
characterizing anything about my posts as any form of gripe.
Post by j. van den hoff
(except that it seems somehow (technically or otherwise) uncool to you
;-)) for discussions regarding fossil (which is the only purpose of this
list...)?
regards,
joerg
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Andy Bradford
2016-02-13 06:13:35 UTC
Permalink
I'm not sure it's possible to send a mail to mailing list when one
has opted-out
It isn't possible, on purpose. That's one of the anti-spam features
associated with email: you're forced to identify yourself in a way
that lets the list manager cut you off if you're determined to be a
spammer.
Not entirely true of all mailing lists. There are many public mailing
lists which allow posting from unsubscribed addresses. Some of them do
require that the email address you send from be able to respond to a
challenge/response, but without requiring explicit subscription. Here's
one, for example:

http://marc.info/?t=145499927700002&r=1&w=2

I posted to that mailing list having never subscribed.

Not all mechanisms for identification necessarily imply subscription.
There may be some who simply don't want to deal with getting more email
than replies to their inquiries and mailing lists which allow this cater
to them.

Andy
--
TAI64 timestamp: 4000000056bec9b3
Yannick Duchêne
2016-02-12 21:03:44 UTC
Permalink
On Fri, 12 Feb 2016 12:33:52 -0500
Post by Boruch Baum
ׂGot it. Your answer made me think of the use of a forum as an
alternative to e-mail, and then I checked and see that a forum seems to
be the only thing missing from fossil.
I think the same about every mailing list. I wish it was a forum instead.
--
Yannick Duchêne
Yannick Duchêne
2016-02-12 21:06:07 UTC
Permalink
On Fri, 12 Feb 2016 10:50:40 -0500
Post by Richard Hipp
To clarify: We used to allow people to submit tickets anonymously.
But that feature was heavily misused, and in some cases abused, so we
turned it off. The policy now is that you have to bring up an issue
on the mailing list, and if it cannot be resolved there, then one of
the maintainers will create the ticket.
I hope it's not entirely my fault: I remember one or two years ago I submitted four tickets successively, and three of those were immediately deleted (the fourth one were kept).
--
Yannick Duchêne
Boruch Baum
2016-02-12 17:05:16 UTC
Permalink
Post by Boruch Baum
1] How can I keep more than project repository UI open on localhost
for web interfacing. In my case, the two of interest were my test
project and the fossil documentation project. It would seem a
reasonable and common request to have more than one project open.
Try: fossil ui from both trees. Fossil will dynamically select a
port, starting at 8080, and start the browser with the proper port
number.
That's what I orginally had tried, ie:
$ fossil ui ~/Downloads/fossil/fossil-scm &
$ fossil ui ~/Downloads/fossil/project1 &
and though the different instances were on unique ports (starting with
8081 in my case) and would open in unique browser tabs, each would close
the prior one's connection.

Does fossil have logging to look at for this kind of thing, or a diagnostic?

Aaaaannnnd . . . now it's not reproducible.

Would there be a log somewhere, maybe within the SQL database, to
document the problem?
Post by Boruch Baum
Does the project want to accept input from this mailin list?
Yes :).
Thanks.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Richard Hipp
2016-02-12 17:17:10 UTC
Permalink
Post by Boruch Baum
Aaaaannnnd . . . now it's not reproducible.
PEBKAC? ;-)

Another approach you might consider is to name all of your
repositories with *.fossil and put them all in the same directory.
Then you can do "fossil ui DIRECTORY" and the same instance of Fossil
will give you access to all the repositories.
--
D. Richard Hipp
***@sqlite.org
Boruch Baum
2016-02-12 18:04:27 UTC
Permalink
Post by Richard Hipp
Post by Boruch Baum
Aaaaannnnd . . . now it's not reproducible.
PEBKAC? ;-)
Be nice . . .
Post by Richard Hipp
Another approach you might consider is to name all of your
repositories with *.fossil and put them all in the same directory.
Then you can do "fossil ui DIRECTORY" and the same instance of Fossil
will give you access to all the repositories.
Now that's cool. I just tried it now, and also see Warren Young's great
reply, which is similar.

1] How would I tweak the content of that listing page?

2] This would be the place to tweak to have pages include a reference
back to the repository list?
http://localhost:8082/setup_skinedit?w=2

3] From Warren's response, I see that 'fossil --help' does not list an
option 'fossil help server', maybe because it shares its page with
'fossil ui', but it should have its own entry on that list.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Richard Hipp
2016-02-12 18:18:20 UTC
Permalink
Post by Boruch Baum
1] How would I tweak the content of that listing page?
It's hard-coded. See
https://www.fossil-scm.org/fossil/artifact/744f0089?ln=1532-1568

But if you really feel compelled to customize the listing screen, you
could probably add code that looks for a listing template file in the
home directory, then inserts the list of <li> entries at some
designated spot within that template, say the first line that contains
only "%%", with fallback to the current hard-coded look if no template
file is found.

See https://www.fossil-scm.org/fossil/doc/cd58f59a474c7ef773d1/www/contribute.wiki
for information on how to contribute features.

With everything else, the format of a page is governed by content in a
repository database. But in this case, there is no repository, so
there is no database to consult for formatting information.
Post by Boruch Baum
2] This would be the place to tweak to have pages include a reference
back to the repository list?
http://localhost:8082/setup_skinedit?w=2
The individual pages have no way of knowing whether or not a
repository list is available.
Post by Boruch Baum
3] From Warren's response, I see that 'fossil --help' does not list an
option 'fossil help server', maybe because it shares its page with
'fossil ui', but it should have its own entry on that list.
It shows up with "fossil help --all". We try to keep the number of
commands to a minimum for "fossil help" to avoid overwhelming people.
Obscure commands like "fossil server" are omitted with the -a or --all
option.
--
D. Richard Hipp
***@sqlite.org
Rolf Ade
2016-02-13 01:29:33 UTC
Permalink
Post by Richard Hipp
Post by Boruch Baum
1] How would I tweak the content of that listing page?
It's hard-coded. See
https://www.fossil-scm.org/fossil/artifact/744f0089?ln=1532-1568
Too sad. Not to say, it's a shame.
Warren Young
2016-02-12 17:22:31 UTC
Permalink
Post by Boruch Baum
Aaaaannnnd . . . now it's not reproducible.
I suspect you just didn’t properly background the first “fossil ui” command. Its browser window would stay open because HTTP doesn’t maintain a continuous connection to the back-end server.

You might prefer to use “fossil server” on a directory full of fossils rather than separate “fossil ui” commands. That allows a single fossil instance to serve many fossils, all on the same TCP port.

Here’s the fslsrv wrapper script I use:


#!/bin/sh
OLDPID=`pgrep fossil`
if [ -n "$OLDPID" ]
then
echo "Killing old Fossil instance (PID $OLDPID) first..."
kill $OLDPID
fi
fossil server -P 3691 /museum > /dev/null &
echo Fossil server running, PID $!.


Port 3691 is a local choice. I come from a Subversion background, so I picked it as svnserve+1.

/museum is where I store my fossils. Of course. In your case, you’d use ~/Downloads/fossil instead.


Once the Fossil server is running, you can visit both Fossils in parallel:

http://localhost:3691/fossil-scm
http://localhost:3691/project1
Post by Boruch Baum
Would there be a log somewhere, maybe within the SQL database, to
document the problem?
SQL database engines often default to no logging at all because that interferes with benchmarking. As far as I’m aware, SQLite adheres to this philosophy.
Boruch Baum
2016-02-12 18:12:32 UTC
Permalink
You might prefer to use “fossil server” on a directory full of
fossils rather than separate “fossil ui” commands. That allows a
single fossil instance to serve many fossils, all on the same TCP
port.
Thanks. It works great. And for the script too
SQL database engines often default to no logging at all because that
interferes with benchmarking. As far as I’m aware, SQLite adheres to
this philosophy.
Expediency and the elimination of the possibility of retrospection, as a
Philosophy. Welcome to progress.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Warren Young
2016-02-12 18:41:38 UTC
Permalink
Post by Boruch Baum
Post by Warren Young
SQL database engines often default to no logging at all because that
interferes with benchmarking. As far as I’m aware, SQLite adheres to
this philosophy.
Expediency and the elimination of the possibility of retrospection, as a
Philosophy. Welcome to progress.
Look at it from the SQL DBMS provider’s perspective.

In a world where DBMSes logged everything for later diagnosis, Phoronix, Ars, and such will install the DBMS packages in their default configuration, run a bunch of identical tests against all the DBMSes in their grand shootout — never accounting for their differing design philosophies — and publish pretty bar graphs. The engine with the longest bar wins.

Then the comment trolls come out and call all the DBMSes with the short bars “slow”, which Google indexes so that when you type “SQLite slow” into a search box, it points you to the Phoronix bar graphs — because Phoronix, Ars, etc. all have great Google juice — which feeds your confirmation bias that SQLite is slow.

I don’t want to live in that world.
Continue reading on narkive:
Loading...