From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: craig@jcb-sc.com Cc: egcs@egcs.cygnus.com Subject: Re: 1.1.2 bug, news lists Date: Fri, 19 Mar 1999 23:45:00 -0000 Message-id: <1534.921909896@upchuck> In-reply-to: Your message of 19 Mar 1999 02:19:04 GMT. < 19990319021904.14950.qmail@deer > References: <19990319021904.14950.qmail@deer> X-SW-Source: 1999-03/msg00685.html In message < 19990319021904.14950.qmail@deer >you write: > Right. Did you notice I modified the g77install.texi sources to the > non-egcs stuff doesn't get generated for some variants? E.g. the > Info docs produced by building an egcs release won't, I hope, end up > with the non-egcs stuff, while those produced from the mainline (always > a development snapshot) or your nightly html-producing scripts (useful > for the general g77 audience) will. Everyone will see the notices about > subsequent material not applying to egcs, though. I hadn't yet. But I hope to soon as part of the installation guide revamp that I'd like to get into egcs-1.2. > At least a consistent infrastructure would be useful. Something that > permits a range of maintenance from none<->overkill, with g77 being > somewhat on the "overkill" side (AFAICT), for example. Yes. This is one of those issues where we're trying to merge multiple projects with different ideas of how to handle news, bugs, and the like. > I gather there are still clusters of people who like to print out > complete manuals, bind them, put them on their shelves, and, especially > pertinent for projects like this, point their managers at them and say > things like "see, this free-software stuff is *serious*, they actually > write real documentation". Yup. There's still some folks like this -- myself included. They should still have that capability, the difference is instead of N separate manuals, they'll have M manuals. > Sounds good to me. And, since we ship sources for everything, it's > not a Big Project for us to offers users *choice* regarding how to > put their manuals together -- not much more than agreeing on how > such choices are to be made and implemented, e.g. GNU-wide. Right. Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: craig@jcb-sc.com Cc: egcs@egcs.cygnus.com Subject: Re: 1.1.2 bug, news lists Date: Wed, 31 Mar 1999 23:46:00 -0000 Message-ID: <1534.921909896@upchuck> References: <19990319021904.14950.qmail@deer> X-SW-Source: 1999-03n/msg00690.html Message-ID: <19990331234600.1sSj7tMk3W4F0W7VKTcHhZVDUicYTmflFMe6PPeqIck@z> In message < 19990319021904.14950.qmail@deer >you write: > Right. Did you notice I modified the g77install.texi sources to the > non-egcs stuff doesn't get generated for some variants? E.g. the > Info docs produced by building an egcs release won't, I hope, end up > with the non-egcs stuff, while those produced from the mainline (always > a development snapshot) or your nightly html-producing scripts (useful > for the general g77 audience) will. Everyone will see the notices about > subsequent material not applying to egcs, though. I hadn't yet. But I hope to soon as part of the installation guide revamp that I'd like to get into egcs-1.2. > At least a consistent infrastructure would be useful. Something that > permits a range of maintenance from none<->overkill, with g77 being > somewhat on the "overkill" side (AFAICT), for example. Yes. This is one of those issues where we're trying to merge multiple projects with different ideas of how to handle news, bugs, and the like. > I gather there are still clusters of people who like to print out > complete manuals, bind them, put them on their shelves, and, especially > pertinent for projects like this, point their managers at them and say > things like "see, this free-software stuff is *serious*, they actually > write real documentation". Yup. There's still some folks like this -- myself included. They should still have that capability, the difference is instead of N separate manuals, they'll have M manuals. > Sounds good to me. And, since we ship sources for everything, it's > not a Big Project for us to offers users *choice* regarding how to > put their manuals together -- not much more than agreeing on how > such choices are to be made and implemented, e.g. GNU-wide. Right. Jeff