Re: solaris is a secondary platform for gcc-4.4
>Benjamin Kosnik <[EMAIL PROTECTED]> writes: > >Given that the set of posted solaris test results for trunk during the >last four months barely requires two hands: > >2008-01 >http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01474.html >http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html >http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html > >2008-02 >http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01519.html > >2008-03 >http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg01093.html >http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg00363.html > >2008-04 >(none) > >I propose moving > >sparc-sun-solaris2.10 > >from primary to secondary on this page: > >http://gcc.gnu.org/gcc-4.4/criteria.html > >Thoughts? > >-benjamin Please maintain Solaris 2.10 as a primary platform. Even though I'm just beginning to learn the GCC internals, I would like to contribute to its development as soon as possible. Like the other posters, we have only recently upgraded to 2.10 here. Robert Kiesling --- Ctalk Home Page: http://www.ctalklang.org/.
Re: Rant about ChangeLog entries and commit messages
[ Charset ISO-8859-1 unsupported, converting... ] > > FWIW, I agree completely - I've never found ChangeLogs useful, I hate > > writing them, and I think the linux-kernel guys these days generally have > > much better checkin messages than we do. > > I guess nobody really loves writing ChangeLog entries, but in my opinion > there > are quite effective "executive summaries" for the patches and helpful to the > reader/reviewer. Please let's not throw the baby with the bath's water. If there's a mechanism to filter checkin messages to ChangeLog summaries, I would be happy to use it - in cases of multiple packages, especially, it's important to know what changes were made, when, and when the changes propagated through packages and releases, and where they got to, occasionally. Anybody know of a useful, built-in mechanism for this task? -- Ctalk Home Page: http://ctalk-lang.sourceforge.net
Re: Rant about ChangeLog entries and commit messages
> On Sun, 2007-12-02 at 09:26 -0500, Robert Kiesling wrote: > > > I guess nobody really loves writing ChangeLog entries, but in my opinion > > > there > > > are quite effective "executive summaries" for the patches and helpful to > > > the > > > reader/reviewer. Please let's not throw the baby with the bath's water. > > > > If there's a mechanism to filter checkin messages to ChangeLog summaries, > > I would be happy to use it - in cases of multiple packages, especially, > > it's > > important to know what changes were made, when, and when the changes > > propagated > > through packages and releases, and where they got to, occasionally. Anybody > > know of a useful, built-in mechanism for this task? > > > > Personally I find it slow and inefficient tracing through why a given > change was made. It is just a slow process searching and sometimes I > don't bother because it is so inconvenient. The ChangeLog entries > provide little help and there does not seem to be a good alternative. If > there is a good alternative no-one has said what it is so far. > > As people have pointed out, the RCSs pretty well cover the "what" these > days. And writing changelog entries, which largely duplicate this > information, is time-consuming and tedious. And there are of of little > to no value to me at least. > > The coding standards do allow, in some cases, that giving some context > would be useful: > > > See also what the GNU Coding Standards have to say about what goes in > > ChangeLogs; in particular, descriptions of the purpose of code and > > changes should go in comments rather than the ChangeLog, though a > > single line overall description of the changes may be useful above the > > ChangeLog entry for a large batch of changes. > > I personally would strongly favour each ChangeLog entry having a single > line of context. This could be the PR number or a single line giving the > purpose of the change or what bigger change it is part of. > > As pointed out by Zach Weinberg in his paper "A Maintenance Programmer's > View of GCC", there are many impediments to contributing to GCC. > > http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf > > Things are not much better than they were when Zach wrote his paper. This > small change would be one positive step n the right direction, IMHO. One line of reference would be sufficient provided that branches other than the main development trunk stick to revisions in that branch only. I haven't glanced through the references yet, but maintenance programming is considerably different than writing new code, or even modifying someone else's code. If it's the latter you're trying to achieve, or anticipate achieving, then an accurate line of reference would be most helpful. Unfortunately, then, _someone_ has to maintain the comments accurately. I wouldn't care to say who (whom?)... just... someone. :) -- Ctalk Home Page: http://ctalk-lang.sourceforge.net
Re: Rant about ChangeLog entries and commit messages
[ Charset ISO-8859-1 unsupported, converting... ] > On 12/3/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > > > Sorry, but again, this is not a good enough justification to me. > > > We do a lot of things different than "The GNU Project". > > > So do plenty of parts of the "official GNU project". > > > They use different coding standards, bug tracking systems, version > > > control systems, checkin policies, etc, than each other. > > > > Yes, but none of those are visible other than to the development community. > > People who obtain the source distributions of projects don't get to see > > those things. They DO see things like the ChangeLog format and coding > > and documentation conventions and THOSE are the things that need to be > > common among GNU projects. > > Except they aren't, across large parts of the GNU project. > > You may find it the same in the "traditional" parts of the GNU project > (IE coreutils, emacs, etc). > It's certainly not the same across any of the newer parts of the GNU project. That's because, although the GNU project strictly - and correctly, experience has shown - monitors its code base, with the propagation of the Free Software development model, newer Free Software contributors who maintain their code on sites like sourceforge.net, are subject to commercial pressures that the older, ivory-tower authors in general are shielded from. It's impossible to convince someone who wants your "niche" for a quickie IPO that maintaining code for more than two or three years is worth the investment. -- Ctalk Home Page: http://www.ctalklang.org/
Re: Rant about ChangeLog entries and commit messages
> Nicholas Nethercote <[EMAIL PROTECTED]> writes: > > > Commit logs are basically invisible; > > That's just a (fixable) problem in your coding setup. In other > projects it is very common to use tools like cvs annotate / cvsps / > git blame / git log / etc. to find the reasons for why code is the way > it is. In fact in several editors these can be functions on hot > keys. Programming is hard enough as is without ignoring such valuable > information sources. Don't do it. Unless there's a good reason _not_ to derive from a source, and there are several, most of which require a clean-room approach, or a simulation of it. I'm just now starting to move over to Subversion, and I'm sure it has the same ability, to publish CVS logs, though not via CVS itself. C-x v u :) -- Ctalk Home Page: http://www.ctalklang.org/
