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 <[email protected]> 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
pgpwxEgUfSk6q.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
