From nicolas.pouillard at gmail.com Fri May 2 12:33:08 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri, 02 May 2008 18:33:08 +0200 Subject: [ditz-talk] What about labels? Message-ID: <1209744474-sup-3166@ausone.local> Hi all, 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. I had a few ideas the first one was to use directories in the bugs/ directory to model a hierarchy of components. Although I think that these hierarchies are too rigid and prefer the idea of labels/tags. The questions that come to me are: (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've planned & started an implementation that would be: * backward compatible: Handling old 'databases', assuming that being in a component means that we are labeled with one label of the same name. * forward compatible: While the feature is not finished the 'database' will not be converted while there is only exactly one label for an issue. * keeping components would be redundant and boring for users to answer one more question while adding an issue. 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. 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. Ideas? questions? Best regards, -- 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: From wmorgan-ditz at masanjin.net Sat May 24 23:39:49 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 24 May 2008 20:39:49 -0700 Subject: [ditz-talk] What about labels? In-Reply-To: <1209744474-sup-3166@ausone.local> References: <1209744474-sup-3166@ausone.local> Message-ID: <1211686071-sup-8952@south> 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. :) 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....) > (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. > 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. > 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? -- William From nicolas.pouillard at gmail.com Sun May 25 10:13:10 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 25 May 2008 16:13:10 +0200 Subject: [ditz-talk] What about labels? In-Reply-To: <1211686071-sup-8952@south> References: <1209744474-sup-3166@ausone.local> <1211686071-sup-8952@south> Message-ID: <1211723397-sup-238@ausone.local> 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: From wmorgan-ditz at masanjin.net Sat May 31 20:44:58 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 31 May 2008 17:44:58 -0700 Subject: [ditz-talk] per-field lazy custom deserialization Message-ID: <1212280737-sup-1792@entry> I've just merged into edge a branch which allows model objects to have per-field custom deserialization/serialization code, which is called lazily and on a per-field basis. The upshot is that issue names will now be interpolated correctly in titles and in comments as well as in descriptions. (That was easy enough to do per se, but it was really slow without the per-field laziness.) This is turning into a pretty reasonable YAML ORM (YORM?). A little more sophistication and we'll have a competitor to ActiveRecord. :) -- William