Hello, on Wednesday 25 May 2011 at 02:14, Ambrose Bonnaire-Sergeant wrote: > Judging by the below thread, I don't think something like this is likely to > be merged into core. > > http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/1457
Well, one might hope he has changed his mind since then. In case he hasn't, here are specific points in reply to his post. When proposing all the help I can provide, that include all that I can qualify as "hacking", what I do need however is design help, to have my library integration not swim against the tide of upstream evolution, and "interface points", i.e. where would be the best place in fossil code to interface with the library in order to have the least coupling (and therefore the most resistance to evolution). Having an upstream review after the fact, to ensure I did everything right, would be wonderful, but I'm afraid it's too much to ask. I'm also willing to handle the support of my library and its glue into fossil, for as long as I have a functional brain. However the manual chasing after fossil releases to merge new changes feels a bit like a waste of human time, especially if the design part is done right so that most of merges are without conflicts. > Thus this (probably) won't happen without an fork, which is undesirable. While I do think forking is acceptable to build a proof-of-concept, maintaining a fork for an indefinite amount of time, without any hope of making it to the official branch, really seems like a waste of efforts. Bummer indeed. Natacha
pgpjtqa1TITXq.pgp
Description: PGP signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
