On Tue, Mar 30, 2010 at 21:07:07 +0000, Ganesh Sittampalam wrote:
> I'm not sure if this feature technically ought to have "grumpy old 
> man" review, but it's been visible (and an open bug request) for a 
> while, and in my humble opinion would easily pass the review anyway 
> because it's a simple and obvious enhancement to an existing 
> command that fits in with it nicely.

Let's go!  http://wiki.darcs.net/Ideas

WARNING: I haven't been following the review well enough to know if I
understand what bisect does exactly, in UI terms.  So I'm guessing below
that it behaves like darcs trackdown would only faster.

1. What problem does the proposed feature solve?

   EYK: Efficiently identifying a set of patches in the repository which
   cause a test to pass (or was it fail?).  We currently have plain old
   darcs trackdown, but it only works one patch a time, which makes it
   rather painful.  Trackdown --bisect would presumably be a lot faster.

2. What are the user stories?

   EYK: A typical scenario may be that a user submits a bug report for
   frobnicator which *appears* to be a regression, but where?  Somebody
   in the frobnicator team could write a formal test case for this bug
   and run darcs trackdown --bisect "./run-test-case
   frimp-switching-xy".

   In doing so, they would find out that the latest version of the
   repository in which the frimp-switching-xy test case passes
   contains the patches up to 2010-03-11 "Tweak identation in woffle
   module".  Therefore, the next patch up, "Refactor frimp processing"
   is the culprit.

3. Does this change any pre-existing workflows? Does this introduce any
   incompatibilities?

   EYK: My current best guess is that it works exactly as darcs
   trackdown would without any switches.  Is that correct?


4. How do we preserve the conceptual integrity of Darcs? Is the UI for
   this feature really Darcs-ish?

   EYK: This switch does not require you to learn any new concepts; it's
   just a variant of trackdown as far as I can tell.

   On the other hand, one thing I would be worried about is the little
   edge details like what exactly trackdown --bisect tells you.  Is it
   the same exact thing as trackdown [the longest sequence of passing
   patches in the order of your repository? next after the sequence being
   the bad guy].  Should it be?

   Also, could we even take a step further and pro-actively enhance the
   user interface by renaming darcs trackdown to darcs test.  The idea
   then is that darcs test by itself just runs the test, and
   darcs test --trackdown and darcs test --bisect do trackdown-ish tasks?

5. What are the possible unintended interactions with other pre-existing
   features?

   EYK: Like Darcs trackdown, this assumes a patch ordering (which goes
   a little bit against the grain of Darcs), but this is not a new
   problem and it seems hard to avoid anyway (consider darcs changes -v)

6. What are the alternative approaches to solving the same problem? Why
   do we prefer this one?

   EYK: We could farm this out to third party tools, eg. using the Darcs
   library.  I suppose we prefer doing this within Darcs because it's
   something that users would run frequently enough.  Also, we already
   have a testing command anyway, so it would seem silly not to pass up
   the opportunity to make it more powerful.

7.  Who are the stakeholders? Who is going to benefit/be affected by
    this feature: end-users, repo farms like patch-tag, darcs
    developers?

    I think this is specific to stakeholders.

Phew, I hope I got this right.  This is something we'll learn to do
right over the long term, I hope.

Eric

PS. For other Grumpy Old Men out there, I think it's important that we

(i) Treat these questions as a guide to ensure that we are being
    sufficiently attentive about conceptual integrity (and not
    as a formality or a bureaucratic burden)

(ii) Avoid mindless conservatism.  The point is to make sure that
     Darcs UI is great (partly because being the easiest DVCS to
     use is one of the precious/unique aspects of Darcs).  While we want
     to avoid flip-flopping, it may sometimes be necessary to introduce
     change to have a more stable and coherent UI in the long term.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Attachment: signature.asc
Description: Digital signature

_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users

Reply via email to