Re: Handling BUGS.

[Evan Prodromou]

>>>>> "TN" == Thien-Thi Nguyen <address@hidden> writes:

    Me> In other words, concentrate on the release, not the
    Me> bug-tracking "tool". What you're suggesting gives everyone an
    Me> excuse to ignore the BUGS file and (totally insufficient)
    Me> system in place until the "next" system appears.

    TN> so i would have to disagree w/ your point, but obliquely; it
    TN> is precisely the act of concentrating on release that is the
    TN> motivating factor here, and it seems the proposed changes are
    TN> well thought-out, or in the process of becoming so.

Well, then, if that's the case, I'd say go for it.

HOWEVER, it seems that perhaps maintaining the current bug file format
(except, of course, splitting up bugs between files) might get one
"there" faster than hoping for -- or hacking on -- an RFC822 parser.

    TN> when you say "it is more important to do this than that" you
    TN> lose sight of the fact that parallel effort is possible and
    TN> indeed encouraged -- good project manglement is not so much
    TN> about constraining (controlling, contorting) efforts into a
    TN> single thread, but more about defining a future sync point
    TN> where the multiple threads can come together (in a harmonious
    TN> way hopefully).

This is true. However, good _release_ management has everything to do
with prioritizing energy and focus, and having dependable
processes. 

~ESP

-- 
Evan Prodromou
address@hidden