Re: [fossil-users] fossil - JIRA hooks
On Fri, Sep 12, 2014 at 6:19 PM, Ron W ronw.m...@gmail.com wrote: Nor does the JSON API need to handle things. Even the TH1 API doesn't handle things. It's the code using the API that does the handling Not if it comes to validation like length limits - that has to be done C-side. The only expectations of the JSON API would be to limit the length of strings delivered to the rest of Fossil and map queries/updates appropriately (see below). Any such limits cannot be imposed until the JSON is parsed in its entirety, though. The JSON DOM (so to say) gets parsed at a lower level, and then the Fossil side of that has to understand what those limits are and where to apply them. e.g. it must not apply them in the Wiki APIs, where pages can be arbitrarily long. To avoid buffer overflows. I would hope that the JSON API already does this. All buffers are allocated dynamically at a far deeper level (based on a parser written by Doug Crockford, if it's any consolation ;). Why are string length limits so important here - i don't get that part. What if someone wants to add a rough draft of your most recent novel field? Same as above, avoiding buffer overflows. If the API (and Fossil) can handle a string the size of Encyclopedia Galactica, that's great. If someone submits a legal JSON string of 2GB in length, it will get read in just like anything else. The length is not known in advance (other than the CONTENT_LENGTH CGI var, which (A) covers the whole input blob and (B) can be set to an arbitrary value by a malicious caller). The lowest level of the parser reads byte by byte (expanding its buffers as needed), and then hands the result of each atomic JSON value back up to the DOM-style API (which sits between fossil and the parser). In terms of memory use, it will take whatever it can get, but only allocates what it needs to handle the current element. The lowest-level push-parser has no mechanism to say, if a given element is larger than X, abort.[1] So yes, one can DoS it by simply feeding it absurdly massive JSON, but that's a potential problem any JSON-consuming application has, as the parsing of JSON request data is done at one (or more) level(s) removed from the app-level code. One can also potentially DoS fossil (and most other POST-reading apps) simply by POSTing arbitrarily large/meaningless form/urlencoded data. [1] one exception: the max nesting depth of objects/arrays is configurable, defaulting to 15 IIRC. i'll need to see an example before that's clear to me, i think. Can you compose some pseudo-json for such a request/response exchange? I guess something like: QUERY, // message type JiraId, 1234,// query fields and values , , // end of query *,// fields to include in response (in this case, all) // end of message Similar for NEW and UPDATE messages, except the second list of the just field names not needed. That's where my problem (per se) is: handling new/update with arbitrary/d field names is a huge pain in the butt in C. i'm completely open to assisting someone else in doing it, but this particular problem is not one i want to personally explore so long as there are much more fun things to be coding :). -- - 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] fossil - JIRA hooks
On Sat, Sep 13, 2014 at 4:29 AM, Stephan Beal sgb...@googlemail.com wrote: That's where my problem (per se) is: handling new/update with arbitrary/d field names is a huge pain in the butt in C. i'm completely open to assisting someone else in doing it, but this particular problem is not one i want to personally explore so long as there are much more fun things to be coding :). Well then, it'll have to be SQL via either Fossil CLI or libfossil (or DBD::SQLite). (There used to be libawk, but that project seems to have sunk below radar - or at least my patience for wading through search results. It was good for doing string handling in C.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Sat, Sep 13, 2014 at 11:07 AM, Ron W ronw.m...@gmail.com wrote: Well then, it'll have to be SQL via either Fossil CLI or libfossil (or DBD::SQLite). But it's still C - the columns have to be transformed from JSON to SQL in C. i admit - it's _not_ hard to do. All the pieces are there for iterating over the JSON fields and for easy generation of strings (including proper SQL escaping), it's just tedious, which means that in order to get me to do it, i need far more motivation. Trivia: fossil's Blob struct (which is how we create dynamic strings) showed me that C can be (almost) as easy to use as C++, and was what convinced me to give C another try after having abandoned it in 1995 in favour of higher-level languages. -- - 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] fossil - JIRA hooks
On Sat, Sep 13, 2014 at 5:25 AM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Sep 13, 2014 at 11:07 AM, Ron W ronw.m...@gmail.com wrote: Well then, it'll have to be SQL via either Fossil CLI or libfossil (or DBD::SQLite). it's just tedious, which means that in order to get me to do it, i need far more motivation. Was never asking you to do it. Now that I know the limitations of the JSON API, I know that best way to do it is either to wrap the CLI or use SQLite directly. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Sat, Sep 13, 2014 at 7:16 PM, Ron W ronw.m...@gmail.com wrote: Was never asking you to do it. No, i know - sorry if i implied otherwise. i did feel like you were trying to talk me into thinking about it, though ;). Some rainy day i might even feel inspired to ;). -- - 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] fossil - JIRA hooks
On Sat, Sep 13, 2014 at 1:22 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Sep 13, 2014 at 7:16 PM, Ron W ronw.m...@gmail.com wrote: Was never asking you to do it. No, i know - sorry if i implied otherwise. i did feel like you were trying to talk me into thinking about it, though ;). Some rainy day i might even feel inspired to ;). No problem. I appologise as well. I really only meant to illustrate how I might use the JSON API. I do know how hard handling strings in C is. In the past, I have used libawk. I might try to find another lib that provides similar functionality or even try to rebuild it (if I can find a copy of the source - not sure I still have a copy), but more likely I would use a language with built in string handling capability. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Sat, Sep 13, 2014 at 3:38 PM, Joseph R. Justice jayare...@gmail.com wrote: From some Google searching, it looks as if libawk *might* have been a part of the Gnu Arch (a.k.a. tla) version ... Ah, and I've found another source for GNU Arch, and libawk, at http://tla.sourcearchive.com/ . Thanks. I had done a little searching, but not as much as you did. I will look into these. Thanks again ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Thu, Sep 11, 2014 at 10:02 PM, Ron W ronw.m...@gmail.com wrote:
No different than my TH1 code being my responsibility to make sure it
handles my custom fields correctly.
handles is the operative word. TH1 can _handle_ things, and JSON, by
itself, cannot.
The only expectations of the JSON API would be to limit the length of
strings delivered to the rest of Fossil and map queries/updates
appropriately (see below).
Any such limits cannot be imposed until the JSON is parsed in its entirety,
though. The JSON DOM (so to say) gets parsed at a lower level, and then
the Fossil side of that has to understand what those limits are and where
to apply them. e.g. it must not apply them in the Wiki APIs, where pages
can be arbitrarily long.
What, like this?
[odroid@host:~/fossil/cwal]$ f json query -sql 'select count(*) from
user'
{
Is this possible through the web interface? If so, can it be disabled?
It's enabled for admin/setup users only (which also means any CLI use,
since Fossil treats CLI users as a superuser), and there is no mechanism
for disabling individual calls.
It just means that any app (or other library) using libfossil to access
tickets will have to be held responsible for using the custom fields
correctly. libfossil would only provide the means to access the tickets and
their fields. No validation beyond limiting string lengths. Nor any mapping
of queries or updates.
Why are string length limits so important here - i don't get that part.
What if someone wants to add a rough draft of your most recent novel
field?
(From above) By appropriate mapping, I suggest something like:
Query JSON message: Payload is 2 lists: One of name/value pairs
designating the fields to search and describing the values to match. The
other a list of fields to return in the results.
Update/Add JSON message: Payload is a list of name value pairs designating
the fields and their values.
The response could be either just a string containing the raw response,
or a list of name/value pairs.
i'll need to see an example before that's clear to me, i think. Can you
compose some pseudo-json for such a request/response exchange?
--
- 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 1:23 PM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote: Is it not possible to define an open-ended list of name-value pairs? Sure we can, but then we've got a data format nobody can predict, which doesn't sit well with me (at the API level). Projects A and B might both define the custom field foo and give them different semantics: one being a list and one being a free-form text field. The JSON API cannot know what semantics to apply to them, like it can with well-defined (non-custom) fields. As best I can determine, Fossil already demands that whomever adds custom fields take responsibility for the customized New Ticket, View Tick and Edit Ticket pages and associated TH1 apply the semantics correctly and consistently. More off-hand thinking: A new ticket from Jira (or other) would just be a new ticket request with accompanying field data, including the Jira ID. Which the JSON API has to then understand, and confirm that your customized fossil schema can deal with. That flexibility is a huge burden, in terms of implementation effort, for the JSON bits. Not impossible, just more effort than i ever felt like putting into it (because i so rarely use the ticket system). I think that the most the JSON API would not need to do more than to limit string lengths, map a JSON Query into a SQLite query and a JSON Update into a SQLite update. Then map the SQLite results into a suitable JSON response. For the query and update operations, I suggest the mapping only because it would limit what commands could be presented to SQLite. I would NOT expose Fossil to raw SQLite commands via any web interface. For the response, simply returning the raw SQLite response would be acceptable. Any integration that required more than this would allow should either interact with the Fossil CLI or use libfossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Thu, Sep 11, 2014 at 7:03 PM, Ron W ronw.m...@gmail.com wrote:
As best I can determine, Fossil already demands that whomever adds custom
fields take responsibility for the customized New Ticket, View Tick and
Edit Ticket pages and associated TH1 apply the semantics correctly and
consistently.
But the JSON API has no mechanism for the user to take over.
I think that the most the JSON API would not need to do more than to
limit string lengths, map a JSON Query into a SQLite query and a JSON
Update into a SQLite update. Then map the SQLite results into a suitable
JSON response.
That kind of thing is easy to do in a script language, but not much fun in
C :/.
For the query and update operations, I suggest the mapping only because it
would limit what commands could be presented to SQLite. I would NOT expose
Fossil to raw SQLite commands via any web interface.
What, like this?
[odroid@host:~/fossil/cwal]$ f json query -sql 'select count(*) from user'
{
fossil:d600c9f85421c0972231561560cb8410589c9606,
timestamp:1410455421,
command:query,
procTimeUs:5000,
procTimeMs:5,
payload:{
columns:[count(*)],
rows:[{count(*):5}]
},
g:{
...
(Reminder to self: bug: the 'g' object in the result should not be
happening without the flag which enables it. Aha... this is almost
certainly another signed vs unsigned char/overflow bug, as the odroid has
unsigned char.)
;)
Any integration that required more than this would allow should either
interact with the Fossil CLI or use libfossil.
So far i've been punting on the ticket problem in libfossil too because
of the tight connection between tickets and th1. i really don't want
libfossil to have _any_ built-in scripting language, because no language is
a perfect fit. Still not yet sure what's going to happen in that corner of
the code.
--
- 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] fossil - JIRA hooks
On Thu, Sep 11, 2014 at 1:14 PM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Sep 11, 2014 at 7:03 PM, Ron W ronw.m...@gmail.com wrote:
As best I can determine, Fossil already demands that whomever adds custom
fields take responsibility for the customized New Ticket, View Tick and
Edit Ticket pages and associated TH1 apply the semantics correctly and
consistently.
But the JSON API has no mechanism for the user to take over.
I do not expect the JSON API to have such a mechanism.
If I write a client program that uses the JSON API to access tickets in
Fossil, it is my responsibility to make sure my program handles my custom
fields correctly.
No different than my TH1 code being my responsibility to make sure it
handles my custom fields correctly.
The only expectations of the JSON API would be to limit the length of
strings delivered to the rest of Fossil and map queries/updates
appropriately (see below).
So, the JSON API would not need to know or care about correct use of the
custom fields. The client using the JSON API would be responsible for using
the custom fields correctly.
What, like this?
[odroid@host:~/fossil/cwal]$ f json query -sql 'select count(*) from user'
{
fossil:d600c9f85421c0972231561560cb8410589c9606,
timestamp:1410455421,
command:query,
procTimeUs:5000,
procTimeMs:5,
payload:{
columns:[count(*)],
rows:[{count(*):5}]
},
g:{
Is this possible through the web interface? If so, can it be disabled?
Any integration that required more than this would allow should either
interact with the Fossil CLI or use libfossil.
So far i've been punting on the ticket problem in libfossil too because
of the tight connection between tickets and th1. i really don't want
libfossil to have _any_ built-in scripting language, because no language is
a perfect fit. Still not yet sure what's going to happen in that corner of
the code.
It just means that any app (or other library) using libfossil to access
tickets will have to be held responsible for using the custom fields
correctly. libfossil would only provide the means to access the tickets and
their fields. No validation beyond limiting string lengths. Nor any mapping
of queries or updates.
(From above) By appropriate mapping, I suggest something like:
Query JSON message: Payload is 2 lists: One of name/value pairs designating
the fields to search and describing the values to match. The other a list
of fields to return in the results.
Update/Add JSON message: Payload is a list of name value pairs designating
the fields and their values.
The response could be either just a string containing the raw response,
or a list of name/value pairs.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil - JIRA hooks
Does anyone have any experience with hooking up fossil to JIRA? Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 9:26 AM, Eric Rubin-Smith eas@gmail.com wrote: Does anyone have any experience with hooking up fossil to JIRA? Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? My generic experience with the latter has been to either use pre and post commit hooks, or create a wrapper around the VCS, to interact with the issue tracking system. FWIW, I originally found Fossil while I was looking for an easy to use, easy to setup issue tracking system that would not require involvement of the IT people. That said, there have been times when it would be nice if I could setup Fossil to receive new tickets from an external system and send updates to those tickets back. I just haven't had the time to truly look into this. Off hand, it looks to me like this could reasonably be accomplished with some combination of the JSON API and the TCL integration. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 6:12 PM, Ron W ronw.m...@gmail.com wrote: like this could reasonably be accomplished with some combination of the JSON API and the TCL integration. And suggestions to either in order to make them usable for such purposes are of course welcomed. :) That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1 support might be (out of the box) more use in that area. (And i see no inherent reason why we couldn't generate JSON out of the those worlds, it just has never happened so far.) -- - 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] fossil - JIRA hooks
Ron W wrote: Does anyone have any experience with hooking up fossil to JIRA? Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? I guess I meant the former, though the latter is also interesting if it can be made as nice as Fossil's internal tracker (in the sense that it is easy to drill from the issue down to the check-ins addressing it). My generic experience with the latter has been to either use pre and post commit hooks, or create a wrapper around the VCS, to interact with the issue tracking system. FWIW, I originally found Fossil while I was looking for an easy to use, easy to setup issue tracking system that would not require involvement of the IT people. I'm in the middle of a debate about whether to use Fossil or git+JIRA. If I can hook Fossil up to JIRA then any points about the superiority of JIRA will experience significant erosion. As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? That said, there have been times when it would be nice if I could setup Fossil to receive new tickets from an external system and send updates to those tickets back. I just haven't had the time to truly look into this. Off hand, it looks to me like this could reasonably be accomplished with some combination of the JSON API and the TCL integration. I guess there are complexities around reconciliation with those simpler approaches. If the external system and Fossil are incommunicado for some period of time (during which they are diverging), then some process will need to have some way of determining the deltas on both sides and doing the sync. The TCL hooks will not suffice for that, unless you extend the scope of what you mean to encompass those full-sync semantics. (This is analogous to the thinking involved in implementing 'fossil sync'.) This in turn will have much to do with the vagaries how to get data into and out from the particular external bug tracker -- JIRA in my case. The tool appears to support a relatively featureful HTTP/REST/JSON API. I guess one of my questions is whether anyone has tried to bite off hooking up a fossil-jira feed using that API yet, whether they experienced any robustness problems or other gotchas in the JIRA API, etc. -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
Stephan Beal wrote: That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1 support might be (out of the box) more use in that area. (And i see no inherent reason why we couldn't generate JSON out of the those worlds, it just has never happened so far.) Okay interesting -- thanks for the response. Did you capture any more specific notes or code anywhere that you can point me to? -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? Sorry to self-reply. I meant for the sense of this question to be constrained specifically to the git-to-JIRA hooks or JIRA itself -- not to git as a stand-alone entity. Fossil devs'/users' criticisms of git in itself are pretty well documented on this forum and elsewhere, and my intention was not to rehash that thinking on this thread. Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 12:21 PM, Stephan Beal sgb...@googlemail.com wrote: That said: ticket integration with the JSON API turned out to be a lot more work than anticipated (and thus it is quite castrated) because of the customizability of the ticket subsystem and its close relationship to the scripting world. Thus, i suspect, the TCL/TH1 support might be (out of the box) more use in that area. (And i see no inherent reason why we couldn't generate JSON out of the those worlds, it just has never happened so far.) I'm rather out of date as to what information is available through the various hooks and under what circumstances. Some the messages on this list have only furthered my confusion. But given that an integration with an external issue tracker would, itself, have to be customisable, I am hoping that the JSON API can at least transport the custom fields. If it were also possible to query the descriptions/meta-data of the custom fields, that would be even better. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
Stephan Beal wrote: In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are of course welcomed, and if there's a concrete case you or Eric have in mind, i can probably say whether it's currently workable or estimate what it would take to make it so. If we assume for a moment that the user is willing to customize the Fossil ticket system to exactly match whatever is needed to integrate with JIRA, does the problem become easy overall? -- Eric A. Rubin-Smith Aterlo Networks, Inc. http://aterlo.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 6:44 PM, Eric Rubin-Smith eas@gmail.com wrote: If we assume for a moment that the user is willing to customize the Fossil ticket system to exactly match whatever is needed to integrate with JIRA, does the problem become easy overall? To answer that i'd need to know what Jira needs. My use of Jira has been limited to the end-user role - i have NO clue what data it likes to have for inputs. (That said, i quite like Jira, as far as ticket systems go. We get a surprising amount of utility out of the Confluence/Jira combo at my current customer's site.) -- - 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 6:35 PM, Ron W ronw.m...@gmail.com wrote: But given that an integration with an external issue tracker would, itself, have to be customisable, I am hoping that the JSON API can at least transport the custom fields. If it were also possible to query the descriptions/meta-data of the custom fields, that would be even better. In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are of course welcomed, and if there's a concrete case you or Eric have in mind, i can probably say whether it's currently workable or estimate what it would take to make it so. -- - 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] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 12:27 PM, Eric Rubin-Smith eas@gmail.com wrote: Ron W wrote: Do you mean automatic ticket sync between Fossil and an external issue tracking system? Or using an external issue tracking system instead of Fossil's? I guess I meant the former, though the latter is also interesting if it can be made as nice as Fossil's internal tracker (in the sense that it is easy to drill from the issue down to the check-ins addressing it). My impression of Jira is that it is designed to be able to integration with most any VCS. Since Fossil commits can be viewed via the web interface, then I would expect this to work nicely. FWIW, I originally found Fossil while I was looking for an easy to use, easy to setup issue tracking system that would not require involvement of the IT people. I'm in the middle of a debate about whether to use Fossil or git+JIRA. If I can hook Fossil up to JIRA then any points about the superiority of JIRA will experience significant erosion. This looks very possible to me. As a separate question along those lines, have people had other sorts of trouble (IT, data sanity or otherwise) with git+JIRA? Our (my team's) concern was/is that IT's ability to cater to the needs of our department are highly variable. IT had one person who was able and willing to handle the needs/wants of software developers (in our case, SW for non-PC devices). Then she moved to another company. They since hired 2 others in succession, each one moving on, only saying that the new offer was better. If we were to use Jira, that would be yet another service to run on IT's servers as the closest we have to a server in our department is the project manager's desk PC. And that is primarily for his convenience in managing issue tickets. Otherwise, we rely on syncing changes peer-to-peer. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 12:44 PM, Eric Rubin-Smith eas@gmail.com wrote: If we assume for a moment that the user is willing to customize the Fossil ticket system to exactly match whatever is needed to integrate with JIRA, does the problem become easy overall? As I understand it, Jira is also customizable, so that would mean 3 places to maintain customizations in sync. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 12:38 PM, Stephan Beal sgb...@googlemail.com wrote: In principal, plain old transport is not the problem. The problem (as i recall it, though it's been a while and i've got the memory of a goldfish) was that i could not define a concrete structure for JSON/Ticket I/O because tickets are customizable. Suggestions are of course welcomed, and if there's a concrete case you or Eric have in mind, i can probably say whether it's currently workable or estimate what it would take to make it so. Is it not possible to define an open-ended list of name-value pairs? More off-hand thinking: A new ticket from Jira (or other) would just be a new ticket request with accompanying field data, including the Jira ID. An update from Jira, I assume the intermediary would need to query Fossil based on the Jira ID, then use the returned Fossil ticket ID to send the updated field data. For updates from Fossil, would need to devise a way to discover the updated tickets (maybe the intermediary keeps track of when it gets updates then queries for tickets changes newer than the time stamp.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil - JIRA hooks
On Wed, Sep 10, 2014 at 7:04 PM, Ron W ronw.m...@gmail.com wrote: Is it not possible to define an open-ended list of name-value pairs? i've forgotten the English word (and maybe there isn't one): jein Sure we can, but then we've got a data format nobody can predict, which doesn't sit well with me (at the API level). Projects A and B might both define the custom field foo and give them different semantics: one being a list and one being a free-form text field. The JSON API cannot know what semantics to apply to them, like it can with well-defined (non-custom) fields. More off-hand thinking: A new ticket from Jira (or other) would just be a new ticket request with accompanying field data, including the Jira ID. Which the JSON API has to then understand, and confirm that your customized fossil schema can deal with. That flexibility is a huge burden, in terms of implementation effort, for the JSON bits. Not impossible, just more effort than i ever felt like putting into it (because i so rarely use the ticket system). -- - 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
