We have had a few project suggestions already,...

One feature i'd love to see a GSoC student tackle is the ability to tag non-checkin artifacts. The architecture supports it just fine, but our CLI and UIs do not. Their task would be to (A) become familiar with the data model, then (B) extend the tag CLI command to accept non-checkin artifacts, then (C) identify and implement places in the UI (or in other CLI commands?) were we could make use of such tags.

e.g. the recent discussion of file xattrs on files has me wondering whether those could be implemented as tags applied to file blobs.

LibFossil projects

Here is the TODO for libfossil . These are very specific tasks, many of which are suitable for GSoC students.

Dan Shearer

Another GSoC feature suggestion:

There's currently no(?) easy way to diff versions of wiki pages unless they're only a single version removed. It might be interesting to expand the wiki history-browsing page to enable selection of 2 arbitrary versions to diff.

e.g.:

https://fossil-scm.org/home/whistory?name=To+Do+List

could be extended with clickable nodes for selecting 2 versions to diff, just like on the timeline page.

That looks like it would be a really easy thing to add, as the wiki-diff links already support passing 2 version IDs, so the only thing to add would be the UI for the clickable nodes and we have a working example of that in the timeline.

The timeline page itself should probably not be extended to add clickable nodes for wiki pages because that would necessarily introduce error handling for when a user select a wiki- and non-wiki node. Alternately, add such nodes to the timeline page, but when a non-wiki node is selected for the first version, disable all wiki nodes, and vice versa, so that only nodes of the same types (checkin vs wiki) can be manually selected.

All we need now is to write up a list of potential projects, and to collect the names of people interested in becoming mentors.

And it goes without saying that i'd be interested in mentoring, assuming my role as admin does not preclude that option.

And from there, forum post diffing. This would be especially useful to mods who have to approve both versions and need to quickly check that the edit doesn't slip something screwy in atop a presumably better-checked initial posting.

This has been tackled before. I still maintain a branch that implements just that. It is based on the old /whistory layout (before this check-in).
My Contributor's Agreement should be on file, so I would be happy to integrate it into mainline.

My Contributor's Agreement should be on file, so I would be happy to integrate it into mainline.

Your account doesn't currently have developer (checkin) privileges, so we'll need to ask Richard to confirm that your CA is on file. If he can confirm it, we'll activate your checkin bit and would be happy to see this integrated :).

I have George's CA, signed on 2019-10-30. The IP addresses he uses post content here are consistent with the postal address on his CA. The "george" account now has check-in privileges on the main Fossil repository.

Thanks for helping out, George!

Richard and Stephan, thank you!
The code of the wiki-history branch is now at the main repository. This has been accomplished with the help of the bundle command.

The repo-side JSON API has a JSON timeline. Bring the JSON timeline up to feature parity with the HTML timeline

Similarly, though it would require a far larger effort:

When the JSON API was implemented, sqlite did not have any JSON support of its own, so the API was based on my own C library. Now that sqlite has its own support for JSON, it might (or might not) make sense to reimplement the JSON API on top of that. Whether that's really feasible or not, in terms of whether feature parity can be matched that way, i'm not 100% certain, but assessing viability might be the initial part of the task.

The main advantage of doing so is that the JSON API could be considered "safe," and eventually be activated in the trunk by default. That it's not already enabled by default is entirely my fault: Richard told me, way back in late 2011 or early 2012, that if it had a full test suite, including fuzzy testing to test its resistance to malicious breakage, that it could be activated. His perfectly reasonable requirements have never been met, though.

So... that leads to an alternate idea, if a port to sqlite's JSON API isn't feasible for whatever reason: adding a full test suite, including fuzzy-input testing, to the current one. The effort involved there would definitely be far less than a port.

Who's going to solicit the students to work on Fossil?

Who's going to solicit the students to work on Fossil?

Dan (the OP) is our point-person for that type of thing, with support from a few more of us if/when he requires.

Who's going to solicit the students to work on Fossil?

Once we have a list in a file of suggestions (and there's more than enough here to write up such a file) then we can point students at them on the Fossil website. We then hope Fossil is selected as a participant by GSoC, which I think is likely but certainly not guaranteed.

After which:

• Google's GSoC team do a lot of promotion, pointing at their list of organisations students can browse. Here is last year's list. The text for this is pulled straight from the application, so if any of the GSoC admins don't like the words I've written, before this Friday 19th is a good time to go and improve them :-)
• Many colleges and universities around the world point their students at the GSoC list of orgs (and therefore list of potential tasks those orgs have available). That's a lot of advertising.
• We have at least one person here who is willing to promote Fossil as a GSoC participant to their university.

Regardless of GSoC status (that is, even if Fossil is not selected) the list of GSoC-ready tasks is something that I encourage anyone present to promote within their college and university circles. I certainly will be.

Dan Shearer

Instead of the reference to LMTP above, I will instead add a project to implement "fossil email -R repo receive_bounce" as per rouilj's suggestion .

A new project I've thought about for a while is to implement Fossil's embedded Markdown in Pandoc, which will require implementing Pikchr in a Pandoc filter.

I will now transfer this thread into a preliminary list of GSoC project suggestions.

• Editor integration: improve VSCode or create a Fossil plugin for Eclipse

There is a plugin for JetBrains products which doesn't work with the current API; it would be nice to see if somebody can create a modern working version for those IDEs (IDEA, PyCharm...).

This plugin works in VS Code.

That's helpful Daniel, VSCode seems to be enormously popular although I don't use it. Eclipse is ubiquitous in large companies, between them there would be a high percentage of developers worldwide I should think.

We don't have a document listing all known integrations. I would have been glad of a document like this at times.

Just quickly...

• people talk about Vim and Emacs scripts for Fossil, but I don't know that any are published and maintained.
• BuildBot
• Concourse CI
• Unmaintained Netbeans Plugin
• Unmaintained Jenkins CI adaptor

I'm sure there's more. There are potential GSoC projects in these.

There exists one plugin for Vim/Neovim, fork of vsccommand with added Fossil support: https://github.com/hdrz/vcscommand.vim

From my experience, it works, but it is limited. Also, probably should be considered as unmaintained.

For emacs I use:

https://chiselapp.com/user/venks/repository/emacs-fossil/timeline

last update 2021-01-01. The file has a quite a few todo items in it.