[Freedombox-discuss] Handling Projects Across Multiple Hosting Services
Nick M. Daly
nick.m.daly at gmail.com
Sun Mar 3 03:19:47 UTC 2013
Hi folks, what're your thoughts on managing issues and wikis across
repositories, between source hosting services?
For example, to encourage commits and to be system independent,
FreedomBuddy is hosted on both Github [0] and Gitorious [1]. These two
systems don't share wikis, much less issue trackers. That's problematic
and hardly "distributed" at all.
There're three obvious solutions to this issue:
1. Centralize everything to enforce a single source of truth.
2. Move the wiki and the issue tracker out of the meta-data and into the
repository's version controlled data.
3. Just accept a fragmented, incomplete view of the world and realize
that we'll never sync meta-data.
For FreedomBox projects, solution 1 sucks. In that case, we might as
well be using CVS and start selling Oracle servers as FreedomBoxes.
Also, solution 3 expresses a significant lack of imagination. So, we're
stuck with moving everything into the version-controlled repository
data. To solve this problem for FreedomBuddy, I wrote Publish [2].
Then, I found Fossil [3]. So, folks, which system should we use?
Fossil's Advantages
====================
- Fossil is just lovely.
- Everything (the issue, wiki, and version tracker) is automatically
integrated in its wonderful UI.
- Great, interactive, web-UI overviews of every supported meta-data type.
Publish's Advantages
====================
- Everything's a file. All the individual meta-data items you want to
track are files in the relevant directories. Want to refer to an
issue from the wiki? That's easy, just link to ../issues/theIssue.
- No special tools required to fiddle with meta-data: you don't need to
serve the system on the localhost just to edit a wiki page.
- Use any of 3 well loved markup languages to edit your issues and wiki:
ReStructured Text, MarkDown, and Org Mode.
- Hosting requires publishing one directory.
- Not tied to any version control system.
- Periodically rebuilds a full repository snapshot that, by default,
includes the repository's meta-data, making the archive an easily
downloadable checkout.
Fossil's Disadvantages
======================
- You need to use Fossil and publish a repository to interact with the
meta-data at all.
- ...YADVCS? (...Yet another distributed version control system?)
Maybe this one doesn't matter, because you do most important things
through the web UI anyway.
- "Downloading" a repository copy doesn't include the issues or wiki,
because they aren't checked in files. You need to clone the
repository through Fossil to get that data.
- The "markup language" is HTML. Writing HTML by hand sucks.
Publish's Disadvantages
=======================
- Publish is ugly as sin, and I know it.
- Not integrated: completing a parent issue won't complete the child
issues. Broken pointers are easy to miss and create the appearance of
a disused and unloved repository.
- The web UI is not interactive. Maybe this is an advantage, because it
adds zero attack surface area: the only way to change the repository
is to modify the files.
Conclusion
====================
For these use cases, I actually think Publish might win, because
*everything's a file.* Maybe I'm wrong, though, and maybe nobody cares
about that sort of legwork. Thus, this email.
Thoughts?
Nick
0: https://github.com/NickDaly/freedombuddy
1: https://gitorious.org/freedombuddy
2: https://gitorious.org/project-publish
3: https://www.fossil-scm.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130302/b874f021/attachment.pgp>
More information about the Freedombox-discuss
mailing list