[darcs-users] patch metadata, annotations, Ignore-this, tagging, etc

[Eric Kow]

If I may wade into this...

On Fri, Mar 19, 2010 at 11:25:44 -0700, Jason Dagit wrote:
> [Moving this discussion out of the ticket because it's no longer converging
> on a resolution of the ticket at hand.]

Thanks for keeping the patch tracker easy to follow.

On Fri, Mar 19, 2010 at 10:30 AM, Max Battcher <me at worldmaker.net> wrote:
> > It's been discussed before that patches should have a real, reliably
> > extensible metadata format, rather than the quick hacks that are the
> > Ignore-This lines, which look stupid when you look at the real patch comment
> > and are very obviously a hack anytime you see a patch in the wild.
> >
> > Of course, that discussion gets derailed in the debate between coming up
> > with a new, better patch format in general or using the existing long
> > comments ala Ignore-This, but perhaps with a more, strictly standardized
> > MIME-like or email header-like approach. Of course any such approach will
> > break compatibility with one or more tools...

OK, if I may wade in and try to steer the discussion a little bit.

Briefly: we're stuck with Ignore-this for the short term; we may be
able to design something better but still backward-compatible for the
medium term; anything else will have to deferred to the long term.

Long/medium/short term
======================
Folks on IRC may have noticed that I've recently picked a habit of
defining Darcs development in terms of long/medium/short term...

Long term [Darcs 3]
-------------------
A new patch format in general may be interesting for the long term.
http://bugs.darcs.net/patch1096 appears to be a step in that direction.

Medium term [Polished Darcs 2]
------------------------------
I claim that this coming up with this new patch format is unrealistic
for the medium term (defined as post-performance-obsession and
pre-Darcs-3).  If we were to use anything better, it'd have to be
backwards-compatible (ie. using the patch long comment?)

Therefore, it would be interesting to determine if

1. If a new backwards compatible format will be useful in the medium
   term [which could last for many years mind you, if you also add in
   the short-term], or if we can get away with using Ignore-this for
   that time

2. If the new format could just start with "Ignore-this:"

3. What the new format would actually look like

We don't have to open this discussion now, but it's now being tracked as
a potential project in <http://bugs.darcs.net/issue1787>.  My request is
for whoever launches the third salvo in this discussion please research
the past threads (eg. when we introduced the Ignore-this salt for
issue27?) and link them here

There's also some very interesting future work on patch annotations
<http://bugs.darcs.net/issue1613> for optional metadata.  It may even
be medium-term if we're lucky.

Short term [Better Darcs 2]
---------------------------
In any case, future Darcsen are going to have to ignore 'Ignore-this: '
followed by some arbitrary string.

So I think we can safely continue to use this for new things in the
short term, particularly for patch167 and the important UTF-8 patch
metadata in the short term.  Let us not allow perfect to be the enemy of
good

Considerations on the problem
=============================

Jason Dagit wrote:

> Data about the patches (metadata), for example how to interpret their
> encoding, makes sense to be in a header context.  For that, MIME seems very
> reasonable to me.  It seems like MIME would work best for optional
> attributes that can be expressed in just a few lines.

Is this a long-term insight or a medium-term one?

> Then there are things like the current random bits that get attached to
> patches to make them more distinct.  That was added as an optional way to
> ensure that patches are distinct when they should be.  Optional in the sense
> that darcs needs to display them, but we didn't want to break compatibility
> with patches written by older darcsen.

This sounds like issue1613 to me.  I'm not tagging your paragraphs to be
annoying; just trying to make sure we're all on board on there being
distinct (and interesting!) discussions we could get into.

> It fixes an important bug with repository handling.  It's my belief that
> making that optional was the hack, not the Ignore-this.  It was the sort of
> hack that allowed us to respond to an important patch format change without
> creating too much headache.  So, I don't think the current use of
> Ignore-This is a good one, but we did fix our immediate need.

Short/medium/long term.  I think we're more or less in the same boat with the
UTF-8 metadata tagging.

> Thinking about things for the long term, I believe that we should have a
> patch and patch bundle format identifiers when transmitting them.

This would be http://bugs.darcs.net/issue1096

> I know there has been resistance to this in the past, but I think once
> we put that infrastructure in place it would pay for itself in time.

Looking at the thread, I think you were put off by the two replies to
this -- not well-defined and wishlist (not urgent) [David] and let's be
cautious about how we deal with patch formats [Eric], but IMHO, I would
not qualify these as resistance.

> Once we had the patch version information you could even imagine
> having an external tool that upgrades (or possibly downgrades) the
> data to a different version.  It still doesn't eradicate the headache
> of deploying the change, but I think it would give us a new ways to
> reduce much of it.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100322/95b7be30/attachment.pgp>