[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnu-arch] Re: [bug #5443] file-revert command
From: |
Tom Lord |
Subject: |
[Bug-gnu-arch] Re: [bug #5443] file-revert command |
Date: |
Fri, 26 Sep 2003 16:36:19 -0700 (PDT) |
> 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
[Bug-gnu-arch] [bug #5443] file-revert command, nobody, 2003/09/27