A read-only clone of the dehub project, for until dehub.dev can be brought back online.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
dehub/ROADMAP.md

92 lines
3.2 KiB

# Roadmap
This document describes currently planned features and events related to the
dehub project. It's intention is to help prioritize work. There are no dates
set, only a sequence of milestones and the requirements to hit them.
## Milestone: Publicize project
Must be able to feel good about showing the project publicly, as well as be able
to accept help from people asking to help.
* Figure out commit range syntax, use that everywhere.
* Tutorials
* Maybe move external host?
## Milestone: IPFS support
* Big ol' question mark on this one.
## Milestone: Versions
* Tag commits
* Add dehub version to the SPEC, make binary aware of it
* Figure out a release system?
force all commits to be ancestors of the root of main --- type: change message: |- force all commits to be ancestors of the root of main Without this commit it would be possible to just start branches willy-nilly on any dehub-remote, each with an independent config. Despite this obvious benefit, there's two significant problems which will need to be solved at a later date: - If an account is removed from the config, then that account will still be able to create and push branches based off commits older than that config change. This can be solved by adding a "checkpoint" flag to change commits, making them the new root. This would also enable hard-forks. - Currently there's no way to specify a custom branch name in lieu of "main". I don't know where this configuration would even go, so I don't know how to solve it atm. change_hash: ANc9dlX1IhMQcuSAAnsAoVWBg5v02mPwcoPn9LBOBAbL credentials: - type: pgp_signature pub_key_id: 95C46FA6A41148AC body: iQIzBAABAgAdFiEEJ6tQKp6olvZKJ0lwlcRvpqQRSKwFAl6KI08ACgkQlcRvpqQRSKwrBRAAt8u95nX/BYjgV4yFv/GQ69miWMidFqR84xAk4ZexiUct50Adf4O8fLpf0iIN1TWNItz3d3CM28h+N5+6ewbaM+zMhmiZ13xz4U/vxKyQ2f3LRpj5x8QdEjPEPzKXEIha+6TzBwYA3ijnRgksUKuDEB0tfgA0YDHeWxaVFSgi/F3Uupu1qphiKqytRI5XGimsVoMgI2CGk3RyzchYzLPJTPeHPocSPGT+FmSNk/hh58DGZ2oIfB4bV93xcW87O1RnwAlTNINp1Opsiq2vA7qKMTbqgDl47XaAgctmbpvVfPSbUhQn3MPkV62YvyA9Ft83ls80GNf4RoYQk5szBpTkCsoEaYGZ9xxTuxH6tuAviBR8aj7UZ5SA7FrxQLTe273971nIK1Ei8P6ms4s4Air0eN34GG7yVdhv692xfGDe2E0Td/PnsHx4el8CbK+pJ6O05o7uSU+855IlNPn8gaka1govfwKdn+AsDxKkk4jIakiYB03L3hDr/pGbu1Mm9hNPMDOegKwMfEmuEaQs6tGhYmkIVcFLxOxV/20JvwGWkmPUPFpNCfS9QfVfqhRS5hjJDQvaDDBtk5e8afEUahTSaqx1pqCMU1joFZT7HSrhsldnTiKBIjobrnuAHPi2Lp8EdoSN+Lgp5jqC2wPEpU72Sh9grINrcr8JE9mXDMuFygs= account: mediocregopher
4 years ago
## Milestone: Checkpoints
* Ability to set change commits as being a "checkpoint", so that they mark a new
root commit. A couple of considerations:
- Only a checkpoint on the main branch should be considered when determining
the project "root".
- Must be a flag on change commits, to allow hard-forks of projects where
the config file is completely replaced.
- Not sure if it should be subject to ACL or not.
## Milestone: Minimal plugin support
* SPEC and implement. Things which should be pluggable, initially:
* Conditions
* Signifiers
* Filters
* Commits???
## Milestone: Minimal notifications support
* Some way to store notification settings locally, and run a command which shows
a sequence of events since the last time you ran it.
* The command should keep a history of all of its outputs, and allow the
user to see that history (in case they run the command, then clear the
output by accident).
* The user should be able to specifically get notifications on threads
they're a part of, threads by branch name pattern, files by path pattern,
and keywords in commit messages.
# Misc Polish
These tasks aren't necessarily scheduled for any particular milestone, but they
are things that could use doing anyway.
* Config validation. Every interface used by the config should have a
`Validate() error` method, and Config itself should as well.
* Maybe coalesce the `accessctl`, `fs`, and `sigcred` packages back into the
root "dehub" package.
* Polish all error messages. A good error message has the following qualities:
* If wrapping an error which was returned from a sub-call:
* Uses `fmt.Errorf` with the `%w` format directive at the end.
* Phrased as if the sentence starts with the word "while", e.g. "opening
file: %w".
* Only includes information the caller of that function/method couldn't
already know.
* Polish commands
* New flag system, some kind of interactivity support (e.g. user doesn't
specify required argument, give them a prompt on the CLI to input it
rather than an error). This is partially done, in that a new flag system
has been started. Needs further work.
* Review flags:
* probably make some of them into positional arguments
* add flag shortcuts
* document everything better.
* POSIX compatible-ish flags?
* Possibly save state locally in order to speed things along, such as
"account id" which probably isn't going to change often for a user.
* More/better tests
* Commits need much better test coverage.