[ditz-talk] What about labels?

Nicolas Pouillard nicolas.pouillard at gmail.com
Sun May 25 10:13:10 EDT 2008

Excerpts from William Morgan's message of Sun May 25 05:39:49 +0200 2008:
> Reformatted excerpts from nicolas.pouillard's message of 2008-05-02:
> > I  would  like  to have a little more expressivity/flexibility when
> > organizing issues  with  ditz.  The  'component'  feature is too
> > limited and I would like extend to something better.
> Well, no one has replied to this yet, which probably means no one
> objects. :)

Sort of...

> Personally I'd be fine with labels, since it's a lossless extension of
> the component idea. I don't see it as something that would immediately
> help me (since I mostly get what I want with ditz grep), but if there
> are a lot of issues, then it will become useful. (Wow, this is just like
> the Gmail / Sup story....)

That's not a lossless extension, the thing you lost when switching to labels
is that an issue is no longer labeled by one and only one label. From the
user point of view is not a problem at all, from the code this means that
iterating over labels and searching for issues that have this labels leads to
iterating more than some issues and must treat specially unlabelled ones.

However that's no big deal, as you will see in the published branch 'labels'
[1] that depends on 'after-deserialize-on-issues' and 'factorize-html'.

> >   (1) Would the feature kindly accepted? (assuming a consensus...)
> >   (2) Should it replaces components?
> >   (3) What becomes the short-name of issues?
> >   (4) How to update the "display issues by component" to labels?
> > 
> > Concerning  (2),  I  think  it  should replace them.
> I agree.

That's what I've done:
  - in a backward compatible manner:
      that is issue component are seen as having one label
  - in a mostly forward compatible manner:
      while using only one label per issue the issue is stored back
      as usual.

> > Concerning (3), I see three ways of doing it:
> > 
> >   * One sort all labels, and join them with a dash: label1-label2-42.
> >   * One give to the first label more importance.
> >   * One forgive about the feature and give them all the same name:
> >     project-42.
> I'd prefer either #2 or #3. These names aren't persistent, aren't
> exported to the outside world, and basically are just there so that
> you're not typing the full hash out each time. So it doesn't really
> matter what they are, as long as they're short. Heck, it could just be a
> number, as far as I'm concerned.
> Tying the issue local name to a component name was a vestigal remnant of
> an earlier, more JIRA-like idea I was playing with. I don't know that it
> really adds that much.

Ok I've done #1 for now, since combined with shell completion typing the
component/label already filter only issues that matches this label. However I
plan to switch to #2 to maintain the shortness.

> > Concerning (4), I also see three ways of doing it:
> > 
> >   * One add a section per sorted-combination of labels.
> >   * One mixup all issues together and show labels clearly.
> >   * One give to the first label more importance.
> I suggest just having a list of issues for every label. The per-label
> counts will add up to more than the total issue count, but who cares
> about that?

That's what I've done so far.

[1]: http://gitorious.org/projects/ditz/repos/clone-by-ertai/logs/labels

Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080525/efb2bb0e/attachment.bin>

More information about the ditz-talk mailing list