On Sat, Jul 26, 2014 at 10:53 AM, Eric Rubin-Smith <eas....@gmail.com> wrote:
> > * Export of tickets. > > If we want to move away from fossil to a git-based thing in the future, we > can export the source version history, though that is not as trivial as the > Fossil page on the matter makes it seem (see below). > > Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs > right from the SQLite database, massage them, and import them into JIRA (or > whatever tool). (In reality, it looks like JIRA supports JSON import, so > I'd probably wind up writing code to read the SQLite database and emit JSON > instead of CSV -- but whatever, similar idea.) I'm guessing this would be > like a 1-day project for a relatively large set of tickets. > > Furthermore, I'd need to massage all of the check-in comments themselves > in order to reference the new JIRA IDs for tickets rather than the Fossil > IDs. Is there a better story than this? > Is there a better story for moving between any two bug tracking systems? Do there exist any two bug tracking systems in the world were you can move from one to the other without having to write some scripts to transform the data? Fossil can give you the ticket data as SQL. I think that is probably about as portable as ticket data is going to get. You can use the "fossil sql" command to run ".dump" to get the ticket content and then load that content into *any* SQL database (MySQL, PostgreSQL, Oracle, SQL Server - name your poison) You will then have to transform the schema into whatever your target system expects. But I think that is always going to be the case, no? > > * Code review! > My major questions here are: > > (1) I know the fossil devs had considered writing a native proper code > review feature. Is that anywhere on the near-term road map? > We do low-ceremony code review on SQLite. Questionable changes go into a branch and then everybody beats on that branch to try to break it and/or find dodgy coding practices, until at some point (perhaps) we think it is ready to go on trunk, at which point it gets merged. There are no review forms to fill out and no records are kept, other than the merge history. For quicker changes, we run "fossil diff --tk" then use the "SaveAs" button on the GUI display to create a graphical diff file. We then send that graphical diff file to everybody on our private chatroom. Our homemade chat client recognizes the graphical diff files when they appear as an attachment in the dialog and gives us a button to click to bring up the GUI display. This make it easy for everybody to look over the diff and voice their opinions. Again, there are no forms to fill out and no records are kept, other than the chat logs. If you want more ceremony, you can certainly set up a system in Fossil where changes have to be tagged by the code reviewers, using a PGP-signed tag. That was my original concept for reviews, but not having a need for them, I never actually implemented it. We use more ceremony for testing. We have a (continuously evolving) checklist of tests that we have to work through for each release. See http://www.sqlite.org/checklists/ for a list of recent checklists. If you are a developer (and know the right passwords) you can click on these checklists to make changes, such as to record that a retest is running or to report that a test passed or failed. The checklist management software keeps track of all changes by timestamp, username, and IP address, and we save all that as part of the permanent record. It has been suggested that some kind of checklist facility like this be added to Fossil, but so far the checklist manager is a completely separate program. I find that using a checklist is better than completely automating the tests using something like Jenkins. It is good to keep a human in the loop. Often a test will "pass" but upon glancing at the output we realize something is wrong and needs to be fixed. Or maybe the test is just taking too long, suggesting a performance regression. Test automation is good. Many of the SQLite testing checklist items are highly automated tests that run literally for hours and perform tens of millions of individual test cases. But even with all this automation, it seems good to have actual humans monitoring the tests for unexpected behavior, and intervening as necessary, and the checklist facilitates that. The checklists also gives us an historical record of the testing, which becomes part of our "process documentation". > > (2) Are there 3rd-party code review tools that (a) are good and (b) > support fossil? > > (3) Are there clever work-flows using native fossil features that more > closely resemble proper code review tools than the sort of bad one that I > sketched above? > > Thanks! > Eric > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- 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
