Re: A thought on urgency
On Mon, 18 Sep 2000, Joey Hess wrote:
> > happened in the versions you can no longer see [1.1 to 1.3 in this
> > example]. That reduces the usability of the feature to about the level
> > of a cheap hack..
> I know. I hope someone comes up with a way to make it work. The control
> file has always been human readable, and we shouldn't change that.
I don't see how a number is not readable.. We already have version
numbers that define order.
> We already get enough oops-LAST-version-was-HIGH-priority-not-this-one
> uploads with it in the changelog. Putting it in the control file will
> just make them more common.
Actually it should make it less common because you have to explicitly go
and increment that field. If you don't then the priority is automatically
low.
You might see a new class of problems where people forget to increment the
serial and set a high priority though.. This could probably actually be
caught though. Catching this would catch the
oops-LAST-version-was-HIGH-priority-not-this-one problem too.
What is that field in the change log used for anyhow? Maybe just tank it
:P
> > You could probably compute the urgency value from the change log just by
> > summing all the urgencies of each release. Taking care to never truncate
> > the changelog.
>
> That would be a (hackish) start, but it doesn't address keeping the
> control file human readable.
I don't see your objection to a number.. It is about as opaque to a user
as it is to a tool -> higher = important bug fixes.
> If this is the best we can do, we should probably not bother -- package
> pools can yeild some of the same behavior.
Package pools will not.. Testing perhaps.
Jason
Reply to: