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

[Jason Dagit]

On Mon, Mar 22, 2010 at 9:59 AM, Eric Kow <kowey at darcs.net> wrote:

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

I guess I would add to all of that, something we did in the past was to add
support for a new format now but do not enable it until much later.  This
can be attractive because then support for it could exist in something like
Debian Stable by the time it becomes the default.


> 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?
>

I don't know.  It just seems like the way things ought to be in the ideal
world.  What do you think?


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


I looked (and looked) but I can't find the thread in the archives anymore.
The argument I was given is that because repositories are tagged with their
capabilities and darcs format version that there is no need to version the
patch bundle.  Essentially it's that patches/bundles only exist in the
context of their repository.  Which is true.  I think in practice though,
sometimes people forget or loss track of those repositories and still want
to work with the patch bundle.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100322/e068adbe/attachment.htm>