[fossil-users] Feature idea: Mailing lists / discussion forums
I know this is a bit I want a pony, but it occurs to me that the one thing Fossil lacks as everything you need to coordinate a software project in one little executable is a mailing list manager. I know we could fit a Web forum in there relatively easily (just, y'know, all the work producing a usable user interface and that). But I find web forums less usable than mailing lists :-) Adding an NNTP interface would be possible, by making it work like fossil server. People like me who run a lot of fossils from one server could run them on funny ports and have a master NNTP server peer with them all and presenting a public interface on the usual port. NNTP is cool, and would save us from having to write a user interface, but asking users to set up an NNTP client might be a stretch. An email discussion list is the de-facto standard for open source collaboration, and it would be possible to build one into Fossil - perhaps by giving it a post command that reads in an email from stdin so it can be hooked up to mail pipe, and sending emails out to a configured SMTP server. Mailing list subscriptions could be handled as part of the existing user database. No matter what interface to the discussions is available (or a combinatoin of the above), fossil ui/server could provide a browsable archive, and it'd be nice to be able to sync the discussion archive (although list admins might need to do a lot of shunning of spam). Integration with ticketing (newly created tickets go to a chosen mailing list, and replies to that message become comments on the ticket) would be nice, too. What do people think? I have a bunch of open source projects in fossil repos, and it's great that fossil handles the web hosting and ticket tracking and source control, but one of them is starting to need a mailing list, and it seems strange to have to set up a separate thing when everything else is built in! ...also, a fossil IRC bot that notifies the channel of new tickets and commits, and responds to ticket/commit IDs with a one-line summary would be nice too, but I can't have a pony AND a unicorn ;-) ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital 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] How to pull back from a git mirror?
+
How about to add a dot:
Index: src/export.c
==
--- /home/juef/fossil/e/fossil/src/export.c~0 2015-04-24 14:44:22.013432681
+0300
+++ /home/juef/fossil/e/fossil/src/export.c 2015-04-24 14:13:35.323413908
+0300
@@ -338,12 +338,14 @@
zTagname += 4;
zEncoded = mprintf(%s, zTagname);
for(i=0; zEncoded[i]; i++){
- if( !fossil_isalnum(zEncoded[i]) ) zEncoded[i] = '_';
+ if( !fossil_isalnum(zEncoded[i]) zEncoded[i] != '.' )
+zEncoded[i] = '_';
}
0.0.1 looks better than 0_0_1
(Tue, 21 Apr 12:32) Ron W:
# incremental import
fossil import --git --inc mirror.fossil secondexport
What am I missing ?
https://cloud.openmailbox.org/public.php?service=filest=a42e1dab28fe9574bca06dca77feb8fd
I made
initial:
git fast-export --all --export-marks=$new $export
cat $export | fossil import --git $fossilRepo
and then:
mv $new $old
git fast-export --all --import-marks=$old --export-marks=$new $export
cat $export | fossil import --git --incremental $fossilRepo
--
http://www.juef.tk/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] revised new ticket page
Hey guys,
This is a simple modification to the tktnew page (alpha code). I'd
appreciate any feedback.
God only knows if the embedded query is correct, but I think it works as a
proof of concept.
To try it out:
Make a copy of your repository (it just safer that way)
Serve it out (fossil serve --port 8080 reponame)
Log in as an admin
Click on the Admin menu item
Click on the Tickets item
Click on the New Ticket Page
Copy the following code into the code textarea
Click on the Apply Changes button
Create a new ticket and enjoy the new look
!-- START CODE --
th1
if {![info exists mutype]} {set mutype {[links only]}}
if {[info exists submit]} {
set status Open
if {$mutype eq HTML} {
set mimetype text/html
} elseif {$mutype eq Wiki} {
set mimetype text/x-fossil-wiki
} elseif {$mutype eq {[links only]}} {
set mimetype text/x-fossil-plain
} else {
set mimetype text/plain
}
submit_ticket
set preview 1
}
/th1
h1 style=text-align: center;Enter A New Ticket/h1
style
#ticket_entry{
line-height:40px;
}
.col1 {
display: inline-block;
width: 150px;
vertical-align: top;
font-weight:bold;
//background-color:wheat;
}
/style
div id='ticket_entry'
span class=col1Title:/span
input type=text name=title title=Single line summary of the ticket
size=60 value=$title /
br
span class=col1Type:/span
!--
th1combobox type $type_choices 1/th1
--
th1
for {set i 0} {$i [llength $type_choices]} {set i [expr {$i+1}]} {
if {$i == 0} { set ch checked } else { set ch }
set c [lindex $type_choices $i]
html input type='radio' name='type' value='$c'
$ch$c/inputnbsp;nbsp;
}
/th1
br
span class=col1Severity:/span
!--
th1combobox severity $severity_choices 1/th1
--
th1
for {set i 0} {$i [llength $severity_choices]} {set i [expr {$i+1}]} {
if {$i == 0} { set ch checked } else { set ch }
set c [lindex $severity_choices $i]
html input type='radio' name='severity' value='$c' $ch$c /input
}
/th1
br
!-- SLIDER
span class=col1Severity:/span
th1
set len [llength $severity_choices]
html input type='range' name='format' min=1 max=$len step=1 value='1'
style='width:400px;' oninput='showValue(event)'/span
id='sev_val'$len/span
/th1
br
--
span class=col1Found In:/span
input id='foundin_id' type=text name=foundin size=20
value=$foundin /nbsp;nbsp;
th1
query {
select distinct substr(tag.tagname,5) as xxx from event,tagxref, tag
where event.objid=tagxref.rid and
tag.tagid == tagxref.tagid and
event.type=ci and
tag.tagname like sym-%
order by event.mtime asc
limit 6
} {
html a
href='javascript:(function(){document.getElementById(\foundin_id\).value=\$xxx\;})()'$xxx/anbsp;nbsp;
}
/th1
br
span class=col1Email:/span
input type=text name=private_contact title=Contact information
size=60 value=$private_contact /
br
span class=col1Description:/span
th1set nline [linecount $comment 50 10]/th1
textarea name=icomment cols=80 rows=$nline wrap=virtual
class=wikiedit$icomment/textareabr /
span class=col1Description format:/span
input type='radio' name='mutype' value='Plain Text' checkedPlain
Text/input
input type='radio' name='mutype' value='links only'Links Only/input
input type='radio' name='mutype' value='HTML'HTML/input
input type='radio' name='mutype' value='Wiki'Wiki/input
br
br
br
th1enable_output [info exists preview]/th1
Description Preview:br /hr /
th1
if {$mutype eq Wiki} {
wiki $icomment
} elseif {$mutype eq Plain Text} {
set r [randhex]
wiki verbatim-$r[string trimright $icomment]\n/verbatim-$r
} elseif {$mutype eq {[links only]}} {
set r [randhex]
wiki verbatim-$r links[string trimright $icomment]\n/verbatim-$r
} else {
wiki nowiki$icomment\n/nowiki
}
/th1
th1enable_output 1/th1
input type=submit name=preview value=Preview /
th1enable_output [info exists preview]/th1
input type=submit name=submit value=Submit /
th1enable_output 1/th1
input type=submit name=cancel value=Cancel /
/div
!-- END CODE --
___
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] How to pull back from a git mirror?
(Fri, 24 Apr 12:30) Ron W: On Fri, Apr 24, 2015 at 8:26 AM, Svyatoslav Mishyn j...@openmailbox.org wrote: What am I missing ? https://cloud.openmailbox.org/public.php?service=filest=a42e1dab28fe9574bca06dca77feb8fd I made initial: git fast-export --all --export-marks=$new $export cat $export | fossil import --git $fossilRepo and then: mv $new $old git fast-export --all --import-marks=$old --export-marks=$new $export cat $export | fossil import --git --incremental $fossilRepo Have you done a round trip, Fossil = Git = Fossil ? Also, probably also Git = Fossil = Git as well. Yes, Why did `fossil import --incremental` create every time a new Leaf ? I know only commits are supported in Git, so I don't expect anything more than commits to survive the round trip. -- http://www.juef.tk/ ___ 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] Two trunks?
Thus said Ron W on Sat, 18 Apr 2015 14:19:16 -0400: As to merging, a branch-leaf is not automatically closed by merging it to anther branch, so why would merging automatically do anything to a fork-leaf to make it not a fork-leaf? Because a fork is only a fork if the branching happens in the same branch. Merging from a branch to a different branch does not cancel the branch, nor does it create a fork, and there is still a leaf on the branch against which checkins are allowed without any constraints, and a leaf in the other branch. With a fork, however, after you have merged it, there are no longer 2 leaves and attempts to checkin changes against either of the nodes that were merged will result in failure as it will create yet another fork. Only if --allow-fork is included will it be possible to checkin against a merged fork, but then, you have a new fork, not a continuation of a previous fork. Thanks, Andy -- TAI64 timestamp: 4000553adcf3 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] relative vs full path for external diff command
A new coworker opted to use Cygwin on her PC rather than have a second PC with Linux. The external gdiff command she configured is winmerge.exe - a Windows application. In the Cygwin command window, she did a fossil gdiff. Winmerge complained about /cygdrive/c/Projects/JL_PEPS_KVM/code/source/drv/s12xe_cw450/mcu_s12xe_init.c~0 not found. Would it be reasonable for Fossil to have a setting, or option in the diff/gdiff command setting, to indicate that relative paths should be supplied? As a workaround, I made a Perl wrapper for winmerge that replaces a leading /cygdrive/x with x:. while this works, it is an extra layer of indirection. ___ 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] Two trunks?
Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400: Proposed solutions include denying the ability to commit or push a fork. But doesn't that just make the problem worse? Yes, I think it does make it worse; this is not a practical approach in my opinion. I think it better to have the fork and receive a warning about it, or see it in the timeline than deny it. We've already established that users are in the habit of ignoring scary fork warnings. If they've seen them. They may not be seeing them due to infrastructure. E.g. User1 syncs to site1.dom and User2 syncs to site2.dom, where there is a 10 minute synchronization delay between site1.dom and site2.dom. If User1 and User2 checkin against the same leaf within that 10 minute window, currently neither will get a warning about forks. Other proposed changes include more frequent nagging about forks. The issue is less clear-cut, but I still worry that it might contribute to warning fatigue. I go by the motto that you should always distrust any computer program that thinks it knows more than you do. Constant nagging about forks seems to move Fossil in the direction of programs that I would not trust. This is not to say that there shouldn't be warnings, but there needs to be balance. I too was worried about warning fatigue. It should warn as little as possible. How to achieve that, while also providing more advanced warning to those who want it is a difficult challenge. I also am not fond of computer programs that behave as if they know more than I do; this is one of the reasons why I prefer Fossil over Git. :-) Regarding the balance for fork warnings, where there seems to be a high volume of forks, will additional notification help prevent the forks? Probably not because a fork is something that has already occurred, but it might help them be resolved more quickly as they will be detected sooner. Specifically, I'm talking about the kind of fork that happens silently that goes undetected for whatever reason. For a project where fork volume is low, will more notifications be a hindrance? I've sought to create a balance in the sync-forkwarn branch between the frequency of the nag and when to nag. For example, it will not nag on a clone---what's the point? It also won't nag if the artifact received is part of a fork previously existing in the clone (again, no need to nag continuously about a checkin against a fork that should already be known). But it will nag if you receive an artifact that has caused a new fork in your clone. The first person to generate a fork will be the one to get the first notification, and if they address it, no other people will be notified. Are these changes reasonable? Does it fit the parsimoniousness of Fossil? Or is it too much? How many forks in Fossil were done intentionally (e.g. with --allow-fork)? How many were unintentional and would have been resolved more quickly had a warning been issued at the time the fork was synchronized? Thanks, Andy -- TAI64 timestamp: 4000553ae819 ___ 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] Feature idea: Mailing lists / discussion forums
Hello, On 24 April 2015 at 03:51, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: I know this is a bit I want a pony, but it occurs to me that the one thing Fossil lacks as everything you need to coordinate a software project in one little executable is a mailing list manager. What do people think? I have a bunch of open source projects in fossil repos, and it's great that fossil handles the web hosting and ticket tracking and source control, but one of them is starting to need a mailing list, and it seems strange to have to set up a separate thing when everything else is built in! Just my opinion, but I'd rather have Fossil devs work on improving what fossil was designed for: code version control backed by sqlite. Related to what fossil does, there are already many enhancement requests that would keep devs busy: https://www.fossil-scm.org/index.html/rptview?rn=8 Also, the mailing list software I'm familiar with, mailman, is not BSD licensed and probably means it can't be incorporated very easily with fossil. That means this could be a solution: https://en.wikipedia.org/wiki/Ezmlm But your MTA will need to be qmail ...also, a fossil IRC bot that notifies the channel of new tickets and commits, and responds to ticket/commit IDs with a one-line summary would be nice too, but I can't have a pony AND a unicorn ;-) Well there's already an rss feed available on the timeline so this may be possible but you would need to write something up. https://www.fossil-scm.org/index.html/timeline.rss ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] Two trunks?
On Sat, 25 Apr 2015 03:03:50 +0200, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Richard Hipp on Sat, 18 Apr 2015 09:53:53 -0400: Proposed solutions include denying the ability to commit or push a fork. But doesn't that just make the problem worse? Yes, I think it does make it worse; this is not a practical approach in my opinion. I think it better to have the fork and receive a warning about it, or see it in the timeline than deny it. We've already established that users are in the habit of ignoring scary fork warnings. If they've seen them. They may not be seeing them due to infrastructure. E.g. User1 syncs to site1.dom and User2 syncs to site2.dom, where there is a 10 minute synchronization delay between site1.dom and site2.dom. If User1 and User2 checkin against the same leaf within that 10 minute window, currently neither will get a warning about forks. Other proposed changes include more frequent nagging about forks. The issue is less clear-cut, but I still worry that it might contribute to warning fatigue. I go by the motto that you should always distrust any computer program that thinks it knows more than you do. Constant nagging about forks seems to move Fossil in the direction of programs that I would not trust. This is not to say that there shouldn't be warnings, but there needs to be balance. I too was worried about warning fatigue. It should warn as little as possible. How to achieve that, while also providing more advanced warning to those who want it is a difficult challenge. I also am not fond of computer programs that behave as if they know more than I do; this is one of the reasons why I prefer Fossil over Git. :-) Regarding the balance for fork warnings, where there seems to be a high volume of forks, will additional notification help prevent the forks? Probably not because a fork is something that has already occurred, but it might help them be resolved more quickly as they will be detected sooner. Specifically, I'm talking about the kind of fork that happens silently that goes undetected for whatever reason. For a project where fork volume is low, will more notifications be a hindrance? I've sought to create a balance in the sync-forkwarn branch between the frequency of the nag and when to nag. For example, it will not nag on a clone---what's the point? It also won't nag if the artifact received is part of a fork previously existing in the clone (again, no need to nag continuously about a checkin against a fork that should already be known). But it will nag if you receive an artifact that has caused a new fork in your clone. The first person to generate a fork will be the one to get the first notification, and if they address it, no other people will be notified. Are these changes reasonable? Does it fit the parsimoniousness of Fossil? Or is it too much? How many forks in Fossil were done intentionally (e.g. with --allow-fork)? How many were unintentional and would have been resolved more quickly had a warning been issued at the time the fork was synchronized? I believe having these warnings would be good and would opt for making a field test whether it is well accepted or not in the fossil users community. regarding 'notification overload'. I always found and still find part of the regular fossil output to verbose. e.g. doing a `fossil up' when already in sync with the server (with autosync on) one gets 8 lines of output the only two being really relevant being the one confirming that pulling is under way and the 'changes' linen stating that nothing has changed. and probably the average user will not care how many artifacts have been sent or received but only would like to see some sort of progress feedback I presume. what I mean is: at a few places there might be a suboptimal signal to noise ratio in the default output and the relevant ones like failure to sync or detected forks should stand out sufficiently. another idea: maybe `fossil info' could also include a warning line if there are any forks at present? thx/j Thanks, Andy -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Feature idea: Mailing lists / discussion forums
On Fri, Apr 24, 2015 at 6:51 AM, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: I know we could fit a Web forum in there relatively easily (just, y'know, all the work producing a usable user interface and that). But I find web forums less usable than mailing lists :-) The technote feature already allows adding arbitrary tags, so it could be used as the underlying mechanism for a web forum. The tags could track threads. The potential technical problem with this is that the name of a technote is a time/date stamp, so possible for more than one technote with the same name. Wiki pages could also be used, but would need a way to navigate the wiki page's timeline. NNTP is cool, and would save us from having to write a user interface, but asking users to set up an NNTP client might be a stretch. I was under the impression that NNTP was deprecated and has been being phased out for several years, now. Maybe NNTP could be supported as a variant of the existing RSS feed with the addition of allowing posting discussion artifacts via NNTP. An email discussion list is the de-facto standard for open source collaboration (although list admins might need to do a lot of shunning of spam). I think that the various issues that mailing lists need to cope with (and have been dealt with to varying degrees by existing mail list managers) really make this too much to incorporate into Fossil ...also, a fossil IRC bot that notifies the channel of new tickets and commits, and responds to ticket/commit IDs with a one-line summary would be nice too, but I can't have a pony AND a unicorn ;-) If you have an IRC (or other IM) server that can accept messages via HTTP GET, then this could be done using a TH1 hook script that formats the message and sends an HTTP GET to the server. ___ 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] How to pull back from a git mirror?
On Fri, Apr 24, 2015 at 8:26 AM, Svyatoslav Mishyn j...@openmailbox.org wrote: What am I missing ? https://cloud.openmailbox.org/public.php?service=filest=a42e1dab28fe9574bca06dca77feb8fd I made initial: git fast-export --all --export-marks=$new $export cat $export | fossil import --git $fossilRepo and then: mv $new $old git fast-export --all --import-marks=$old --export-marks=$new $export cat $export | fossil import --git --incremental $fossilRepo Have you done a round trip, Fossil = Git = Fossil ? Also, probably also Git = Fossil = Git as well. I know only commits are supported in Git, so I don't expect anything more than commits to survive the round trip. ___ 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] revised new ticket page
(Fri, 24 Apr 14:21) Erik Lechak: Hey guys, This is a simple modification to the tktnew page (alpha code). I'd appreciate any feedback. Hi, looks nice! ;) -- http://www.juef.tk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
