summaryrefslogtreecommitdiff
path: root/www/gsoc-ideas.md
diff options
context:
space:
mode:
authorcashmere <cashmere@autistici.org>2026-09-04 09:05:24 +0200
committercashmere <cashmere@autistici.org>2026-09-04 09:05:24 +0200
commit4f49b16079b27d7ce633619e4cddfdf2bffbc952 (patch)
treec296c1e7f3c3e2f6859c6d3a1b1b208779b89679 /www/gsoc-ideas.md
downloadrelic-master.tar.gz
initial commitHEADmaster
Diffstat (limited to 'www/gsoc-ideas.md')
-rw-r--r--www/gsoc-ideas.md177
1 files changed, 177 insertions, 0 deletions
diff --git a/www/gsoc-ideas.md b/www/gsoc-ideas.md
new file mode 100644
index 0000000..5d14f1a
--- /dev/null
+++ b/www/gsoc-ideas.md
@@ -0,0 +1,177 @@
+# List of Projects and Tasks
+
+This list was made for the Fossil project's application for [Google Summer of Code](https://summerofcode.withgoogle.com/) in 2021. That application was
+unsuccessful, but still this list is a starting point for anyone looking
+for a place to start. We welcome newcomers, and invite developers to follow the simple
+[procedures for contributing to Fossil](./contribute.wiki). The
+[hacker how-to](./hacker-howto.wiki) is recommended reading.
+
+There are two implementations of the Fossil data model:
+
+* [the classic Fossil project](https://fossil-scm.org) , which is where this file is maintained and
+ which is as of 2021 how everyone interacts with Fossil objects
+* [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
+
+As of 2021 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.
+
+The projects listed here are grouped by functionality - User Interface, Integration, Email,
+etc. If you are looking for something easy to start with, then depending where
+your interests lie, there are some small libfossil tasks and small
+features to work on in the UI.
+
+# UI, Look and Feel
+
+Tasks for those interested in graphic/web design:
+
+* Add a quote button to the Forum, such as [discussed in this thread](https://fossil-scm.org/forum/forumpost/7ad03cd73d)
+* 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)
+* Allow diffing of Forum posts
+* 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](https://tangentsoft.com/inskinerator/dir) and add features to the Inskinerator
+
+# Projects Relating to Fossil Integration
+
+* 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](https://pandoc.org) filter that handles Fossil-style Markdown
+* 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)
+* 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)
+* 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
+
+# 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](./alerts.md), but cannot receive email at all.
+That is a good thing, because a complete [SMTP
+MTA](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/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](http://www.postfix.org/FILTER_README.html#simple_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](https://fossil-scm.org/home/reportlist)
+because the social programming
+model has evolved to often use the Forum instead of ticketing. 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. That means the ticketing system really needs to be further
+developed. 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](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.
+* 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.
+* 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,
+and have UI features that would improve ticketing
+* If there is an inbound email system as per the previous section "Adding Inbound (Receiving) Email to Fossil", then implement this system for ticketing
+
+# 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](./fileformat.wiki),
+be [easily accessible](./fossil-v-git.wiki#durable), and is [non-relational](./fossil-is-not-relational.md).
+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](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
+
+# Fossil is cool
+
+There are many reasons why Fossil is just plain cool:
+
+* Fossil is symbiotically connected with [SQL and SQLite](5631123d66d96)
+* Fossil is highly portable accross different operating systems
+* Fossil is the [only credible alternative to Git](./fossil-v-git.wiki)
+* 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](./cap-theorem.md) and [whether Fossil is a blockchain](./blockchain.md)
+* 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.
+
+
+
+
+``` pikchr center toggle
+// 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
+
+```
+
+