Hi. OSLC-CM is a protocol that seeks to establish a standard for interoperability with Change Management servers, i.e. bugtrackers included. It would be great if debbugs was compatible with it, for instance so that it can be operated through Mylyn. For more details on OSLC-CM, see : http://open-services.net/bin/view/Main/CmHome Best regards,
tag 565513 moreinfo thanks I glanced at the website which contains the specification, and I have no clue what in particular you want me to implement for Debbugs. [FWICT, a large part of this specification isn't finalized, and its not clear if anything actually implements consumers of this specification.] You'll have to provide a lot more information or a link to a site which actually deals with the part of the specification and how it could apply to a bug server if you want me to look into it. Don Armstrong
Le samedi 16 janvier 2010 à 07:18 -0800, Don Armstrong a écrit : Well, the OSLC-CM V1 specification would be a good start ;) In short, it's a REST API allowing to submit, retrieve and change bugs. It's based on either JSON or XML (RDF and ATOM) for the transferred data. The main consumer to be available first is gonna be Eclipse's Mylyn task manager which allows to subscribe to bugtracker reports from inside Eclipse and manipulate them along the corresponding code. Mylyn's OSLC code is there but the end-user components are not released yet. I hope this is enough to get you started would you be interested : http://open-services.net/bin/view/Main/CmHome?sortcol=table;up=#1_0_Finalized Maybe I could also have a look at a free software set of "demo" servers that we're implementing for testing support of OSLC-CM on the server side for Mantis, FusionForge and maybe others in the future (PHP for now) at : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/WebHome The main advantage I can see for OSLC-CM is that tools like reportbug, bug-buddy, bts, bz, bts-link, mylyn or others could only implement on single standard instead of having to deal with various sorts of APIs once the bugtrackers have agreed to use this standard. In any case, it would probably be interesting if you had comments on OSLC-CM's way of providing a REST API for bugtrackers. Hope this fulfilled your moreinfo ;) Best regards,
It wasn't clear what part of the specification actually enabled you to do that. [Honestly, it's still not clear, because the specification isn't particularly well organized, nor does it have a very logical layout that.] Furthermore, we won't be supporting submitting or modifying bugs via any non-email API. [At least, not in the forseable future.] Unfortuatly, OSLC-CM doesn't appear anywhere near complete enough to handle the reports that reportbug, bts, et al. already deal with. Don Armstrong
Le dimanche 17 janvier 2010 à 00:08 -0800, Don Armstrong a écrit : I agree it's not very clear upfront. That may be questioned, but this is another topic of discussion. ACK. I'm not sure. OSLC-CM V1 only mandates some very basic fields of description of bugs, but it doesn't prevent to use extended (non-standard) attributes, making it a very basic common standard, still extensible for each tool's specific attributes. Anyway, thanks for your comments, and we'll eventually try and hack some code to demonstrate if/how debbugs may benefit from OSLC-CM ;) Regards,
tag 565513 help thanks That would be great! Code or a working demo always tells me more than a specification. Don Armstrong
Ciao Sandro. Le mercredi 28 juillet 2010 à 09:26 +0200, Sandro Tosi a écrit : That's what I thought I had done... using bts --mbox show 590269 but I was tricked by the automatic proposal to CC 590214 :-(... anyway, the principle is that both server (debbugs) and client (reportbug) should speak the same language, so that's not completely off-topic... it's just that the server is more concerned by interoperability with more clients probably. Thanks for fixing and CC-ing the proper debbugs one. In can understand your point as I've been myself working on bugtracker interoperability for years and only heard about OSLC-CM one year only after they had started to elaborate the process. The fact that you never heard of OSLC-CM is probably related to you not noticing my numerous posts about it ;), but more seriously, because it has mainly been elaborated by big proprietary vendors. Notice I haven't called it "more standard than SOAP". It's just that it has all properties of a good standard, i.e. a specs which propose some properties, and not just one instance of an API of a particular tool. But in any case, I think *if* one thinks about designing a new API, and REST is an option, then I would definitely *advise* to check OSLC-CM [0] instead of reinventing another wheel. If the properties of OSLC-CM don't fit, then... ok... but just because you ignore something doesn't dismiss it I guess... OK, then, now you know about it, if you don't like it, period. Sure. The point is just, with a (proposed) standard, the couple reportbug + debbugs may not be the only tools that can implement some connection between each-other, and adopting OSLC-CM may help foster interoperability with other tools that (will) speak OSLC-CM (like Mylyn). Sure, one has to implement something... and the rest is void... only, now, you are aware that OSLC-CM exists ;) My 2 cents, Best regards,