[ditz-talk] What about labels?

Nicolas Pouillard nicolas.pouillard at gmail.com
Mon Sep 1 07:53:37 EDT 2008

Excerpts from Nicolas Pouillard's message of Sun May 25 16:13:10 +0200 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.

This work is now somewhat outdated by recent ditz changes.

Before reworking it I would like to be sure that people/you want it.

I plan to do it soon and I would like to be sure that's a good period to be

More precisely one have to choose between making this change backward
compatible or not (if so one will provide a migration tool). The first version
was backward compatible, but I've heard that issue types could be removed
(tasks,bugs,features) and I think it could be a good reason to switch to

The migration tool will convert issues types and components into labels,
making two labels per issue after the conversion, then people can choose to
continue that way or remove labels to hide components and/or issue types.


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/20080901/9b0cbcdc/attachment.bin>

More information about the ditz-talk mailing list