Re: Heads up: please help documenting *internal* GCC changes for 4.6
On Fri, 28 Jan 2011, Basile Starynkevitch wrote: I am not sure to understand the technical ways to modify that; is CVS still mandatory? Yes, the web pages reside in CVS. Not a lot different from SVN in terms of operations, just `cvs update`, `cvs diff`, `cvs commit` instead of the same svn commands. ;-) On Fri, 28 Jan 2011, Ian Lance Taylor wrote: I would say that any gcc maintainer may update the changes file without explicit review. The patch must be valid HTML, and Gerald runs a script which verifies that. Patches must be sent to gcc-patc...@gcc.gnu.org. Only make changes that are correct. If you feel uncertain, you should get a review. That review can come from any other gcc maintainer. (Anyone: please let me know if you disagree with the above.) I think you hit the nail on the head. I do offer the service of reviewing all web pages, either up front or after the fact, but especially for the release notes nobody should be hesitant. ;-) Realizing that our documentation could, and should, be more clear around this I just applied the following documentation update: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02244.html Gerald
Re: Heads up: please help documenting *internal* GCC changes for 4.6
On Fri, 28 Jan 2011 14:43:28 +0200
Laurynas Biveinis laurynas.bivei...@gmail.com wrote:
I have just added a new section (approved by Gerald) to the bottom of
http://gcc.gnu.org/gcc-4.6/changes.html
Its intention is to mention noteworthy internal changes, i.e. changes
interesting for, say, maintainers of backends/frontends outside the
tree, and of course plugin developers upgrading from 4.5 to 4.6.
I am not sure to understand what is the social rules to modify that. I
suppose that any patch to that page should be approved with the same
strong process as patches to trunk code?
I am not sure to understand the technical ways to modify that; is CVS
still mandatory?
That page says.
The gengtype utility, which previously was internal to the GCC build
process, has been
enchanced to provide GC root information for plugins as necessary.
Perhaps we should mention the gtype.state file also. Unfortunately,
neither gengtype nor gtype.state are installed (unless someone pushed a
patch for that which I did not pay attention to; I certainly didn't).
So perhaps a possible phrasing might eventually become
The gengtype utility, which previously was internal to the GCC build
process, has been enchanced to provide GC root information for plugins
as necessary. The entire internal state of gengtype (describing the
large set of GTY-ed types) is now persistent (in file gtype.state).
Therefore, plugins can use GTY annotations without needing the
availability of the GCC compiler source and build trees
Comments are welcome.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Heads up: please help documenting *internal* GCC changes for 4.6
2011/1/28 Basile Starynkevitch bas...@starynkevitch.net: Its intention is to mention noteworthy internal changes, i.e. changes interesting for, say, maintainers of backends/frontends outside the tree, and of course plugin developers upgrading from 4.5 to 4.6. I am not sure to understand what is the social rules to modify that. I suppose that any patch to that page should be approved with the same strong process as patches to trunk code? It needs to be reviewed, but it's much easier IMHO. I am not sure to understand the technical ways to modify that; is CVS still mandatory? Yes. Perhaps we should mention the gtype.state file also. I think that mentioning gtype.state--very shortly--is a good idea. Would you like to prepare the patch with your suggested wording? -- Laurynas
Re: Heads up: please help documenting *internal* GCC changes for 4.6
Basile Starynkevitch bas...@starynkevitch.net writes: I am not sure to understand what is the social rules to modify that. I suppose that any patch to that page should be approved with the same strong process as patches to trunk code? I would say that any gcc maintainer may update the changes file without explicit review. The patch must be valid HTML, and Gerald runs a script which verifies that. Patches must be sent to gcc-patc...@gcc.gnu.org. Only make changes that are correct. If you feel uncertain, you should get a review. That review can come from any other gcc maintainer. (Anyone: please let me know if you disagree with the above.) I am not sure to understand the technical ways to modify that; is CVS still mandatory? Yes. Ian
Re: Heads up: please help documenting *internal* GCC changes for 4.6
On Jan 28, 2011, at 8:04 AM, Laurynas Biveinis wrote: 2011/1/28 Basile Starynkevitch bas...@starynkevitch.net: Its intention is to mention noteworthy internal changes, i.e. changes interesting for, say, maintainers of backends/frontends outside the tree, and of course plugin developers upgrading from 4.5 to 4.6. I am not sure to understand what is the social rules to modify that. I suppose that any patch to that page should be approved with the same strong process as patches to trunk code? It needs to be reviewed, but it's much easier IMHO. I'm wondering if it would be helpful for the internal changes to be documented in a separate file, rather than in the same file as the user changes. That makes it more obvious what documentation is being touched. paul
