[darcs-devel] FOSDEM summary

[Juliusz Chroboczek]

Hello to all,

FOSDEM was very interesting, with quite a few Darcs people being
around, especially much of the conflictors people.  A pity that Ian
and Tommy couldn't come, I'd have liked to meet them.

What follows is a summary of my notes; please do correct me if I'm
incomplete or incorrect about anything.

We first met on Saturday afternoon.  There was quite a bit of rather
technical conflictor discussion that was way over my head; my
impression is that conflictors are a difficult problem, but one that
is definitely worth working on.  As far as I could gather, the main
features are:

  - efficiency of conflictors should be much better, both in theory
    and in practice;
  - conflictors have better commutation properties than mergers, most
    notably in that (A A^{-1}) behaves just like the empty patch;
    however, mergers do *not* have all of the compositionality
    properties you'd like to have;
  - conflictors explicitly contain their ``effect'' (merger equivalent
    in the current terminology), which implies that everything other
    than commutation can reasonably be done without implementing all
    of Darcs (useful for CGIs that don't want to rely on Darcs being
    installed on the server).

Conflictors are a hard problem, but people seem optimistic.  My gut
instinct is that the concrete representation (apparently due to Arjan)
needs to be refined, but I really don't understand the issues.

We then had a somewhat unstructured discussion of more current
affairs, which was mostly repeated the next day, so I won't summarise
it here.

On Sunday morning, David gave a talk about GADTs and future plans for
Darcs, which I'll let him summarise.  Somebody asked a question about
the possibility to implement patch splitting (for unpulling part of a
patch from a repository).  Somebody asked whether GADTs are
multimethods.  (In case you care: no, they aren't.)  Somebody asked
about current events in the Darcs world, but David was starting to be
tired and didn't answer in much detail.  Somebody asked whether the
Git backend is a rumour.

David's talk was followed with a talk about Subversion.  Encouragingly
enough, the audience's reactions to this talk seem to imply that
people do understand the importance of distributed VC systems, or at
the very least systems that allow disconnected operation.

(Off-topic: this was followed with a talk about Valgrind, which I
warmly recommend to all C programmers.  If you program in C -- check
out valgrind!)

After the morning session, we met with a few so-called users.  I
arrived late, but I believe that they discussed Darcs' inefficiency
with binary patches, and how nice the new Darcs logo is (thanks, Mark!).
There were probably other complaints which I forget (I wasn't taking
notes).

We then walked for eight miles uphill in the freezing wind to a rather
nice Brasserie and had an extended discussion on current affairs.
This lasted four hours, and therefore the quality of my notes
deteriorates as I got more tired (the beer might have some effect here
too); please correct me if I misrepresent anything.

A feature that we definitely need is the ability to handle Unix
permissions internally to Darcs; the plan remains unchanged from what
we outlined on Darcs-devel a few weeks ago.  This is something that
Juliusz should probably implement.  Everyone complained about Juliusz
being a lazy bum.

Hashed inventories: new inventory format that contains a cryptographic
hash of the on-disk patch file.  While this will not protect from
corruption when pulling/pushing, it does protect from on-disk cor-
ruption and things like line endings getting fu^H^Hconverted.  A
transition plan was worked out and agreed upon.  Everyone complained
about Juliusz being a lazy bum.

End-to-end hashing: including cryptographic hashes of the patch in
minimal context in the patches themselves.  This is believed to
provide end-to-end protection, but verification will be somewhat
expensive (require some commuting).  This is more of a long-term
project, but is definitely worth doing.  It is somewhat tricky, and
should probably be implemented by one of David, Ganesh or Eric as far
as the patch-specific bits are concerned, and by Juliusz for the
hashing itself.

We then discussed GUI issues.  Eric described the built-in Darcs GUI
(Eric, any chance you could write your description up, and perhaps put
up some screenshots somewhere?).  David mentioned that someone needs
to bully someone into packaging wxHaskell for Debian.  Someone else
mentioned that Ian should do that, but someone said that Ian is busy
and really ought to be left in peace for the time being.

Juliusz suggested that we rip out all of the built-in GUI code, as it
makes Darcs maintenance more complicated than it would otherwise be,
especially since you cannot test the changes you're committing.  Eric
and David yelled at Juliusz.  Juliusz ordered more beer.  We arrived
at the compromise that the GUI code stays, but that anyone is allowed
to break the GUI for the time being, and Eric agreed to clean up any
GUI-related mess.

We then discussed an interface for external interactive interfaces
above Darcs, such as GUIs, vc-darcs.el and so on.  Ganesh and Juliusz
argued for a ``LL/SC''-style protocol (outlined by Juliusz on
darcs-devel a few weeks ago -- search for ``darcs batch'' in the
archives).  David disagreed, arguing for a simple interactive protocol
over a socket or pipe.  After some discussion, we agreed that the
simple interactive protocol is a more powerful and simpler solution.

Juliusz said that the lack of a Windows GUI for Darcs is a tragedy.
Somebody mentioned that the built-in GUI should work under Windows,
but Juliusz said that's not what he means by ``Windows GUI'', and that
Windows users like integration into the OS.  Everyone sniggered.
Somebody said this is just a chicken-and-egg problem, and will solve
itself when Darcs is more popular.

Someone (my notes don't say who, but I seem to recall it was at least
two people) requested the ability to record multiple patches
simultaneously, splitting changes interactively.  After some
discussion, people agreed that this would be a good idea, and Ganesh
volunteered to implement the necessary extensions to patch_select.

We then discussed planned changes to the patch format.  Somebody
mentioned that we now have the ability to carry out graceful
transitions thanks to David's RepoFormat module.  Everyone agreed that
Ian's proposed change to the format of ordinary hunks is a good idea,
and should be implemented ASAP as it's not difficult to do and should
provide significant performance gains.  (I don't recall if anyone
volunteered, but probably not -- I would have written it down.)

About binary patches.  Unfortunately, nobody present admitted to using
binary patches, but the reactions at David's talk clearly showed that
this is something people do care about.  We went through a few possible
designs.  Ganesh suggested we just keep the current format but without
hex conversion.  Juliusz suggested we allow the use of arbitrary
binary diff algorithms, but David worried about compatibility.  David
and Ganesh suggested a format that contains XORs of the old and new
contents, and David suggested that this could also contain offset
information, but Ganesh claimed David was being too ``clever''
(apparently a mild insult in British English).  We finally reached the
compromise that we'll accept the format suggested by David, but will
only generate patches that use 0 offsets for now, which will allow us
to move to David's idea in the future if David can prove it is useful.

David mentioned that Tommy is working on replace patches with embedded
spaces, which actually happens to work (unlike embedded newlines,
which break the universe).  Everyone agreed this is a goodness.

Finally, Juliusz described the issues he's having with Darcs-Git, and
how he expects to fix them.  David mildly implied that Juliusz is be-
ing silly, and told him how to do it right.  And there was much rejoicing.

                                        Juliusz