[fossil-users] Painful team interaction with fossil, how to improve?
Hi, I'm using fossil for a while now, and I'm quite happy with it, for the scm part and the web part. The problem is when going with the ticket part of fossil. I do not need something sophisticated, the the way the ticket works is ok with me, however the more the project I'm working on is growing the more painful it becomes to track ticket activity. In particular to interact with the submitter. I have found no way to: 1/ send a mail when new ticket is created (yes we can follow via rss feed, but a mail is way nicer) 2/ send a mail each time to ticket is modified to reporters and followers (No rss2email is not a solution: not flexible enough) The 2 above are really painful, and for the first time I really thinking about migrating from fossil to $something else for the project I do have the becomes popular :( The lacks of flexible hooks on server side is also a big problem to me, I can live with it, but the more I get people involve in the project I'm working on the more I'm missing it. What I do need on the hook side is: 1/ send a mail after each push of code with a diff: prior-push-tip/post-push-tip for each branch impacted to a given mailing list 2/ be able to get access to the diff and run random code on it and reject the push if not validated I would like to be able to do the above on top of fossil, how should I do? regards, Bapt ___ 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] Painful team interaction with fossil, how to improve?
On Thu, Feb 13, 2014 at 10:24 AM, Baptiste Daroussin baptiste.darous...@gmail.com wrote: In particular to interact with the submitter. I have found no way to: 1/ send a mail when new ticket is created (yes we can follow via rss feed, but a mail is way nicer) 2/ send a mail each time to ticket is modified to reporters and followers A ticket hook was added recently. I have not used it, so I don't know how it it works. The lacks of flexible hooks on server side is also a big problem to me What I do need on the hook side is: 1/ send a mail after each push of code with a diff: prior-push-tip/post-push-tip for each branch impacted to a given mailing list Why not just links to the commits? For example, http://fossil-scm.org/index.html/info/e327614047 appears to contain the information you are asking for. This is a lot to put in to an email message. 2/ be able to get access to the diff and run random code on it and reject the push if not validated Others on this list have set up automatic build servers. I don't think it would be hard to add validation functionality. May I ask what version control systems you have used before now? ___ 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] Painful team interaction with fossil, how to improve?
Hello. On Thu, Feb 13, 2014 at 04:24:39PM +0100, Baptiste Daroussin wrote: In particular to interact with the submitter. I have found no way to: 1/ send a mail when new ticket is created (yes we can follow via rss feed, but a mail is way nicer) 2/ send a mail each time to ticket is modified to reporters and followers (No rss2email is not a solution: not flexible enough) I wrote a Python script that helps myself deal with this. It looks at all tickets and emails all participants with all comments and changes since their last reaction. It also emails users specified in the responsible ticket field (which you can add in /tktsetup_tab), thus I can assign tickets to users and they get emailed without having to comment first. It also sends all changes to an email address specified in the FOSSIL_CC environment variable, for archiving purpose. I tried using the ticket hooks branch, but found it easier to just query the repository every 5 minutes with a cron job (also, this saves me from maintaining another web app that would handle the hook requests). I run the script on the same machine that Fossil databases are, so there are no performance or load issues. In case this sounds helpful, you can inspect the script here: http://code.umonkey.net/fossil-extras/file/tip/fossil-ticket-notify.py Or download it: http://code.umonkey.net/fossil-extras/raw-file/tip/fossil-ticket-notify.py Good luck. -- Justin Forest http://umonkey.net/ signature.asc Description: 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] looking for interesting new fossil skins
Hmmm I thought I could just do a fossil config pull skin to get these but that seems not to be sufficient. What are the steps to clone a skin? On Wed, Feb 12, 2014 at 12:40 AM, Baptiste Daroussin baptiste.darous...@gmail.com wrote: I have also stolen long ago the google code like theme and has adapted it a bit: - timeline is showing raw logs (because we do multiline commit logs - btw I can't get the cli timeline respecting multiline commits log :() - the tree view is default and has icons (stolen from openclipart as well) which makes it better integrated in the global theme) https://fossil.etoilebsd.net/poudriere regards, Bapt 2014-02-11 21:36 GMT+01:00 Stephan Beal sgb...@googlemail.com: On Tue, Feb 11, 2014 at 7:42 PM, Martijn Coppoolse li...@martijn.coppoolse.com wrote: Another one I liked is this one: http://projects.depar.is/divers/ It's based on GitHub's style, as the one above is based on Google Code's style. :-) Oooo, i like that one, too, but Google Code sits fonder in my memory than git-anything ;), so i'm sticking with the bluish one for now. Sidebar: i (re)discovered today that (fossil config export skin) exports the index-page setting and imports it on (fossil config import). index-page apparently cannot be set via the CLI, meaning that manual GUI intervention is needed when importing the config to a repo which has a different index page name (as most do). i find copying this option as part of the skin to be somewhat arguable (though a use case for it could certainly present itself)./Sidebar -- - 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 ___ 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] looking for interesting new fossil skins
On Thu, Feb 13, 2014 at 6:07 PM, Matt Welland estifo...@gmail.com wrote:
Hmmm I thought I could just do a fossil config pull skin to get
these but that seems not to be sufficient. What are the steps to clone a
skin?
conf pull skin pulls not only the CSS but also the index page name, so i've
reverted to this script for mass-injecting my preferred skin:
#!/bin/bash
fsrc=$1
fdest=$2
[[ -f $fsrc ]] [[ -f $fdest ]] || {
echo Usage: $0 SRC_REPO DEST_REPO 12
exit 1
}
cat EOF | sqlite3
ATTACH '$fsrc' AS src;
ATTACH '$fdest' AS dest;
REPLACE INTO dest.config(name,value)
SELECT name, value FROM src.config
WHERE name IN ('css','header','footer')
;
EOF
exit $?
--
- 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
___
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] Painful team interaction with fossil, how to improve?
I have used the ticket hooks and they do work. However they will not allow automatic updates to be sent to whoever logged the ticket. As a result I have moved the bug tracker to redmine. On 13 Feb 2014 16:25, Baptiste Daroussin baptiste.darous...@gmail.com wrote: Hi, I'm using fossil for a while now, and I'm quite happy with it, for the scm part and the web part. The problem is when going with the ticket part of fossil. I do not need something sophisticated, the the way the ticket works is ok with me, however the more the project I'm working on is growing the more painful it becomes to track ticket activity. In particular to interact with the submitter. I have found no way to: 1/ send a mail when new ticket is created (yes we can follow via rss feed, but a mail is way nicer) 2/ send a mail each time to ticket is modified to reporters and followers (No rss2email is not a solution: not flexible enough) The 2 above are really painful, and for the first time I really thinking about migrating from fossil to $something else for the project I do have the becomes popular :( The lacks of flexible hooks on server side is also a big problem to me, I can live with it, but the more I get people involve in the project I'm working on the more I'm missing it. What I do need on the hook side is: 1/ send a mail after each push of code with a diff: prior-push-tip/post-push-tip for each branch impacted to a given mailing list 2/ be able to get access to the diff and run random code on it and reject the push if not validated I would like to be able to do the above on top of fossil, how should I do? regards, Bapt ___ 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] Painful team interaction with fossil, how to improve?
On Thu, Feb 13, 2014 at 1:13 PM, Mark Janssen mpc.jans...@gmail.com wrote: I have used the ticket hooks and they do work. However they will not allow automatic updates to be sent to whoever logged the ticket. As a result I have moved the bug tracker to redmine. My impression, from reading comments on this email list, is that the hook sends the ticket UUID in an HTTP request, then the recipient fetches the details and forwards some of the details by whatever means. Assuming that the recipient of the ticket-hook notification is allowed access to the private_contact field, it could forward the notification to the ticket originator. Likewise, access to any assigned-to and/or subscribers fields would also be needed. ___ 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] looking for interesting new fossil skins
On Thu, Feb 13, 2014 at 12:09 PM, Stephan Beal sgb...@googlemail.comwrote: On Thu, Feb 13, 2014 at 6:07 PM, Matt Welland estifo...@gmail.com wrote: Hmmm I thought I could just do a fossil config pull skin to get these but that seems not to be sufficient. What are the steps to clone a skin? conf pull skin pulls not only the CSS but also the index page name, so i've reverted to this script for mass-injecting my preferred skin: Do we need to change config pull skin so that it omits the index page name? Or, maybe rig config pull skin so that it will accept a URL for a repository with a different project code, but only pull the index page name if the project code is the same? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] looking for interesting new fossil skins
On Thu, Feb 13, 2014 at 2:18 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Feb 13, 2014 at 7:52 PM, Richard Hipp d...@sqlite.org wrote: Do we need to change config pull skin so that it omits the index page name? i'd vote for that, or a flag for it. Huh. Apparently you can already do config pull css. What else other than the CSS file needs to be brought over to move a look from one repo to another? I don't think you necessarily want header and footer, since those can be customized to a project. (I know that I typically do customize headers and footers.) And you don't want to bring over the logo or background image or the ad unit setup. What else is there that is considered part of the portable skin? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] looking for interesting new fossil skins
On Thu, Feb 13, 2014 at 8:24 PM, Richard Hipp d...@sqlite.org wrote: Huh. Apparently you can already do config pull css. What else other than the CSS file needs to be brought over to move a look from one repo to another? Didn't know that. In my case i pulled (css,header,footer), but i don't know if that's generically the right thing to do. I don't think you necessarily want header and footer, since those can be customized to a project. (I know that I typically do customize headers and footers.) And you don't want to bring over the logo or background image or the ad unit setup. What else is there that is considered part of the portable skin? i always go imageless and adless, so those don't bother me, but yeah, they should probably be included in the skin. -- - 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 ___ 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] Painful team interaction with fossil, how to improve?
On 13 Feb 2014 19:44, Ron Wilson ronw.m...@gmail.com wrote: On Thu, Feb 13, 2014 at 1:13 PM, Mark Janssen mpc.jans...@gmail.com wrote: I have used the ticket hooks and they do work. However they will not allow automatic updates to be sent to whoever logged the ticket. As a result I have moved the bug tracker to redmine. My impression, from reading comments on this email list, is that the hook sends the ticket UUID in an HTTP request, then the recipient fetches the details and forwards some of the details by whatever means. Assuming that the recipient of the ticket-hook notification is allowed access to the private_contact field, it could forward the notification to the ticket originator. Likewise, access to any assigned-to and/or subscribers fields would also be needed. True with effort all of this could be retrieved from the underlying sqlite db. The reason I didn't do that is that you need opt out and email verification to prevent sending spam. I could add your email on every ticket and you would not be able to stop the notifications without admin interaction. Eventually you are really just rebuilding something like redmine. I really wanted to make it work, but in the end it just lacks too many features at the moment. ___ 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] Painful team interaction with fossil, how to improve?
On Thu, Feb 13, 2014 at 2:46 PM, Mark Janssen mpc.jans...@gmail.com wrote: True with effort all of this could be retrieved from the underlying sqlite db. The reason I didn't do that is that you need opt out and email verification to prevent sending spam. I could add your email on every ticket and you would not be able to stop the notifications without admin interaction. I had not considered that because, at work, everyone using Fossil is an employee of the company. For my personal projects, I don't have to worry about this. For the OSS projects I contribute to, I either send patch files or use github. (Mostly I send patch files.) Eventually you are really just rebuilding something like redmine. I really wanted to make it work, but in the end it just lacks too many features at the moment. I am curious what features are missing. ___ 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] Painful team interaction with fossil, how to improve?
On Thu, Feb 13, 2014 at 9:33 PM, Ron Wilson ronw.m...@gmail.com wrote: On Thu, Feb 13, 2014 at 2:46 PM, Mark Janssen mpc.jans...@gmail.comwrote: True with effort all of this could be retrieved from the underlying sqlite db. The reason I didn't do that is that you need opt out and email verification to prevent sending spam. I could add your email on every ticket and you would not be able to stop the notifications without admin interaction. I had not considered that because, at work, everyone using Fossil is an employee of the company. For my personal projects, I don't have to worry about this. For the OSS projects I contribute to, I either send patch files or use github. (Mostly I send patch files.) Indeed for personal projects and in company projects, what fossil already offers should suffice. Eventually you are really just rebuilding something like redmine. I really wanted to make it work, but in the end it just lacks too many features at the moment. I am curious what features are missing. Some things that come to mind: * Ticket notification for admin, logger and followers (this is the big one). * Email verification to prevent spam. * Ability to edit your own comments. The one thing that fossil gets absolutely right (and most other trackers don't) is the ability to log issues anonymously without becoming a spam trap. ___ 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] Painful team interaction with fossil, how to improve?
I set up our email notification to use a wiki page as the source for email addresses (creatively named emailnotification). Anyone who has read/write to the wiki can add or remove email addresses. This works fine for us so far but might not work for a open web facing project. On Thu, Feb 13, 2014 at 2:06 PM, Mark Janssen mpc.jans...@gmail.com wrote: On Thu, Feb 13, 2014 at 9:33 PM, Ron Wilson ronw.m...@gmail.com wrote: On Thu, Feb 13, 2014 at 2:46 PM, Mark Janssen mpc.jans...@gmail.comwrote: True with effort all of this could be retrieved from the underlying sqlite db. The reason I didn't do that is that you need opt out and email verification to prevent sending spam. I could add your email on every ticket and you would not be able to stop the notifications without admin interaction. I had not considered that because, at work, everyone using Fossil is an employee of the company. For my personal projects, I don't have to worry about this. For the OSS projects I contribute to, I either send patch files or use github. (Mostly I send patch files.) Indeed for personal projects and in company projects, what fossil already offers should suffice. Eventually you are really just rebuilding something like redmine. I really wanted to make it work, but in the end it just lacks too many features at the moment. I am curious what features are missing. Some things that come to mind: * Ticket notification for admin, logger and followers (this is the big one). * Email verification to prevent spam. * Ability to edit your own comments. The one thing that fossil gets absolutely right (and most other trackers don't) is the ability to log issues anonymously without becoming a spam trap. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Privilege separation between wiki and embedded documentation
Hello fossil users: I've been using fossil for some time now, and I'm really blown away by the versatility of the program. I have run into a problem recently however. I would like to be able to allow non-members to view the wiki for a project, but not the source code. At the same time, I wish to be able to put images in the wiki. Whenever I try to place an image in the wiki, I need to reference either a file path (/doc/tip/www/...) or an artifact id (/raw/0a8e5742056ccc69?m=image/jpeg). Referencing the image in either of these ways requires the Check-out privilege, which would also allow users to see the source code. For the moment, I am allowing the Nobody role to have checkout's, but I know that it is possible to click on the attachment name and see the artifact number. Clicking on the artifact number brings the user to the check-in, where they can then view all of the files in the source tree. I have changed the header to prevent Nobody from being able to access the time line or anything similar, but find this solution inconvenient. Does anyone have any ideas as to a better solution? Stephen ___ 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] Privilege separation between wiki and embedded documentation
On Thu, Feb 13, 2014 at 7:40 PM, Stephen Cripps 9...@queensu.ca wrote: Hello fossil users: I've been using fossil for some time now, and I'm really blown away by the versatility of the program. I have run into a problem recently however. I would like to be able to allow non-members to view the wiki for a project, but not the source code. At the same time, I wish to be able to put images in the wiki. Whenever I try to place an image in the wiki, I need to reference either a file path (/doc/tip/www/...) or an artifact id (/raw/0a8e5742056ccc69?m=image/jpeg). Referencing the image in either of these ways requires the Check-out privilege, which would also allow users to see the source code. For the moment, I am allowing the Nobody role to have checkout's, but I know that it is possible to click on the attachment name and see the artifact number. Clicking on the artifact number brings the user to the check-in, where they can then view all of the files in the source tree. I have changed the header to prevent Nobody from being able to access the time line or anything similar, but find this solution inconvenient. Does anyone have any ideas as to a better solution? (1) You can put your images as attachments on the wiki pages. Then reference the attachments in the text of the wiki page. I don't remember the details of how that works, but I vaguely remember adding code to make it work back in (approximately) 2007 or 2008. (2) Maybe put your images in a specific subdirectory of your code (say images/) and then grant user nobody permission to see only that one subdirectory. Under the Admin/Access menu you will find the Public Pages entry box, that lets you specify a comma-separate list of glob patterns for URLs that will be accessible by nobody regardless of normal permissions. You can add the glob pattern /doc/trunk/images/* to that entry box. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Painful team interaction with fossil, how to improve?
On Thu, Feb 13, 2014 at 4:06 PM, Mark Janssen mpc.jans...@gmail.com wrote: Some things that come to mind: * Ticket notification for admin, logger and followers (this is the big one). * Email verification to prevent spam. I can think of ways of using a list server to mostly handle these 2 items. * Ability to edit your own comments. It might be possible to do this by modifying the edit ticket page. ___ 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] Painful team interaction with fossil, how to improve?
Thus said Mark Janssen on Thu, 13 Feb 2014 22:06:49 +0100: * Email verification to prevent spam. MLMs (mailing list managers; like ezmlm, mailman, etc...) already solve this problem. Perhaps those who want notifications can subscribe to a tic...@domain.dom mailing list and the ticket hook can send messagse to the mailing list, instead of individuals. Andy -- TAI64 timestamp: 400052fd8a40 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
