[Bug-gnu-arch] Re: [bug #5443] file-revert command

[Tom Lord]

    > From: Dustin Sallings <address@hidden>

    >   This is ridiculous.  Why was this bug closed?

It was not closed -- it was put into "Feedback" status, meaning that I
request you take some additional action.

A quick review suggested that the changes are acceptable if fixed and
that it won't take much work to fix the remaining problems.



    >   If it's because it doesn't compile against the latest, that sounds  
    > like a collision.  It compiled just fine against 177 which I merged in  
    > on 2003/09/24 (two days ago).

I got some undefined variables when I tried compiling it.  If you
discover this was a "user error" on my part, I'll be happy to retry.


    >   If it's because of the formatting conventions, let me know what indent  
    > options to use to repair it.

I don't know what indent options will fix it.

Generally: formatting foo is not a show-stopper but it's appreciated
if you can keep the code consistent.   The undefined variables were
the big thing.

As for formatting:

Braces should go on their own lines.

Indenting is by two spaces per level with labels outdented.

There should be a space before the ( in function calls and function
declarations.

static functions should come after exported ones, separated from the
external ones with a formfeed, and be declared in a section at the top
of the file that starts with a comment of the form:

   /* __STDC__ prototypes for static functions */

That section of static declarations should be surrounded by formfeeds.

Longer lines up to about 160 or so characters are preferable to
breaking up expressions over multiple lines.

The `=' in an assignment should be preceeded and followed by a space.


    >   If it's because of the parameter ordering, that's a very minor fix.

Yes, if that were the only problem -- even if that and the formatting
were the only problems in what is a fairly small change -- I would
have simply fixed that and perhaps mentioned it to you for future
reference.

Again: perhaps I spazzed on the merge and it really does compile but
it didn't appear so when I tried.   If you think it does, I'll retry.


    >   The only reason it should be closed as invalid is if you don't believe  
    > the file-revert command should exist (and it would've been nice to say  
    > so).  If this is the case, I think it's short-sighted.  This is the  
    > most common operation I perform in my revision control systems outside  
    > of the usual checkin procedure.

Sorry for the confusing fields -- they are both mandatory fields on
Savannah and I don't quite like them.  Now I have another reason.

Don't overinterpret "Resolution".  By setting it to "invalid" I just meant
that the change doesn't compile.   Perhaps I should have left it at
"None" -- it makes little difference.

It's the status field that determines whether or not a bug has been
closed.  In this case the status is "Feedback", not "Closed".


    > > =================== BUG #5443: LATEST MODIFICATIONS ==================
    > > http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5443&group_id=4899
    > >
    > > Changes by: Tom Lord <address@hidden>
    > > Date: Fri 09/26/2003 at 14:38 (US/Pacific)
    > >
    > >             What     | Removed                   | Added
    > > ----------------------------------------------------------------------- 
    > > ----
    > >           Resolution | None                      | Invalid
    > >               Status | Open                      | Feedback
    > >

-t