Re: What backend should be the default now on -nix?

[Gregory John Casamento]

MJ,

--- MJ Ray <mjr@dsl.pipex.com> wrote:

> Gregory John Casamento <greg_casamento@yahoo.com> wrote:
> > > [...] If one
> > > changes too many things together, you can't tell what fixed the bug
> > > and it teaches little.  Each "cvs update" run risks introducing new
> > > problems as well as cures. [...]
> > Actually, I was talking from the point of view of the end user, not the
> > developer who is fixing the bugs. [...]
> 
> Actually, so was I. I'm certainly not a developer who can fix the bugs
> and at this rate I never will be. One of the things I really like about
> free software is the ability to get involved and learn new things. It's
> really frustrating when I encounter the box-shifter's attitude of "oh,
> that one's broken for you? Have a new black box."
> 
> Would the developers like to get more feedback and specific thanks for
> fixing particular nasty bugs?

I'm sure that they would.
 
> > I, personally, fix one bug at a time, but when I commit it's usually only
> after
> > I've been through the process of fixing several bugs.
> 
> So no-one besides you can really untangle your bugfixes?

Yes, they can untangle my bugfixes.   For each bug I discover I document
exactly what was fixed in the ChangeLog and I also, if a savannah bug exists,
document the cause there AND in the ChangeLog.   Also we do have a CVS mailing
list which shows diffs when something is committed.

Also, if you can point me to anywhere in the GNU Coding Standards where it says
I must do one bugfix for each commit, I'll start doing that.   I strive to go
above and beyond the standard, if I can, but I admit I don't do one commit per
bugfix.

Additionally, for anyone lacking the willingness, ability or skill to go
through any bugfixes I make I would be glad to help that person understand by
taking the time to explain why each correction was made.  Again, however, this
is what the ChangeLog and commit comments are there for.  

> > I'm not sure I necessarily agree with this.  How else would you rather it
> be
> > handled?  Should we be more detailed in our responses to users and tell
> them
> > what the nature of each bug in the previous release was and how it was
> fixed?  
> > This is actually what the ChangeLog is for, BTW.   To show what was done
> with a
> > little explanation of how it was done.
> 
> I think I answered part of how I would rather it was handled before:
> Release patches.  If there are so many serious problems fixed that there
> are too many patches, it may be time for another release, or at least
> a Release Candidate compilation patchfile.

What level, precisely, are you talking about releasing patches at?  Doing it at
the individual bug level can get pretty tiresome, although this would allow
other developers to pick and choose which changes go in, but it might become an
issue since changes are sometimes interdependent.
 
> I doubt that verbose descriptions are necessary, but I would like
> some way to connect a bug report (which describes the user experience
> problem) with the fix commit (which would identify the patch) or the
> patch. That's not possible from the ChangeLogs, as far as I can tell,
> or Savannah tracker. Some Savannah bugs just get closed with a comment of
> "Fixed in CVS".

None of mine ever do, and I don't agree with this practice. 


=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A Maryland Corporation)
#### Maintainer of Gorm for GNUstep.