changelog rotation...

changelog rotation...

[J.T. Conklin]

Now that gcc and binutils have rotated ChangeLogs, should we do the
same for gdb?  By existing convention, the new ChangeLog file would be
ChangeLog-00.

Is there any reason not to use it?  The only drawback is that a sorted
directory listing wouldn't keep the files in numerically correct order.

        --jtc
 
-- 
J.T. Conklin
RedBack Networks

Re: changelog rotation...

[Fernando Nasser]

"J.T. Conklin" wrote:
> 
> Now that gcc and binutils have rotated ChangeLogs, should we do the
> same for gdb?  By existing convention, the new ChangeLog file would be
> ChangeLog-00.
> 
> Is there any reason not to use it?  The only drawback is that a sorted
> directory listing wouldn't keep the files in numerically correct order.
> 

We use 4 digits for gdbtk ChangeLogs.  Maybe we should do this for gdb
as well.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: changelog rotation...

[J.T. Conklin]

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
>> 
>> Now that gcc and binutils have rotated ChangeLogs, should we do the
>> same for gdb?  By existing convention, the new ChangeLog file would be
>> ChangeLog-00.
>> 
>> Is there any reason not to use it?  The only drawback is that a sorted
>> directory listing wouldn't keep the files in numerically correct order.
>> 

Fernando> We use 4 digits for gdbtk ChangeLogs.  Maybe we should do
Fernando> this for gdb as well.

I see no reason not to.  If we did, I'd split ChangeLog-9091 into two
files.  There's not much of a reason for it to be one file anyway, if
everything else is split by single years.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: changelog rotation...

[Fernando Nasser]

"J.T. Conklin" wrote:
> 
> >>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
> >>
> >> Now that gcc and binutils have rotated ChangeLogs, should we do the
> >> same for gdb?  By existing convention, the new ChangeLog file would be
> >> ChangeLog-00.
> >>
> >> Is there any reason not to use it?  The only drawback is that a sorted
> >> directory listing wouldn't keep the files in numerically correct order.
> >>
> 
> Fernando> We use 4 digits for gdbtk ChangeLogs.  Maybe we should do
> Fernando> this for gdb as well.
> 
> I see no reason not to.  If we did, I'd split ChangeLog-9091 into two
> files.  There's not much of a reason for it to be one file anyway, if
> everything else is split by single years.
> 

I agree.  Are you doing the renaming?  Nobody seems to disagree and this
has been the standard practice for years anyway.  I guess it was just a 
question of someone getting around to do it.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: changelog rotation...

[J.T. Conklin]

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
>> I see no reason not to.  If we did, I'd split ChangeLog-9091 into two
>> files.  There's not much of a reason for it to be one file anyway, if
>> everything else is split by single years.

Fernando> I agree.  Are you doing the renaming?  Nobody seems to
Fernando> disagree and this has been the standard practice for years
Fernando> anyway.  I guess it was just a question of someone getting
Fernando> around to do it.

I'll do the renaming as long as no one really wants to do it.  The
bulk of what I want to do is still stalled waiting for an approval, 
so I'm keeping myself occupied doing little stuff on the side.

So the current proposal is:

        * rename ChangeLog-9X to ChangeLog-199X
        * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991        
        * split ChangeLog-2000 out of ChangeLog.

Any objections?  If not, I intend to check in this tomorrow.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: changelog rotation...

[Stan Shebs]

"J.T. Conklin" wrote:
> 
> So the current proposal is:
> 
>         * rename ChangeLog-9X to ChangeLog-199X
>         * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991
>         * split ChangeLog-2000 out of ChangeLog.
> 
> Any objections?  If not, I intend to check in this tomorrow.

Coolio, I was hoping somebody would do something like that for GDB.
(I made a ChangeLog-00 for Xconq last week, looked at it for a couple
minutes, said "nahhh" and did just what you're proposing.)

Stan

Re: changelog rotation...

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 11 Jan 2001 12:16:29 -0800
> 
> Now that gcc and binutils have rotated ChangeLogs, should we do the
> same for gdb?  By existing convention, the new ChangeLog file would be
> ChangeLog-00.
> 
> Is there any reason not to use it?

Yes: these ChangeLog-NNNN names all clash after truncation to DOS 8+3
limits.

I believe it is a long-term goal to eliminate such problems.  So I'd
suggest to start this now, and rename all ChangeLog-NNNN into
ChangeLog.NNNN.

Re: changelog rotation...

[Eli Zaretskii]

> Reply-To: jtc@redback.com
> From: jtc@redback.com (J.T. Conklin)
> Date: 11 Jan 2001 14:17:08 -0800
> 
> So the current proposal is:
> 
>         * rename ChangeLog-9X to ChangeLog-199X
>         * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991        
>         * split ChangeLog-2000 out of ChangeLog.

I suggest this instead:

         * rename ChangeLog-9X to ChangeLog.9X
         * split ChangeLog-9091 into ChangeLog.90 and ChangeLog.91        
         * split ChangeLog.00 out of ChangeLog.

Re: changelog rotation...

[Eli Zaretskii]

> Date: Thu, 11 Jan 2001 17:06:35 -0500
> From: Fernando Nasser <fnasser@redhat.com>
> 
> Are you doing the renaming?  Nobody seems to disagree

Please allow a bit more time for dissent to be posted.  Not everybody
lives on EST around here, and sometimes some of us do happen to be
off-line (e.g., to catch some sleep ;-).

Re: changelog rotation...

[Eli Zaretskii]

> Date: Fri, 12 Jan 2001 11:15:34 +0200
> From: "Eli Zaretskii" <eliz@is.elta.co.il>
> > 
> > So the current proposal is:
> > 
> >         * rename ChangeLog-9X to ChangeLog-199X
> >         * split ChangeLog-9091 into ChangeLog-1990 and ChangeLog-1991        
> >         * split ChangeLog-2000 out of ChangeLog.
> 
> I suggest this instead:
> 
>          * rename ChangeLog-9X to ChangeLog.9X
>          * split ChangeLog-9091 into ChangeLog.90 and ChangeLog.91        
>          * split ChangeLog.00 out of ChangeLog.

I can also suggest alternative schemes that you might want to
consider.  One possibility is to rename the files to ChangeLog.1,
ChangeLog.2, ChangeLog.3, etc., starting with the oldest one.  This is
what Emacs does in its distribution.

Emacs also splits ChangeLog files by versions, not by years.  Thus, a
new ChangeLog is started when a version X.YZ is released and work on
the next version begins.  (Since GDB uses branching, this would mean
to start a new ChangeLog when a certain version's branch is cut.)

I think splitting by version is better than by years, because it is
trivial to find out to what years does a certain ChangeLog file
belongs, by looking at its head and tail, whereas the opposite--find
out what version's ChangeLog entries are in which file--is not trivial
at all.

Btw, it is not necessary to have one ChangeLog per released version;
depending on the number of entries, several versions can live in the
same ChangeLog file.

If we do put each version on its own ChangeLog, we could have
ChangeLog.418, ChangeLog.500, etc.

Re: changelog rotation...

[Fernando Nasser]

Eli Zaretskii wrote:
> 
> > From: jtc@redback.com (J.T. Conklin)
> > Date: 11 Jan 2001 12:16:29 -0800
> >
> > Now that gcc and binutils have rotated ChangeLogs, should we do the
> > same for gdb?  By existing convention, the new ChangeLog file would be
> > ChangeLog-00.
> >
> > Is there any reason not to use it?
> 
> Yes: these ChangeLog-NNNN names all clash after truncation to DOS 8+3
> limits.
> 

Lots of other things will clash as well.

Our established file size limit is 14, exactly what these names have.


> I believe it is a long-term goal to eliminate such problems.  So I'd
> suggest to start this now, and rename all ChangeLog-NNNN into
> ChangeLog.NNNN.

We can't keep adding limitations to GDB and other free software based on
obsolete 20 year old operating systems.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: changelog rotation...

[Andrew Cagney]

Fernando Nasser wrote:

> We can't keep adding limitations to GDB and other free software based on
> obsolete 20 year old operating systems.

We shouldn't be doing anything to hinder people with such operating
systems either.  Supporting GNU tools on DOS/cygwin is important.

	Andrew

Re: changelog rotation...

[Eli Zaretskii]

> Date: Fri, 12 Jan 2001 08:13:34 -0500
> From: Fernando Nasser <fnasser@redhat.com>
> 
> Lots of other things will clash as well.

But why add to those clashes?  In the long run, we agreed to eliminate
most, if not all of these problems by using subdirectories more
aggressively.

> Our established file size limit is 14, exactly what these names have.

I don't have anything against long file names, even if they are longer
than 14 characters, as long as they don't clash after truncation to
8+3.

> > I believe it is a long-term goal to eliminate such problems.  So I'd
> > suggest to start this now, and rename all ChangeLog-NNNN into
> > ChangeLog.NNNN.
> 
> We can't keep adding limitations to GDB and other free software based on
> obsolete 20 year old operating systems.

Uhm.. Unix is even older than that, I believe ;-)

Anyway, I really don't understand the attitude.  The DJGPP port is
part of the official distribution and is fully supported by the GDB
project.  Amazingly enough, the DJGPP installed base doesn't seem to
be decreasing, judging by the traffic on comp.os.msdos.djgpp (it
amazes me as well).  Thousands of teenage programmers are exposed to
Free Software through using DJGPP.  The FSF is now releasing the 2nd
edition of the "GNU Software for MS-Windows and MS-DOS" CD-ROM, which
is based equally on DJGPP and Cygwin ports (the previous editions were
all sold out); that CD-ROM includes ports of all the latest GNU stuff,
including GCC 2.95.2, Emacs 20.7 and GDB 5.0.

As long as the DJGPP port of GDB is fully supported, each file which
clashes with other files means more work for me, to resolve those
clashes, because otherwise users will not be able to build GDB
reliably.  When you add such files, you are fighting against me and
against DJGPP users, not against Microsoft.

Now, I'm fully aware that DOS and Windows are not the most important
operating systems on GNU Project's agenda, so if there are valid
technical reasons to do something that makes the maintenance of the
DJGPP port a bit harder, I'll accept that.  If some technical
considerations dictate that we use ChangeLog-NNNN names, let's talk
about those considerations.

I suggested a few alternative solutions, which I think are better, on
their own merit (split by version, not by year), and at the same time
avoid file-name clashes.  Perhaps considering those suggestions would
help us solve the problem without arguing about file names.

Re: changelog rotation...

[Frank Ch. Eigler]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

: [...]
: Anyway, I really don't understand the attitude.  [...]
: Thousands of teenage programmers are exposed to Free Software through
: using DJGPP.  [...]

Really?  How would you compare the popularity of Win32 platforms to
DOS for running GNU tools on?

Why are Cygwin and DOS mentioned in the same sentence anyway?  Is it
not the case that any machine that can run Cygwin is unaffected by the
DOS 8.3 limits?  (VFAT!)


- FChE

Re: changelog rotation...

[DJ Delorie]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> suggest to start this now, and rename all ChangeLog-NNNN into
> ChangeLog.NNNN.

They'd also conflict, by dropping the last digit.  We might have to
handle this in djtar, like the info files.

Re: changelog rotation...

[J.T. Conklin]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
>> Date: Thu, 11 Jan 2001 17:06:35 -0500
>> From: Fernando Nasser <fnasser@redhat.com>
>> 
>> Are you doing the renaming?  Nobody seems to disagree

Eli> Please allow a bit more time for dissent to be posted.  Not
Eli> everybody lives on EST around here, and sometimes some of us do
Eli> happen to be off-line (e.g., to catch some sleep ;-).

Sorry, I jumped the gun and the renaming has already occured.  That's
not to say that it must stay that way.  It's trivial to rename them 
once again if a new naming convention is prefered.

For the time being, I'm going to step aside and let things sort them-
selves out.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: changelog rotation...

[Stan Shebs]

Eli Zaretskii wrote:
> 
> I can also suggest alternative schemes that you might want to
> consider.  One possibility is to rename the files to ChangeLog.1,
> ChangeLog.2, ChangeLog.3, etc., starting with the oldest one.  This is
> what Emacs does in its distribution.

Now that I'm working on GCC, I find that this is more puzzling
than the GDB scheme; the names give no information beyond that the
file has been split.

> If we do put each version on its own ChangeLog, we could have
> ChangeLog.418, ChangeLog.500, etc.

I really like this idea.

Stan

Re: changelog rotation...

[J.T. Conklin]

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:

Stan> Eli Zaretskii wrote:
>> 
>> I can also suggest alternative schemes that you might want to
>> consider.  One possibility is to rename the files to ChangeLog.1,
>> ChangeLog.2, ChangeLog.3, etc., starting with the oldest one.  This is
>> what Emacs does in its distribution.

Stan> Now that I'm working on GCC, I find that this is more puzzling
Stan> than the GDB scheme; the names give no information beyond that the
Stan> file has been split.

>> If we do put each version on its own ChangeLog, we could have
>> ChangeLog.418, ChangeLog.500, etc.

Stan> I really like this idea.

I actually like the split-by-year scheme.  This tends to place about
the right number of entries in each file regardless of whether there
are six months or two years between GDB releases.  It makes it easy 
to go from the mailing list archives to the cooresponding ChangeLog
file without any guessing.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: changelog rotation...

[Kevin Buettner]

On Jan 12, 11:33am, J.T. Conklin wrote:

> >> If we do put each version on its own ChangeLog, we could have
> >> ChangeLog.418, ChangeLog.500, etc.
> 
> Stan> I really like this idea.
> 
> I actually like the split-by-year scheme.  This tends to place about
> the right number of entries in each file regardless of whether there
> are six months or two years between GDB releases.  It makes it easy 
> to go from the mailing list archives to the cooresponding ChangeLog
> file without any guessing.

I agree with J.T.

(I don't normally like "me too" mail, so just consider this as a vote
against any split-by-version scheme.)

Kevin

Re: changelog rotation...

[Christopher Faylor]

On Fri, Jan 12, 2001 at 02:49:39PM -0700, Kevin Buettner wrote:
>On Jan 12, 11:33am, J.T. Conklin wrote:
>
>> >> If we do put each version on its own ChangeLog, we could have
>> >> ChangeLog.418, ChangeLog.500, etc.
>> 
>> Stan> I really like this idea.
>> 
>> I actually like the split-by-year scheme.  This tends to place about
>> the right number of entries in each file regardless of whether there
>> are six months or two years between GDB releases.  It makes it easy 
>> to go from the mailing list archives to the cooresponding ChangeLog
>> file without any guessing.
>
>I agree with J.T.
>
>(I don't normally like "me too" mail, so just consider this as a vote
>against any split-by-version scheme.)

Maybe a compromise is to adopt the Microsoft-style version numbering of

"GDB 2001", "GDB 2002", etc.  Then we'd have the best of both worlds.

:-) (I think)

cgf

Re: changelog rotation...

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 12 Jan 2001 11:33:45 -0800
> 
> >> If we do put each version on its own ChangeLog, we could have
> >> ChangeLog.418, ChangeLog.500, etc.
> 
> Stan> I really like this idea.
> 
> I actually like the split-by-year scheme.  This tends to place about
> the right number of entries in each file regardless of whether there
> are six months or two years between GDB releases.

Why is this important to have ChangeLog files be of similar sizes?

In any case, the decision to start a new ChangeLog is a human one, and
can be based on the size as well.

> It makes it easy to go from the mailing list archives to the
> cooresponding ChangeLog file without any guessing.

You don't need to guess, just to "head ChangeLog.*".

Anyway, if you-all decide to stay with year-based split, I don't mind.

Re: changelog rotation...

[Eli Zaretskii]

> From: DJ Delorie <dj@redhat.com>
> Newsgroups: cygnus.gdb
> Date: 12 Jan 2001 12:59:27 -0500
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > suggest to start this now, and rename all ChangeLog-NNNN into
> > ChangeLog.NNNN.
> 
> They'd also conflict, by dropping the last digit.

Only if we use 4-digit years.  We could use the last 3 digits
instead.  (Yes, it _is_ ugly, which is why I suggested to split the
files by GDB version, not by the year.)

> We might have to handle this in djtar, like the info files.

The GDB distribution already does that, by invoking DJTAR with a
rename file.  I was just trying to keep its size in check.

I'm not sure doing so in DJTAR's code is a good idea: this problem is
unique to GDB, and the right renaming isn't obvious to put it into
code applied automatically.

Re: changelog rotation...

[Eli Zaretskii]

> From: fche@redhat.com (Frank Ch. Eigler)
> Date: 12 Jan 2001 11:38:01 -0500
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
> : [...]
> : Anyway, I really don't understand the attitude.  [...]
> : Thousands of teenage programmers are exposed to Free Software through
> : using DJGPP.  [...]
> 
> Really?  How would you compare the popularity of Win32 platforms to
> DOS for running GNU tools on?

I don't have any objective data to compare.  Perhaps DJ can contribute
some insight.

What I can tell is that the comp.os.msdos.djgpp news group generates
about 100 messages on any given day.  That's a clear sign of a large
number of users.

Note that many (probably most) users run DJGPP on some version of
Windows nowadays, since DJGPP programs are very nice console
applications (they support long file names on Windows).  I'm guessing
that they use DJGPP because it is very easy to set up and use: unzip
the files, set a couple of environment variables, and start coding.

> Why are Cygwin and DOS mentioned in the same sentence anyway?  Is it
> not the case that any machine that can run Cygwin is unaffected by the
> DOS 8.3 limits?  (VFAT!)

The file-name problem is indeed irrelevant to Cygwin.  But other
nuisances are common to DOS and Windows.  For example, some characters
are invalid in file names on both DOS and Windows, you cannot delete
an open file on some of the Windows version, etc.

Re: changelog rotation...

[DJ Delorie]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > Really?  How would you compare the popularity of Win32 platforms to
> > DOS for running GNU tools on?
> 
> I don't have any objective data to compare.  Perhaps DJ can contribute
> some insight.

The only data I have is that the web server claims about 1000 people a
day access the zip-picker (the cgi that tells them what to download
and how to install).  Here's one day's summary (last Thursday):

    115	os=dos
     11	os=dosemu
     30	os=unix
      9	os=win3x
    356	os=win95
    673	os=win98
    188	os=winNT

Note that only 95/98 support long file names in DOS, leaving 25% of
all djgpp users with the 8.3 restriction.

Re: changelog rotation...

[Eli Zaretskii]

> From: DJ Delorie <dj@redhat.com>
> Newsgroups: cygnus.gdb
> Date: 13 Jan 2001 12:48:22 -0500
> 
> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > > Really?  How would you compare the popularity of Win32 platforms to
> > > DOS for running GNU tools on?
> > 
> > I don't have any objective data to compare.  Perhaps DJ can contribute
> > some insight.
> 
> The only data I have is that the web server claims about 1000 people a
> day access the zip-picker (the cgi that tells them what to download
> and how to install).

1000 per DAY??  Wow! that surprises even me...

> Here's one day's summary (last Thursday):
> 
>     115	os=dos
>      11	os=dosemu
>      30	os=unix
>       9	os=win3x
>     356	os=win95
>     673	os=win98
>     188	os=winNT
> 
> Note that only 95/98 support long file names in DOS, leaving 25% of
> all djgpp users with the 8.3 restriction.

I suspect that some of those registered under NT are actually using
Windows 2000, where long file names _are_ supported, since the
zip-picker doesn't distinguish between these two versions.

Anyway, I hoped that you might have some data about Cygwin downloads
as well, so that we could compare.

Re: changelog rotation...

[Christopher Faylor]

On Sun, Jan 14, 2001 at 06:37:52AM -0500, Eli Zaretskii wrote:
>> Here's one day's summary (last Thursday):
>> 
>>     115	os=dos
>>      11	os=dosemu
>>      30	os=unix
>>       9	os=win3x
>>     356	os=win95
>>     673	os=win98
>>     188	os=winNT
>> 
>> Note that only 95/98 support long file names in DOS, leaving 25% of
>> all djgpp users with the 8.3 restriction.
>
>I suspect that some of those registered under NT are actually using
>Windows 2000, where long file names _are_ supported, since the
>zip-picker doesn't distinguish between these two versions.

Haven't long filenames been supported since almost forever on Windows NT?
I use them on a 3.5 system, at least.

cgf

Re: changelog rotation...

[Fernando Nasser]

Christopher Faylor wrote:
> 
> On Sun, Jan 14, 2001 at 06:37:52AM -0500, Eli Zaretskii wrote:
> >> Here's one day's summary (last Thursday):
> >>
> >>     115      os=dos
> >>      11      os=dosemu
> >>      30      os=unix
> >>       9      os=win3x
> >>     356      os=win95
> >>     673      os=win98
> >>     188      os=winNT

Do we build gdb natively on a DOS system or is it generated with
--build --host --target on a higher system?

Keeping the installed file names is not hard.  If we build on a
different host
the 8.3 restriction on source files won't hurt.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: changelog rotation...

[Eli Zaretskii]

> Date: Sun, 14 Jan 2001 13:17:35 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> >I suspect that some of those registered under NT are actually using
> >Windows 2000, where long file names _are_ supported, since the
> >zip-picker doesn't distinguish between these two versions.
> 
> Haven't long filenames been supported since almost forever on Windows NT?
> I use them on a 3.5 system, at least.

For native Windows programs, that's true, of course.  But DJGPP
programs are DOS executables, as far as Windows is concerned, and DOS
executables are barred from issuing the Win32 API calls for file
access.  So DJGPP programs cannot access the long file names except
through a special API avail;able to DOS programs (a bunch of functions
of Int 21h).  That API is not supported by NT versions before 5
(i.e. before W2K).  Windows 9X always had it included.  The DJGPP
library detects this API at startup and automatically switches all
library functions to use that API, thereby proividing a transparent
support for long file names.

Re: changelog rotation...

[Eli Zaretskii]

> Date: Sun, 14 Jan 2001 13:37:45 -0500
> From: Fernando Nasser <fnasser@redhat.com>
> 
> Do we build gdb natively on a DOS system or is it generated with
> --build --host --target on a higher system?

It is mostly built natively.  Cross-compilation is not something a
typical DJGPP user will consider, and even some of the developers use
native build environment for whatever packages whose ports they maintain.

Re: changelog rotation...

[J.T. Conklin]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
>> I actually like the split-by-year scheme.  This tends to place about
>> the right number of entries in each file regardless of whether there
>> are six months or two years between GDB releases.

Eli> Why is this important to have ChangeLog files be of similar sizes?

IMO, ChangeLogs should have sufficent information density yet not be
so large that they are difficult to use.

What I mean by information density is that a ChangeLog file should be
"large enough" that it is likely to contain entries that refer to the
same change.  In my experience, changes are not always 100% correct
when they are committed.  In most cases, residual problems are quickly
identified and fixed; but occasionally a problem is discovered months
afterward.  I find it convenient to be able to search backwards in the
same changelog file to find related changes.  

Of course this breaks down at the changelog rotation dates.  This
could be fixed by having just one (huge) ChangeLog file, but that has
its own problems.  Recently there was a discussion on the gcc list
about the large ChangeLog causing problems with remote CVS on slow
networks.

If we had a lot more changes, a more frequent rotation interval might
be more appropriate; while if GDB development slowed down, a slower
one might be best.  I think it is interesting to note that the sizes
are roughly the same over the last 10 years.  Perhaps that indicates
that something is bounding the rate of change that can be sustained on
GDB (lack of infrastructure, lack of volunteers, lack of interest,
etc.).  If we could identify and eliminate those roadblocks, we might
be able to make larger strides in the coming years.

But for now, the split-by-year scheme that we have been using seems to
be a good balance of these opposing forces.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: changelog rotation...

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 15 Jan 2001 14:12:52 -0800
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> >> I actually like the split-by-year scheme.  This tends to place about
> >> the right number of entries in each file regardless of whether there
> >> are six months or two years between GDB releases.
> 
> Eli> Why is this important to have ChangeLog files be of similar sizes?
> 
> IMO, ChangeLogs should have sufficent information density yet not be
> so large that they are difficult to use.

Splitting by version will satisfy the first requirement, while not
necessarily contradicting the second.  (I consider a 500KB file to not
be ``too large''.  YMMV.)

Anyway, I think we need a definitive say-so at this time (Andrew?),
because something has to be done to get the CVS sources be usable for
the DJGPP port again.

I will go along with whatever verdict The Powers That Be will issue.
That includes any work that needs to be done if one of my suggestions
for a different split method is accepted: I'm prepared to do it.

Re: changelog rotation...

[Andrew Cagney]

Eli Zaretskii wrote:
> 
> > From: jtc@redback.com (J.T. Conklin)
> > Date: 15 Jan 2001 14:12:52 -0800
> >
> > >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> > >> I actually like the split-by-year scheme.  This tends to place about
> > >> the right number of entries in each file regardless of whether there
> > >> are six months or two years between GDB releases.
> >
> > Eli> Why is this important to have ChangeLog files be of similar sizes?
> >
> > IMO, ChangeLogs should have sufficent information density yet not be
> > so large that they are difficult to use.
> 
> Splitting by version will satisfy the first requirement, while not
> necessarily contradicting the second.  (I consider a 500KB file to not
> be ``too large''.  YMMV.)

Technical point.  Splitting on versions isn't easy.  You could split
when the branch occures but then you end up with is argument about where
to put ChangeLogs made on the branch and merged back into the trunk :-)

> Anyway, I think we need a definitive say-so at this time (Andrew?),
> because something has to be done to get the CVS sources be usable for
> the DJGPP port again.

I should be getting error messages about this and I'm not :-(

> I will go along with whatever verdict The Powers That Be will issue.
> That includes any work that needs to be done if one of my suggestions
> for a different split method is accepted: I'm prepared to do it.

I've honestly no idea on what to do here (one of those cases where you
wish the coding standard took the decision away from you). I guess there
are two choices:

	ChangeLog-NNNN (unix - 14) -> ChangeLog.NNN (dos 8.3)

	ChangeLog.NNN (unix and dos) (we could start numbering from 190 :-)

Much that I totally hate it the latter has merit in that (if I
understand correctly) it is similar to what is used used by EMACS and
EMACS is kind of the technical suplement to the coding standard.

	Andrew

(Must ... resist ... temptation ... to point out that the world was
created in January 1970 so we should be using year offsets from then
....)

Re: changelog rotation...

[Kevin Buettner]

On Jan 17,  2:39pm, Andrew Cagney wrote:

> I've honestly no idea on what to do here (one of those cases where you
> wish the coding standard took the decision away from you). I guess there
> are two choices:
> 
> 	ChangeLog-NNNN (unix - 14) -> ChangeLog.NNN (dos 8.3)
> 
> 	ChangeLog.NNN (unix and dos) (we could start numbering from 190 :-)
> 
> Much that I totally hate it the latter has merit in that (if I
> understand correctly) it is similar to what is used used by EMACS and
> EMACS is kind of the technical suplement to the coding standard.

My unix biases are showing here, but I much prefer ChangeLog-NNNN.

I'm not sure I understand what the problem is for DOS anyway. 
ChangeLogs are not buildable, so they don't have to be referred to in
Makefiles or any other part of the configury, right?  And we do have a
mechanism for mapping colliding names to other (non-colliding) names
when creating a tar file for such systems, right?  Also, we're going
to only be adding a new one of these each year; this should not be
too onerous for the maintainer who has to update the mapping.

That being the case (if it really is the case), I see no reason to
give the ChangeLog files names that are going to annoy most of us
every time we see them.

Kevin

Re: changelog rotation...

[Eli Zaretskii]

On Wed, 17 Jan 2001, Kevin Buettner wrote:

> I'm not sure I understand what the problem is for DOS anyway. 
> ChangeLogs are not buildable, so they don't have to be referred to in
> Makefiles or any other part of the configury, right?

Right.

> And we do have a
> mechanism for mapping colliding names to other (non-colliding) names
> when creating a tar file for such systems, right?

Yes, but: this mechanism for mapping names to prevent collisions is not 
automatic.  It requires that a file (gdb/config/djgpp/fnchange.lst) be 
edited to add any new files that collide, together with their mappings.  
This is an additional maintenance burden I'd like to avoid, especially 
since there's a decision to make the list of colliding names much 
smalled in some distant future by reorganizing the directory structure in 
a way that part of the file names is replaced with a subdirectory.  For 
example, files gdb/config/alpha/alpha-osf2.mh and 
gdb/config/alpha/alpha-osf2.mh will go into a subdirectory 
gdb/config/alpha/alpha under the names osf1.mh and osf2.mh (or something 
like that, the exact example is not important).

> Also, we're going
> to only be adding a new one of these each year; this should not be
> too onerous for the maintainer who has to update the mapping.

These files are not the only ones that are added.  One file per year 
might seem like a small problem, but if it is an Nth plus one file, the 
overall burden is significant.

> That being the case (if it really is the case), I see no reason to
> give the ChangeLog files names that are going to annoy most of us
> every time we see them.

I suggested to make the split be version-based to avoid the annoyance, 
among other reasons.

Re: changelog rotation...

[Eli Zaretskii]

On Wed, 17 Jan 2001, Andrew Cagney wrote:

> > Splitting by version will satisfy the first requirement, while not
> > necessarily contradicting the second.  (I consider a 500KB file to not
> > be ``too large''.  YMMV.)
> 
> Technical point.  Splitting on versions isn't easy.

``Isn't easy'' is my middle name, believe me ;-)  As I've said, I'm
ready to put my money where my mouth is and do whatever is necessary
to rework existing ChangeLog's into split-by-version shape, if that is
the decision.

> You could split
> when the branch occures but then you end up with is argument about where
> to put ChangeLogs made on the branch and merged back into the trunk :-)

When changes from the branch are merged back, you need to merge the
ChangeLog entries as well, with an appropriate banner.  That is the
prudent thing to do anyway.

However, I don't see how this is different now.  When you cut the
branch, don't you cut the ChangeLog files as well?  If you do, the
changes for the branch only appear in the branch ChangeLog's, and need
to be merged back when you switch to the trunk again, no?  What am I
missing?

> > something has to be done to get the CVS sources be usable for
> > the DJGPP port again.
> 
> I should be getting error messages about this and I'm not :-(

Yes, I wondered what happened.  Some problem with the script maybe?

> I guess there are two choices:
> 
> 	ChangeLog-NNNN (unix - 14) -> ChangeLog.NNN (dos 8.3)
> 
> 	ChangeLog.NNN (unix and dos) (we could start numbering from 190 :-)
> 
> Much that I totally hate it the latter has merit in that (if I
> understand correctly) it is similar to what is used used by EMACS

No, Emacs uses ChangeLog.1, ChangeLog.2, ChangeLog.3 etc.  The .N
extensions have nothing to do with the years.  The Emacs ChangeLog's
are generally split by released versions, not by years.

(Emacs also doesn't use branching, btw.)