This list was made for the Fossil project's application for [Google Summer of Code](https://summerofcode.withgoogle.com/) in 2021. That application was
4
unsuccessful, but still this list is a starting point for anyone looking
5
for a place to start. We welcome newcomers, and invite developers to follow the simple
6
[procedures for contributing to Fossil](./contribute.wiki). The
7
[hacker how-to](./hacker-howto.wiki) is recommended reading.
8
9
There are two implementations of the Fossil data model:
10
11
* [the classic Fossil project](https://fossil-scm.org) , which is where this file is maintained and
12
which is as of 2021 how everyone interacts with Fossil objects
13
* [libfossil](https://fossil.wanderinghorse.net/r/libfossil), which is an independent project to manipulate Fossil objects from a library, or using commandline tools which are thin wrappers to the library
14
15
As of 2021 the two implementations have an identical implementation of the
16
Fossil data model, are 100% compatible in terms of data access since they use
17
the same SQL, and are 100% binary compatible in terms of on-disk storage.
18
19
The projects listed here are grouped by functionality - User Interface, Integration, Email,
20
etc. If you are looking for something easy to start with, then depending where
21
your interests lie, there are some small libfossil tasks and small
22
features to work on in the UI.
23
24
# UI, Look and Feel
25
26
Tasks for those interested in graphic/web design:
27
28
* Add a quote button to the Forum, such as [discussed in this thread](https://fossil-scm.org/forum/forumpost/7ad03cd73d)
29
* Improve the documentation history-browsing page to enable selection of 2 arbitrary versions to diff, similar to the [Mediawiki history feature enabled on Wikipedia](https://en.wikipedia.org/w/index.php?title=Fossil_\(software\)&action=history)
30
* Allow diffing of Forum posts
31
* General touch-ups in the existing skins. This may, depending on how deep one
32
cares to dig, require digging into C code to find, and potentially modify, how
33
the HTML is generated.
34
* Creation of one or more new skins. This does not specifically require any C
35
know-how.
36
* Complete per-feature CSS facilities in [the Inskinerator](https://tangentsoft.com/inskinerator/dir) and add features to the Inskinerator
37
38
# Projects Relating to Fossil Integration
39
40
* 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
41
* Create a [Pandoc](https://pandoc.org) filter that handles Fossil-style Markdown
42
* Create a [Pandoc filter that handles Pikchr](https://groups.google.com/g/pandoc-discuss/c/zZSspnHHsg0?pli=1) (Pikchr can be used with many kinds of layout, not just Markdown)
43
* Editor integration: [improve the Fossil VSCode plugin](https://marketplace.visualstudio.com/items?itemName=koog1000.fossil) or [create a Fossil plugin for Eclipse](https://marketplace.eclipse.org/taxonomy/term/26%2C31)
44
* 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
45
* 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
46
47
# Adding Inbound (Receiving) Email to Fossil
48
49
This task involves designing a new feature and working with Fossil developers to
50
see how it can be feasible in practice.
51
52
Fossil can [send email alerts](./alerts.md), but cannot receive email at all.
53
That is a good thing, because a complete [SMTP
54
MTA](https://en.wikipedia.org/wiki/MTA) is complicated and requires constant
55
maintenance, so Fossil should not try to be an MTA or ever listen to mail ports
56
on the Internet.
57
58
There is one specific type of email reception that make sense for Fossil to
59
handle. When there is inbound mail related to a message that Fossil has
60
previously generated with a unique hash, Fossil already knows the context of
61
that message. An unknown sender cannot guess a valid hash although a malicious
62
sender could of course find a way to receive a valid hash and then use that to
63
gain access. The risk of automatic and non-specific spam is very low.
64
65
A proposal to handle that would be to implement a Fossil command like this:
Where the type of email would be one of a list something like this:
72
73
* mail_bounce
74
* ticket_reply
75
* forum_reply
76
77
This command is a non-network-aware [Mail Delivery
78
Agent](https://en.wikipedia.org/wiki/Mail_delivery_agent), and would be called
79
by an SMTP MTA such as Postfix, Courier or Exim. The MTA would need to be
80
configured to recognise that this is an email intended for Fossil, and what
81
type of email, and to extract its hash. People who configure MTAs are used to
82
doing this sort of thing, but no doubt Fossil would include a sample
83
[Postfix mail filter](http://www.postfix.org/FILTER_README.html#simple_filter) and
84
an equivalent driver for Exim.
85
86
The Fossil command would reject anything that doesn't look like a bounce it is expecting.
87
88
It is not certain that this design is the best one to address the inbound mail
89
problem. That is why the first part of this task is to find a workable design.
90
91
# Work relating to the ticketing system in Fossil
92
93
The Fossil SCM project uses tickets in a [somewhat unusual manner](https://fossil-scm.org/home/reportlist)
94
because the social programming
95
model has evolved to often use the Forum instead of ticketing. Other Fossil-using projects
96
use tickets in a more traditional report-a-bug manner. So this means that the
97
Fossil ticketing system user interface is underdeveloped.
98
99
On the other hand, pretty much every software developer uses a ticketing system
100
at some point in their workflow, and Fossil is intended to be usable by most
101
developers. That means the ticketing system really needs to be further
102
developed. The underlying technology for the Fossil ticketing system is
103
guaranteed, so to improve it requires only user interface changes.
104
105
Projects relating to the ticketing system include:
106
107
* Improving the [Fossil cli for tickets](https://fossil-scm.org/forum/forumpost/d8e8a1cf92) which is confusing, as pointed out in that ticket. This is still classified as a "user interface" even though it isn't graphical.
108
* Alternatively, instead of improving Fossil's cli, implement a comprehensive ticket commandline with [libfossil's primitives](https://fossil.wanderinghorse.net/r/libfossil/wiki/home), look under the f-apps/ directory.
109
* Improving the Fossil web UI for ticketing, which is clunky to say the least. Fossil tries not be a heavy user of Javascript and Javascript libraries, but the wikiedit, chat and Forum code are all more advanced than ticketing,
110
and have UI features that would improve ticketing
111
* If there is an inbound email system as per the previous section "Adding Inbound (Receiving) Email to Fossil", then implement this system for ticketing
112
113
# Tasks Requiring Fossil Data Model Knowledge
114
115
The Fossil data model concepts are simple, but the implications are quite subtle and impressive. The data model
116
is designed to [endure for centuries](./fileformat.wiki),
117
be [easily accessible](./fossil-v-git.wiki#durable), and is [non-relational](./fossil-is-not-relational.md).
118
You will need to understand the data model to work on the following tasks:
119
120
* Add the ability to tag non-checkin artifacts, something supported by
121
the data model but not the current CLI and UIs. This would open the
122
door to numerous new features, such as "sticky" forum posts and
123
per-file extended attributes. This could also relate to the RBAC
124
system.
125
* Implement "merge" and "stash" in libfossil
126
* Analyse the different kinds of [split/export/shallow clone](https://fossil-scm.org/forum/forumpost/1aa4f8ea8c6f96) use cases for Fossil including [complete bifurcation](https://fossil-scm.org/forum/forumpost/6434a06871). 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
127
128
# Fossil is cool
129
130
There are many reasons why Fossil is just plain cool:
131
132
* Fossil is symbiotically connected with [SQL and SQLite](5631123d66d96)
133
* Fossil is highly portable accross different operating systems
134
* Fossil is the [only credible alternative to Git](./fossil-v-git.wiki)
135
* Fossil is both ultra-long-term stable and has a high rate of development and new features
136
* Fossil has thought deeply about Comp Sci principles including [CAP Theorem](./cap-theorem.md) and [whether Fossil is a blockchain](./blockchain.md)
137
* Fossil has two independent implementations of the same data model: Fossil and libfossil
138
139
and a lot, lot more, in the source, docs, forum and more.
140
141
142
143
144
``` pikchr center toggle
145
// Click to see the rendered diagram this describes,
146
// written in Fossil's built-in pikchr language, see https://pikchr.org