Project Ideas for Google Summer of Code 2021

This list was made for the Fossil project's application for Google Summer of Code in 2021. GSoC pays students to contribute to free software projects during the Northern Hemiphere summer. If you are a student, you will be able to apply for GSoC starting March 29th 2021.

This page applies to the two implementations of Fossil: the classic Fossil and libfossil. The two implementations have an identical implementation of the Fossil data model, are 100% compatible in terms of data access since they use the same SQL, and are 100% binary compatible in terms of on-disk storage.

General Features

• Improve the documentation history-browsing page to enable selection of 2 arbitrary versions to diff, similar to the Mediawiki history feature enabled on Wikipedia&action=history)
• Allow diffing of Forum posts
• Develop a test suite for the draft JSON API in libfossil. This JSON API is a way of integrating many kinds of systems with Fossil
• Re-implement the draft JSON API in libfossil to use the JSON capability in SQLite, now that SQLite has JSON. This is a large project and would start with feasibility analysis
• Fossil hooks for pipelines with CI/CD such as static analysis, Buildbot, Gerrit, Travis and Jenkins are not well-documented and may need some further development. Make this work better, with configuration examples
• Create a Pandoc filter that handles Fossil-style Markdown
• Create a Pandoc filter that handles Pikchr (Pikchr can be used with many kinds of layout, not just Markdown)
• Editor integration: improve the Fossil VSCode plugin or create a Fossil plugin for Eclipse

Adding Inbound (Receiving) Email to Fossil

This task involves designing a new feature and working with Fossil developers to see how it can be feasible in practice.

Fossil can send email alerts, but cannot receive email at all. That is a good thing, because a complete SMTP MTA is complicated and requires constant maintenance, so Fossil should not try to be an MTA or ever listen to mail ports on the Internet.

There is one specific type of email reception that make sense for Fossil to handle. When there is inbound mail related to a message that Fossil has previously generated with a unique hash, Fossil already knows the context of that message. An unknown sender cannot guess a valid hash although a malicious sender could of course find a way to receive a valid hash and then use that to gain access. The risk of automatic and non-specific spam is very low.

A proposal to handle that would be to implement a Fossil command like this:

fossil email -R repo receive -t TYPE-OF-EMAIL -h HASH

Where the type of email would be one of a list something like this:

• mail_bounce
• ticket_reply
• forum_reply

This command is a non-network-aware Mail Delivery Agent, and would be called by an SMTP MTA such as Postfix, Courier or Exim. The MTA would need to be configured to recognise that this is an email intended for Fossil, and what type of email, and to extract its hash. People who configure MTAs are used to doing this sort of thing, but no doubt Fossil would include a sample Postfix mail filter and an equivalent driver for Exim.

The Fossil command would reject anything that doesn't look like a bounce it is expecting.

It is not certain that this design is the best one to address the inbound mail problem. That is why the first part of this task is to find a workable design.

Work relating to the ticketing system in Fossil

The Fossil SCM project uses tickets in a somewhat unusual manner because the social programming model has evolved to often use the Fosum instead. Other Fossil-using projects use tickets in a more traditional report-a-bug manner. So this means that the Fossil ticketing system user interface is underdeveloped. On the other hand, pretty much every software developer uses a ticketing system at some point in their workflow, and Fossil is intended to be usable by most developers. The underlying technology for the Fossil ticketing system is guaranteed, so to improve it requires only user interface changes.

Projects relating to the ticketing system include:

• Improving the Fossil cli for tickets which is confusing, as pointed out in that ticket.
• Alternatively, instead of improving Fossil's cli, implement a comprehensive ticket commandline with libfossil's primitives, look under the f-apps/ directory.
• Improving the Fossil web UI for ticketing, which is clunky to say the least

Look and Feel

Tasks for those interested in graphic/web design:

• General touch-ups in the existing skins. This may, depending on how deep one cares to dig, require digging into C code to find, and potentially modify, how the HTML is generated.
• Creation of one or more new skins. This does not specifically require any C know-how.
• Complete per-feature CSS facilities in the Inskinerator and add features to the Inskinerator

Tasks Requiring Fossil Data Model Knowledge

The Fossil data model concepts are simple, but the implications are quite subtle and impressive. The data model is designed to endure for centuries, be easily accessible, and is non-relational. You will need to understand the data model to work on the following tasks:

• Add the ability to tag non-checkin artifacts, something supported by the data model but not the current CLI and UIs. This would open the door to numerous new features, such as "sticky" forum posts and per-file extended attributes. This could also relate to the RBAC system.
• Implement "merge" and "stash" in libfossil
• Analyse the different kinds of split/export/shallow clone use cases for Fossil including complete bifurcation. There are many proposals, relating to many different use cases, and a good analysis would help us to work out what should be implemented, and what should be implemented in Fossil and what is instead a libfossil wrapper

Fossil is cool

There are many reasons why Fossil is just plain cool:

• Fossil is symbiotically connected with SQL and SQLite
• Fossil is highly portable accross different operating systems
• Fossil is the only credible alternative to Git
• Fossil is both ultra-long-term stable and has a high rate of development and new features
• Fossil has thought deeply about Comp Sci principles including CAP Theorem and whether Fossil is a blockchain
• Fossil has two independent implementations of the same data model: Fossil and libfossil

and a lot, lot more, in the source, docs, forum and more.

// Click to see the rendered diagram this describes,
// written in Fossil's built-in pikchr language, see https://pikchr.org
// 
// based on pikchr script by Kees Nuyt, licensed
// https://creativecommons.org/licenses/by-nc-sa/4.0/

scale = 1.0
eh = 0.5cm
ew = 0.2cm
ed = 2 * eh
er = 0.4cm
lws = 4.0cm
lwm = lws + er
lwl = lwm + er

ellipse height eh width ew fill Bisque color CadetBlue 
L1: line width lwl from last ellipse.n
line "click for" bold above width lwm from last ellipse.s
LV: line height eh down

move right er down ed from last ellipse.n
ellipse height eh width ew fill Bisque color CadetBlue 
L3: line "example of Fossil" bold width lws right from last ellipse.n to LV.end then down eh right ew
line width lwm right from last ellipse.s then to LV.start

move right er down ed from last ellipse.n
ellipse height eh width ew fill Bisque color CadetBlue 
line width lwl right from last ellipse.n then to L1.end
line "coolness" bold width lwl right from last ellipse.s then up eh