discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recommended minimum information when submitting bugs...


From: Nicola Pero
Subject: Re: Recommended minimum information when submitting bugs...
Date: Mon, 1 Nov 2004 15:16:05 +0000 (GMT)

> > Eg, the following quick patch adds the function
> > 'gnustep_gui_version_last_change ()' to gnustep-gui, which returns the
> > date/time/author of the last change compiled into the library as 
> > reported
> > by the ChangeLog.  The make rules should keep that updated.
> 
> Interesting idea. FYI, in gdb it pulls the date that you last did a 
> 'cvs update',

I would be interested in seeing how they do :-)


> which I suppose could be a problem if you've checked out 
> a branch and not the mainline (although I think gdb accounts for this 
> somehow).

Well, if branches are involved, it is complex :-) even with the ChangeLog
approach, that date/time/author of the last applied change does not tell
you enough if that same change was applied to both mainline and branch and
the branches differ in other respects ... But if you couple the last
ChangeLog entry with the GNUSTEP_GUI_VERSION you should get a clear
understanding of which version is being used ... presumably the mainline
and the branch will have different GNUSTEP_GUI_VERSIONs; once you know in
which branch you are, the last ChangeLog entry gives you the final bit to
determine exactly which version is being used.

Another approach would be to run 'cvs status ChangeLog' to get the exact
version of the ChangeLog.  That would give you a number which is different
on the branch and on the mainline and which uniquely identified the
ChangeLog version you're using (from which, presumably, assuming they have
checked out the same branch in all the tree and that every change is
recorded in the ChangeLog, you should be able to determine exactly what
they are running).

But I liked the ChangeLog approach because it wasn't dependent on CVS ... 

Maybe what gdb does is different but nice / nicer.


> The problem with your patch is that it's possible someone would not put
> in a ChangeLog, but that's really a no-no anyway.

Yes, but I'd assume there is enough social control to prevent this from
happening. :-)


Anyway, I don't have a strong opinion, mine was just a quick suggestion to
dispel the fear and uncertainty around implementing those things, which
only deciding on a simple API, and then a few make rules to implement it.

Thanks





reply via email to

[Prev in Thread] Current Thread [Next in Thread]