[Freedombox-discuss] Handling Projects Across Multiple Hosting Services

[Nick M. Daly]

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>