On Fri, Mar 28, 2008 at 04:36:24PM -0700, Russ Allbery wrote: > I think that you will find it easier to do the work incrementally if you > keep Type as-is and add a new header containing this information. We can > then run Lintian in either mode and compare the results for a while before > retiring the old classification system and rebasing it on the new tags. > Otherwise, it becomes a single flag-day change, and those are always > harder to pull off.
I agree working incrementally makes sense here. Even if I were to implement the keywords list, the plan is to keep the behaviour of Lintian unchanged until the new classification is "ready". > Otherwise, this is more general than I had been planning but still seems > fundamentally sound. I think it's worth considering, given that we > already have a field syntax where it's very easy to add more fields, > whether it makes sense to use keywords instead of just adding more > fields. In other words, rather than having: > > Type: severity::error, certainty::wild-guess, origin::policy > > you could have: > > Severity: error > Certainty: wild-guess > Origin: policy > > and use more of the existing parsing infrastructure without having to > handle the keywords separately. I actually don't have a strong opinion about it. I asked in part because I don't really know if there will be need for more categories in the future, but I guess it is hard to tell. Your mail made me change my opinion about using new fields, but as you said, this is a rather specific detail. There is no need to decide right now. > Taking a step back from the specific details, I see this work as having > three basic steps. This is just my view on it, though, and you may want > to do it differently. My view isn't that different. A fourth step I also thought about is enhancing lintian.debian.org to support the new classification, but it probably isn't a "basic" step. Thanks for your comments, they are really appreciated. You helped me solve a few misunderstandings I had, and made me realize about some flaws in my proposal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]