[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.


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.



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