4.1 news item

4.1 news item

[Daniel Berlin]

I was thinking we maybe should just copy the checked in project list
from the wiki, remove the duplicates (IE struct aliasing part I and II,
etc), and add a news item saying:

"GCC 4.1 stage 2 is now closed.  The following projects were
contributed: <project list>.  Thank you to all contributors, testers,
and everyone else for making stage 2 of gcc 4.1 a success"

Re: 4.1 news item

[Gerald Pfeifer]

On Fri, 8 Jul 2005, Daniel Berlin wrote:
> I was thinking we maybe should just copy the checked in project list
> from the wiki, remove the duplicates (IE struct aliasing part I and II,
> etc), and add a news item saying:
> 
> "GCC 4.1 stage 2 is now closed.  The following projects were
> contributed: <project list>.  Thank you to all contributors, testers,
> and everyone else for making stage 2 of gcc 4.1 a success"

I like this idea.  Want to go head? ;-)

Gerald

Re: 4.1 news item

[Mark Mitchell]

Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> 
>>I was thinking we maybe should just copy the checked in project list
>>from the wiki, remove the duplicates (IE struct aliasing part I and II,
>>etc), and add a news item saying:
>>
>>"GCC 4.1 stage 2 is now closed.  The following projects were
>>contributed: <project list>.  Thank you to all contributors, testers,
>>and everyone else for making stage 2 of gcc 4.1 a success"
> 
> 
> I like this idea.  Want to go head? ;-)

I was going to wait until midnight to officially announce Stage 3, but, 
heck, let's just consider it pre-announced for 6.75 hours from now, and 
go ahead and update the web site.

Thanks!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.1 news item

[Daniel Berlin]

[-- Attachment #1: Type: text/plain, Size: 570 bytes --]

On Fri, 2005-07-08 at 23:39 +0200, Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> > I was thinking we maybe should just copy the checked in project list
> > from the wiki, remove the duplicates (IE struct aliasing part I and II,
> > etc), and add a news item saying:
> > 
> > "GCC 4.1 stage 2 is now closed.  The following projects were
> > contributed: <project list>.  Thank you to all contributors, testers,
> > and everyone else for making stage 2 of gcc 4.1 a success"
> 
> I like this idea.  Want to go head? ;-)
> 

Here's a patch.


> Gerald

[-- Attachment #2: index.diff --]
[-- Type: text/x-patch, Size: 1273 bytes --]

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.507
diff -u -p -r1.507 index.html
--- index.html	8 Jul 2005 06:50:42 -0000	1.507
+++ index.html	9 Jul 2005 01:01:49 -0000
@@ -84,6 +84,24 @@ mission statement</a>.</p>
 
 <dl>
 
+<dt><b>July 8, 2005</b></dt>
+<dd>
+GCC 4.1 stage 2 has been closed.  The following projects were contributed
+during stage 1 and stage 2: 
+New C Parser, LibAda GNATTools Branch, Code Sinking, Improved phi-opt, Structure Aliasing,
+Autovectorization Enhancements, Hot and Cold Partitioning, SMS Improvements
+Integrated Immediate Uses, Tree Optimizer Cleanups, Variable-argument Optimization,
+Redesigned VEC API, IPA Infrastructure, Altivec Rewrite Warning Message Control,
+New SSA Operand Cache Implementationa, Safe Builtins, Port of IBM Pro Police Stack Detector
+New DECL hierarchy.
+
+More information about these projects can be found at 
+<a href="http://gcc.gnu.org/wiki/GCC%204.1%20Projects">GCC 4.1 projects</a>
+
+Thank you to all contributors, testers, and everyone else for making stage 1 and stage 2 
+of GCC 4.1 a success.
+</dd>
+
 <dt><b>July 7, 2005</b></dt>
 <dd>
 <a href="gcc-4.0/">GCC 4.0.1</a> has been released.

Re: 4.1 news item

[Gerald Pfeifer]

On Fri, 8 Jul 2005, Daniel Berlin wrote:
> Here's a patch.

Thanks.

There are a couple of commas between items missing (usually when
there is a line break) and some of the lines are too long (as with
GCC sources we generally prefer lines no longer than ~77 characters).

Is the new stack checking infrastructure really a port of IBM Pro
Police, or a reimplementation by RTH and Jakub?

Gerald

Re: 4.1 news item

[Steven Bosscher]

On Sunday 10 July 2005 00:16, Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> > Here's a patch.
>
> Thanks.
>
> There are a couple of commas between items missing (usually when
> there is a line break) and some of the lines are too long (as with
> GCC sources we generally prefer lines no longer than ~77 characters).
>
> Is the new stack checking infrastructure really a port of IBM Pro
> Police, or a reimplementation by RTH and Jakub?

RTH said (http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01193.html):

//
The following is a functional re-implementation of the IBM stack
smashing protection patch described here:

  http://www.research.ibm.com/trl/projects/security/ssp/

This version is *much* less intrusive than the IBM version:
//

Looks like a re-implementation to me, then! ;-)

Gr.
Steven

Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

I noticed that the Wiki is getting more and more of a third place where
to find documentation in addition of gcc/doc and wwwdocs, and a parallel
universe at that, with quite some duplication and inconsistencies.

The Wiki is a nice idea for project lists, "Hot Bugzillas" lists and    
similar, but when I see pages like http://gcc.gnu.org/wiki/TestingGCC  
and http://gcc.gnu.org/wiki/HowToPrepareATestcase I really start 
wondering...

Michael, why did you take a wwdocs patch and copy it to the Wiki, 
basically forking our official documentation instead of helping to
improve it?  I'd appreciate a patch to merge improvements into our
documentation and help us avoid (and get rid) of this fork.

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote:
> I noticed that the Wiki is getting more and more of a third place where
> to find documentation in addition of gcc/doc and wwwdocs, and a parallel
> universe at that, with quite some duplication and inconsistencies.

Have you not yet discovered that this is because people find the
documentation we have to be hard to work with, and submitting patches to
write in texinfo and whatnot to be a pain in the ass? 

Some (maybe most, hard to say) people don't like the organization,
topics, etc of our current documentation.  They find it useless to a
large degree to understand how GCC works.

IE i'm talking about developer facing docs, not user facing docs.

In fact, i had someone recently send me a *104 page PDF file* on how RTL
really works organized in a way that most developers would probably find
better.

But it has some spelling errors, was a little rough, etc.  I'm sure if
he submitted it, it would be nitpicked to death, told to convert to
texinfo, blah blah blah.

However, the fact that he found the current documentation *entirely
worthless* enough to write a 104 page document on how everything
actually worked should tell us maybe there is something wrong with our
documentation implementation, what we cover, and how we cover it.

It's not just "out of date" or whatever, people find it fundamentally
not covering the topics they seem to care about (which is how one
actually goes about doing useful things with our intermediate
representation, etc).


> The Wiki is a nice idea for project lists, "Hot Bugzillas" lists and    
> similar, but when I see pages like http://gcc.gnu.org/wiki/TestingGCC  
> and http://gcc.gnu.org/wiki/HowToPrepareATestcase I really start 
> wondering...

It should make you wonder why people felt it easier to do that than
write it in our "official docs".
Not "why do we have a wiki"?

I find it sad that you are complaining that people have created a
resource *they* find useful, instead of one that *we think they should
find useful*.

In reality, you should be taking the docs people found useful, like on
the wiki, and moving them into our developer facing documentation, etc,
instead of saying what seems to be "we shouldn't let people write about
this stuff on the wiki".


> 
> Michael, why did you take a wwdocs patch and copy it to the Wiki, 
> basically forking our official documentation instead of helping to
> improve it?  I'd appreciate a patch to merge improvements into our
> documentation and help us avoid (and get rid) of this fork.
> 
> Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

Sorry for the tone, i've had a frustrating day for other reasons :)

However, my real point still stands:

1. Every developer i've talked to who wants to work on gcc finds our
current docs not useful, both the wwwdocs and the texinfo ones.  Not
because they are out of date, but because they don't give them
information on what they really want to know.
2. If they find the wiki more useful to write down interesting things
they've discovered, how to go about things, or whatever, let them, and
just export the docs from the wiki.  This is simple enough (the wiki
docs are valid xhtml transitional, except for some of the output of
plugins.  But the regular pages are)
3. We should seriously consider writing and maintaining different guides
and references than the ones we have.
I'm happy to go talk to the people who feel this way, and find out what
it is exactly that they want, though i'm pretty sure it's something like

A. Tree language reference guide (ie, semantics, etc)
B. RTL language reference guide (ie, semantics) written in a simple
format like:

RTL Instructions and how they are linked
RTL modes and what they represent.

Then
For each RTL code:

CODE - what it is used for and represents
examples of how operations are represented using CODE
valid flags for CODE
valid macros for CODE

instead of the current:

"here's a bunch of things about rtl.
here's a bunch of things about rtl flags.
Here's a bunch of things about rtl macros.
Here's a small bunch of things about rtl operations.
here's a bunch of things about rtl modes
Here's some more stuff about insns"

C. How to write a basic RTL pass
D. How to write a basic tree-ssa pass
E. Reference guides for analysis providers in tree-ssa (IE what we
provide and how to make use of provided alias info, data dependence
info, immediate uses, etc)
F. Reference guide for analysis providers in RTL.


On Sun, 2005-07-10 at 13:53 -0400, Daniel Berlin wrote:
> On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote:
> > I noticed that the Wiki is getting more and more of a third place where
> > to find documentation in addition of gcc/doc and wwwdocs, and a parallel
> > universe at that, with quite some duplication and inconsistencies.
> 
> Have you not yet discovered that this is because people find the
> documentation we have to be hard to work with, and submitting patches to
> write in texinfo and whatnot to be a pain in the ass? 
> 
> Some (maybe most, hard to say) people don't like the organization,
> topics, etc of our current documentation.  They find it useless to a
> large degree to understand how GCC works.
> 
> IE i'm talking about developer facing docs, not user facing docs.
> 
> In fact, i had someone recently send me a *104 page PDF file* on how RTL
> really works organized in a way that most developers would probably find
> better.
> 
> But it has some spelling errors, was a little rough, etc.  I'm sure if
> he submitted it, it would be nitpicked to death, told to convert to
> texinfo, blah blah blah.
> 
> However, the fact that he found the current documentation *entirely
> worthless* enough to write a 104 page document on how everything
> actually worked should tell us maybe there is something wrong with our
> documentation implementation, what we cover, and how we cover it.
> 
> It's not just "out of date" or whatever, people find it fundamentally
> not covering the topics they seem to care about (which is how one
> actually goes about doing useful things with our intermediate
> representation, etc).
> 
> 
> > The Wiki is a nice idea for project lists, "Hot Bugzillas" lists and    
> > similar, but when I see pages like http://gcc.gnu.org/wiki/TestingGCC  
> > and http://gcc.gnu.org/wiki/HowToPrepareATestcase I really start 
> > wondering...
> 
> It should make you wonder why people felt it easier to do that than
> write it in our "official docs".
> Not "why do we have a wiki"?
> 
> I find it sad that you are complaining that people have created a
> resource *they* find useful, instead of one that *we think they should
> find useful*.
> 
> In reality, you should be taking the docs people found useful, like on
> the wiki, and moving them into our developer facing documentation, etc,
> instead of saying what seems to be "we shouldn't let people write about
> this stuff on the wiki".
> 
> 
> > 
> > Michael, why did you take a wwdocs patch and copy it to the Wiki, 
> > basically forking our official documentation instead of helping to
> > improve it?  I'd appreciate a patch to merge improvements into our
> > documentation and help us avoid (and get rid) of this fork.
> > 
> > Gerald
> 

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote:
| > I noticed that the Wiki is getting more and more of a third place where
| > to find documentation in addition of gcc/doc and wwwdocs, and a parallel
| > universe at that, with quite some duplication and inconsistencies.
| 
| Have you not yet discovered that this is because people find the
| documentation we have to be hard to work with, and submitting patches to
| write in texinfo and whatnot to be a pain in the ass? 


I disagree with the notion that because our current documentation is
imperfect, we shall move the corrected one to the Wiki page.  I think
we've gotten too far in putting valuables bits of GCC outside our main
documentation repository.

[...]

| However, the fact that he found the current documentation *entirely
| worthless* enough to write a 104 page document on how everything
| actually worked should tell us maybe there is something wrong with our
| documentation implementation, what we cover, and how we cover it.

It tells us that the documentation is inaccurate; it does not tell us
that we ought to move it to the Wiki. 

[...]

| I find it sad that you are complaining that people have created a
| resource *they* find useful, instead of one that *we think they should
| find useful*.

The issue is not complaining that people do useful things.  Rather,
whether the updated and and more useful documentation of GCC shall be
moved outside GCC main docuementation sources.  


-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

On Sun, 2005-07-10 at 20:14 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> | On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote:
> | > I noticed that the Wiki is getting more and more of a third place where
> | > to find documentation in addition of gcc/doc and wwwdocs, and a parallel
> | > universe at that, with quite some duplication and inconsistencies.
> | 
> | Have you not yet discovered that this is because people find the
> | documentation we have to be hard to work with, and submitting patches to
> | write in texinfo and whatnot to be a pain in the ass? 
> 
> 
> I disagree with the notion that because our current documentation is
> imperfect, we shall move the corrected one to the Wiki page.  I think
> we've gotten too far in putting valuables bits of GCC outside our main
> documentation repository.

This happens because
1. People don't want to write texinfo, and continually submit patches to
update the docs little by little (remember, people work on docs the same
way they do on code.  Most of the time, what they have written is not
complete yet.  Which is fine for the wiki, but not for our cvs docs, it
seems), whereas this is trivial with the wiki
2. The docs people seem to want to write or use don't fit anywhere in
our current scheme.

> 
> [...]
> 
> | However, the fact that he found the current documentation *entirely
> | worthless* enough to write a 104 page document on how everything
> | actually worked should tell us maybe there is something wrong with our
> | documentation implementation, what we cover, and how we cover it.
> 
> It tells us that the documentation is inaccurate; it does not tell us
> that we ought to move it to the Wiki. 
Sorry, i completely disagree that we should force people who want to
write docs to do it only on our terms, considering how many people like
writing docs and how they write them (little by little in incomplete
pieces)
If people find it easier to write on the wiki, let them.

> 
> [...]
> 
> | I find it sad that you are complaining that people have created a
> | resource *they* find useful, instead of one that *we think they should
> | find useful*.
> 
> The issue is not complaining that people do useful things.  Rather,
> whether the updated and and more useful documentation of GCC shall be
> moved outside GCC main docuementation sources.  
We should be taking what people do and moving it, not saying "you can't
write it where you want".

Re: Some notes on the Wiki (was: 4.1 news item)

[Joseph S. Myers]

On Sun, 10 Jul 2005, Daniel Berlin wrote:

> This happens because
> 1. People don't want to write texinfo, and continually submit patches to
> update the docs little by little (remember, people work on docs the same
> way they do on code.  Most of the time, what they have written is not
> complete yet.  Which is fine for the wiki, but not for our cvs docs, it
> seems), whereas this is trivial with the wiki

Patches for the internals documentation don't need to be complete.  
c-tree.texi and sourcebuild.texi are both clearly marked as incomplete.

> 2. The docs people seem to want to write or use don't fit anywhere in
> our current scheme.

They can just stick a new chapter somewhere vaguely plausible in the 
internals manual - that's what's been done so far.  The structure of the 
internals manual may not be wonderfully coherent, but adding new chapters 
won't make it worse.

> We should be taking what people do and moving it, not saying "you can't
> write it where you want".

This does of course require identifying the authors of all significant 
parts and making sure they have assignments or disclaimers on file at the 
FSF.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| Sorry for the tone, i've had a frustrating day for other reasons :)
| 
| However, my real point still stands:
| 
| 1. Every developer i've talked to who wants to work on gcc finds our
| current docs not useful, both the wwwdocs and the texinfo ones.  Not
| because they are out of date, but because they don't give them
| information on what they really want to know.

Then, let see what information they want and how they can be put there.

[...]

| 3. We should seriously consider writing and maintaining different guides
| and references than the ones we have.
| I'm happy to go talk to the people who feel this way, and find out what
| it is exactly that they want, though i'm pretty sure it's something like
| 
| A. Tree language reference guide (ie, semantics, etc)
| B. RTL language reference guide (ie, semantics) written in a simple
| format like:
| 
| RTL Instructions and how they are linked
| RTL modes and what they represent.
| 
| Then
| For each RTL code:
| 
| CODE - what it is used for and represents
| examples of how operations are represented using CODE
| valid flags for CODE
| valid macros for CODE
| 
| instead of the current:
| 
| "here's a bunch of things about rtl.
| here's a bunch of things about rtl flags.
| Here's a bunch of things about rtl macros.
| Here's a small bunch of things about rtl operations.
| here's a bunch of things about rtl modes
| Here's some more stuff about insns"
| 
| C. How to write a basic RTL pass
| D. How to write a basic tree-ssa pass
| E. Reference guides for analysis providers in tree-ssa (IE what we
| provide and how to make use of provided alias info, data dependence
| info, immediate uses, etc)
| F. Reference guide for analysis providers in RTL.

I see no reason why those should not be part of our main
documentation reposotroty along with or replacing our traditional
documentation.


It appears to me that you're relating unrelated effects and causes.

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Sun, 2005-07-10 at 20:14 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <dberlin@dberlin.org> writes:
| > 
| > | On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote:
| > | > I noticed that the Wiki is getting more and more of a third place where
| > | > to find documentation in addition of gcc/doc and wwwdocs, and a parallel
| > | > universe at that, with quite some duplication and inconsistencies.
| > | 
| > | Have you not yet discovered that this is because people find the
| > | documentation we have to be hard to work with, and submitting patches to
| > | write in texinfo and whatnot to be a pain in the ass? 
| > 
| > 
| > I disagree with the notion that because our current documentation is
| > imperfect, we shall move the corrected one to the Wiki page.  I think
| > we've gotten too far in putting valuables bits of GCC outside our main
| > documentation repository.
| 
| This happens because
| 1. People don't want to write texinfo, and continually submit patches to
| update the docs little by little (remember, people work on docs the same
| way they do on code.  Most of the time, what they have written is not
| complete yet.  Which is fine for the wiki, but not for our cvs docs, it
| seems), whereas this is trivial with the wiki
| 2. The docs people seem to want to write or use don't fit anywhere in
| our current scheme.

Then, let's extend that scheme (no, I exclude Wiki :-))

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

> It appears to me that you're relating unrelated effects and causes.

Not really.
People don't contribute to the current docs for the following main
reasons, AFAICT and have heard from people, *in order of number of
complaints i've heard from people*:

1. They don't want to send continual incomplete patches, they'd rather
update it in small bites on their own time schedule, without getting
nitpicked to death as often happens on doc patches (hence the reason you
see stuff done on wiki, where this is easily possible)

2. The current docs don't cover what they want to talk about.

3. They don't like texinfo, they don't want to edit it.

These are all related causes of the effect that our documentation and
the process behind it hasn't worked for as long as i've been hacking gcc
(5 or 6 years now).  Everyone seems to pretend "oh, it's just the damn
lazy developers fault, they don't update docs".  Have you ever
considered there may be reasons for this, other than lazy developers,
like the above?

I'm not sure why we, as someone else put it, ignore the implicit
feedback from developers about our docs, and the process, and just try
to force everyone to do what we want, when they just end up not doing it
or doing the bare minimum as a result. 

I'm not saying a complete free for all is the best process here, but
it's pretty clear at least to me that what we do now in terms of
developer docs, and how we do it, plain old doesn't work well. So maybe
it's time to try something else, and work *with* people who want to be
writing docs, instead of just trying to hammer people into following the
current process?

--Dan

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

[...]

| These are all related causes of the effect that our documentation and
| the process behind it hasn't worked for as long as i've been hacking gcc
| (5 or 6 years now).  Everyone seems to pretend "oh, it's just the damn
| lazy developers fault, they don't update docs".  Have you ever
| considered there may be reasons for this, other than lazy developers,
| like the above?

That is a question I would have loved answered did I endorse its
predicate. 

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[David Edelsohn]

>>>>> Gabriel Dos Reis writes:

Gaby> That is a question I would have loved answered did I endorse its
Gaby> predicate. 

	Then by all means continue to use the existing docs in your world
and let others create more useful documentation for developers in our
world, which appears to be on a different plane of existence.

David

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Sun, 10 Jul 2005, Daniel Berlin wrote:
> I find it sad that you are complaining that people have created
> a resource *they* find useful, instead of one that *we think they
> should find useful*.

I'm sure you are aware of the fact that I am not responsible for 
gcc/doc/*.texi as such.  The main reason I'm listed as doc co-maintainer 
is so that I can help, as far as I can in terms of what I know, to get 
changes approved/applied and maintain install.texi and contrib.texi.

There are, it seems, at least two different issues here: one is that our 
manuals seem not to be satisfactory, especially for new developers. And 
one is the documentation of our policies, procedures, timelines, etc. on 
the web pages.

> In reality, you should be taking the docs people found useful, like on
> the wiki, and moving them into our developer facing documentation, etc,

As far as reviewing/applying/approving patches for wwwdocs is concerned, 
and implementing suggestions sent to the GCC lists, I'm committed to do 
that, and do so within one "online day" if possible in any way.

However, I just don't have the bandwidth to dig through Wiki and port 
things over, and it's not exactly an efficient nor motivating modus 
operandi either.

> instead of saying what seems to be "we shouldn't let people write
> about this stuff on the wiki".

Really, it depends on what "this stuff" is.  Duplicating official 
information from the regular web pages simply does not seem very
fruitful (and risks inconsistencies), and taking a wwwdocs patch
and putting it into the Wiki as Michael did as opposed to providing
feeback just seems counter productive.

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Sun, 10 Jul 2005, Daniel Berlin wrote:
> 1. Every developer i've talked to who wants to work on gcc finds our
> current docs not useful, both the wwwdocs and the texinfo ones.  Not
> because they are out of date, but because they don't give them
> information on what they really want to know.

I'd like to know what's missing on wwwdocs and try to fix that.

> 3. We should seriously consider writing and maintaining different guides
> and references than the ones we have.

Nobody won't object to that, I guess.

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Steven Bosscher]

On Sunday 10 July 2005 20:14, Gabriel Dos Reis wrote:
> The issue is not complaining that people do useful things.  Rather,
> whether the updated and and more useful documentation of GCC shall be
> moved outside GCC main docuementation sources.

This is just a matter of where a contributor wants to add it.  If you
think it should be moved else where, move it elsewhere.

Gr.
Steven

Re: Some notes on the Wiki (was: 4.1 news item)

[Andrew Pinski]

On Jul 10, 2005, at 1:31 PM, Gerald Pfeifer wrote:

> I noticed that the Wiki is getting more and more of a third place where
> to find documentation in addition of gcc/doc and wwwdocs, and a 
> parallel
> universe at that, with quite some duplication and inconsistencies.
>
> The Wiki is a nice idea for project lists, "Hot Bugzillas" lists and
> similar, but when I see pages like http://gcc.gnu.org/wiki/TestingGCC
> and http://gcc.gnu.org/wiki/HowToPrepareATestcase I really start
> wondering...


HowToPrepareATestcase was submitted but never reviewed which is why it
moved to the wiki. Giovanni Bajo pinged it at least twice.  And then
someone suggesting to put into the wiki so it would be some where and
still easy to find.

-- Pinski

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Sun, 10 Jul 2005, Andrew Pinski wrote:
> HowToPrepareATestcase was submitted but never reviewed which is why it
> moved to the wiki.

It was reviewed the very same day it was submitted:

  http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
  http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

On Sun, 2005-07-10 at 22:50 +0200, Gerald Pfeifer wrote:
> On Sun, 10 Jul 2005, Daniel Berlin wrote:
> > I find it sad that you are complaining that people have created
> > a resource *they* find useful, instead of one that *we think they
> > should find useful*.
> 
> I'm sure you are aware of the fact that I am not responsible for 
> gcc/doc/*.texi as such. 

Of course.

>  The main reason I'm listed as doc co-maintainer 
> is so that I can help, as far as I can in terms of what I know, to get 
> changes approved/applied and maintain install.texi and contrib.texi.

Yup.

> 
> There are, it seems, at least two different issues here: one is that our 
> manuals seem not to be satisfactory, especially for new developers. And 
> one is the documentation of our policies, procedures, timelines, etc. on 
> the web pages.

Yup.

> 
> > In reality, you should be taking the docs people found useful, like on
> > the wiki, and moving them into our developer facing documentation, etc,
> 
> As far as reviewing/applying/approving patches for wwwdocs is concerned, 
> and implementing suggestions sent to the GCC lists, I'm committed to do 
> that, and do so within one "online day" if possible in any way.

I understand, and you've been great about approving what is sent.
I don't mean to disrepect that in any way.

> 
> However, I just don't have the bandwidth to dig through Wiki and port 
> things over, and it's not exactly an efficient nor motivating modus 
> operandi either.
I would submit them from the wiki if i felt people found more use for it
in wwwdocs.
Otherwise, why not just link from the approriate page to it in the wiki?

> Really, it depends on what "this stuff" is.  Duplicating official 
> information from the regular web pages simply does not seem very
> fruitful (and risks inconsistencies), and taking a wwwdocs patch
> and putting it into the Wiki as Michael did as opposed to providing
> feeback just seems counter productive.

See Andrew's message.

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

David Edelsohn <dje@watson.ibm.com> writes:

| >>>>> Gabriel Dos Reis writes:
| 
| Gaby> That is a question I would have loved answered did I endorse its
| Gaby> predicate. 
| 
| 	Then by all means continue to use the existing docs in your world
| and let others create more useful documentation for developers in our
| world, which appears to be on a different plane of existence.

?

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Gerald Pfeifer <gerald@pfeifer.com> writes:

| > 3. We should seriously consider writing and maintaining different guides
| > and references than the ones we have.
| 
| Nobody won't object to that, I guess.

Indeed.

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

[...]

| > However, I just don't have the bandwidth to dig through Wiki and port 
| > things over, and it's not exactly an efficient nor motivating modus 
| > operandi either.
| I would submit them from the wiki if i felt people found more use for it
| in wwwdocs.
| Otherwise, why not just link from the approriate page to it in the wiki?

I would rather prefer we find a way to get the docs in sync and in
wwwdocs. 

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Kaveh R. Ghazi]

 > In fact, i had someone recently send me a *104 page PDF file* on how
 > RTL really works organized in a way that most developers would
 > probably find better.

So share it with the masses, put it in the wiki.

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Some notes on the Wiki

[R Hill]

Gerald Pfeifer wrote:
> As far as reviewing/applying/approving patches for wwwdocs is concerned, 
> and implementing suggestions sent to the GCC lists, I'm committed to do 
> that, and do so within one "online day" if possible in any way.

I'd like to applaud you for that effort.

> However, I just don't have the bandwidth to dig through Wiki and port 
> things over, and it's not exactly an efficient nor motivating modus 
> operandi either.

What about considering the wiki as documentation in progress?  Once the 
author(s) is satisfied with the work it could be submitted for review 
and inclusion in the official docs.  I think someone even mentioned 
hacking up a wikisyntax to texi converter a while back that could make 
this more streamlined.

>> instead of saying what seems to be "we shouldn't let people write
>> about this stuff on the wiki".
> 
> Really, it depends on what "this stuff" is.  Duplicating official 
> information from the regular web pages simply does not seem very
> fruitful (and risks inconsistencies), and taking a wwwdocs patch
> and putting it into the Wiki as Michael did as opposed to providing
> feeback just seems counter productive.

Providing feedback takes time and requires follow-up.  Hitting edit on a 
wiki page gets it done /now/ and out of the way.  It may not be the most 
logical or correct way to do things, but it's more comfortable and 
suited to how people write (docs or otherwise).  The easier it is for 
people to write documentation, the better quality documentation they'll 
write.

One other point:  it's far less nerve-wracking for someone new to the 
project to add something to the wiki than go through the review process. 
  Yes, that might make little sense to experienced contributors.  Yes, 
it's still true.  ;)


--de.

Re: Some notes on the Wiki

[Paolo Bonzini]

> In fact, i had someone recently send me a *104 page PDF file* on how RTL
> really works organized in a way that most developers would probably find
> better.

If the guy has copyright assignment on file, I can volunteer to convert 
this.  Is the PDF made from latex?  If so I have some scripts to aid.

Paolo

Re: Some notes on the Wiki

[Paolo Bonzini]

> > It was reviewed the very same day it was submitted:
> > 
> >   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
> >   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html

where you said:

 > (and possibly to your tutorial as a separate page if
 > it still seems desirable to have it as a coherent tutorial).

The page ended up on the wiki rather than wwwdocs.

Paolo

Re: Some notes on the Wiki

[Paolo Bonzini]

> > It was reviewed the very same day it was submitted:
> > 
> >   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
> >   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html

where you said:

 > (and possibly to your tutorial as a separate page if
 > it still seems desirable to have it as a coherent tutorial).

The page ended up on the wiki rather than wwwdocs.

Paolo

Re: Some notes on the Wiki (was: 4.1 news item)

[Giovanni Bajo]

Gerald Pfeifer <gerald@pfeifer.com> wrote:

> It was reviewed the very same day it was submitted:
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html

Yes. And the review was very detailed, and suggested that I had to redone to
work almost from scratch, scattering the infos across a dozen of files in
both WWW and TeX format where they really belong (including Dejagnu's
documentation), *plus* I could also provide the existing page as a tutorial
with references.

I would like to thank you and Joseph Myers for the accurate and fast review.
The point is that it took me already long enough to prepare that patch, and
I never had time (nor will, let me admit) to go back and redo the work in a
different way.

What happened next is that I started providing the link to the gcc-patches
mail over IRC, and then in the list, and then in private mail. And people
were thanking me for it, because it was very helpful. So, I realized that,
while the improvements you suggested were legitimate and correct, that text
was already very useful *the way it is* *right now*. So, it was put in the
Wiki. And I know many people have read it and found it useful. If you want,
you can add a plea at the bottom of the Wiki page, summing the reviews and
asking volunteers to incorporate it into the documentation in the proper
places.

I already expressed my concerns about the way documentation patches work in
other threads. I myself am uninterested in contributing documentation
patches to TeX (and pretty discouraged about the WWW patches, even if I do
that regularly, as you well know). Instead, I contributed many things to the
Wiki. Given the way things like Wikipedia work out, I think we need to
either review our documentation system, or, if there is too much politics
going on with the FSF, accept the fact that the documentation *is* going to
be forked, and setup a workflow to contribute stuff back from the wiki to
the official documentation.

My personal position is that making documentation patches *blocked* by
review (as happens with code) is wrong. The worst thing it can happen is
that the documentation patch is wrong, and the doc maintainer can revert it
in literally seconds (using the Wiki; in minutes/hours using the TeX).
Nobody is going to be blocked by this; no bootstrap will be broken; no wrong
code will be generated. This ain't code. In many common cases, the
documentation will be useful effectively immediatly, and
typos/subtleties/formatting can be refined by others over time.
-- 
Giovanni Bajo

Re: Some notes on the Wiki (was: 4.1 news item)

[Joseph S. Myers]

On Mon, 11 Jul 2005, Giovanni Bajo wrote:

> My personal position is that making documentation patches *blocked* by
> review (as happens with code) is wrong. The worst thing it can happen is
> that the documentation patch is wrong, and the doc maintainer can revert it
> in literally seconds (using the Wiki; in minutes/hours using the TeX).

It's not for the doc maintainer to know whether most doc patches are 
correct or not; it should be the maintainer of the relevant parts of the 
compiler who reviews them in general.

> Nobody is going to be blocked by this; no bootstrap will be broken; no wrong
> code will be generated. This ain't code. In many common cases, the

Wrong code will be generated when someone relies on subtly wrong 
information in the documentation.  It is a well-established failure mode 
even on the best wikis (i.e. Wikipedia) that someone inserts subtly wrong 
information because of not knowing better (or not knowing that there is 
controversy among experts about which of two versions is correct) and this 
does not get corrected soon if at all.  There may be *policies* of 
providing references to back up claims made, but (a) that can't work in 
the context of GCC and (b) I don't see Wikipedia edits routinely getting 
reverted simply for lack of substantiating evidence.  We're dealing with 
subtle matters where there may be no one expert on the subject, and where 
reversion may not in general be any better than applying the patch: where 
the proper response will involve discussion of the individual edit to 
clarify the basis for the claims made and whether things should be 
refined.

Perhaps the wiki could automatically send all changes to gcc-patches to 
assist in review?

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Some notes on the Wiki (was: 4.1 news item)

[Giovanni Bajo]

Joseph S. Myers <joseph@codesourcery.com> wrote:

>> Nobody is going to be blocked by this; no bootstrap will be broken; no
>> wrong code will be generated. This ain't code. In many common cases, the
>
> Wrong code will be generated when someone relies on subtly wrong
> information in the documentation.  It is a well-established failure mode
> even on the best wikis (i.e. Wikipedia) that someone inserts subtly wrong
> information because of not knowing better (or not knowing that there is
> controversy among experts about which of two versions is correct) and this
> does not get corrected soon if at all.

That is right, but there are level of interests. The debate can be on some
small detail, while the big picture is still good enough for beginners or
intermediates. Having something which is possibly wrong on some subtle
details is still better than having nothing at all. As I said, I am a strong
sustainer of "commit now, refine later".

> (b) I don't see Wikipedia edits routinely getting
> reverted simply for lack of substantiating evidence.

Yeah, but I widely use it and it is still very useful. It may not be 1000%
correct in each word, so what? Are printed books any better? Or is there a
real only truth? We're entering philosphy here. What is certain is that
Wikipedia wouldn't be 1/1000th of that if there was a review process for
each patch being submitted.

> Perhaps the wiki could automatically send all changes to gcc-patches to
> assist in review?


I strongly support this (and was going to suggest this myself). I'd rather
it be another list though, say wiki-patches or doc-patches, because of the
amount of traffic that is going to be generated (think of all those small
typo fixes, or spam reverts).
-- 
Giovanni Bajo

Re: Some notes on the Wiki

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Paolo Bonzini wrote:
>>> It was reviewed the very same day it was submitted:
>>>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
>>>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html
> where you said:
>> (and possibly to your tutorial as a separate page if
>> it still seems desirable to have it as a coherent tutorial).
> The page ended up on the wiki rather than wwwdocs.

I don't necessarily disagree, but that was Joseph, not me.

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Giovanni Bajo wrote:
>> Perhaps the wiki could automatically send all changes to gcc-patches to
>> assist in review?
> I strongly support this (and was going to suggest this myself). I'd rather
> it be another list though, say wiki-patches or doc-patches, because of the
> amount of traffic that is going to be generated (think of all those small
> typo fixes, or spam reverts).

Sounds like an interesting idea!

(For example, it might help those volunteering to integrate stuff from 
Wiki to the gcc/doc or wwwdocs documentation, modulo the open copyright
assignment question.)

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Steven Bosscher]

On Monday 11 July 2005 23:34, Gerald Pfeifer wrote:
> On Mon, 11 Jul 2005, Giovanni Bajo wrote:
> >> Perhaps the wiki could automatically send all changes to gcc-patches to
> >> assist in review?
> >
> > I strongly support this (and was going to suggest this myself). I'd
> > rather it be another list though, say wiki-patches or doc-patches,
> > because of the amount of traffic that is going to be generated (think of
> > all those small typo fixes, or spam reverts).
>
> Sounds like an interesting idea!
>
> (For example, it might help those volunteering to integrate stuff from
> Wiki to the gcc/doc or wwwdocs documentation, modulo the open copyright
> assignment question.)

Another idea that was coined on IRC is to have reviewing and commit
after approval rules for the user manual, but to allow patches to the
internals manual in without review.  Is that something people are
willing to consider and discuss?

Gr.
Steven

Re: Some notes on the Wiki (was: 4.1 news item)

[Joseph S. Myers]

On Mon, 11 Jul 2005, Steven Bosscher wrote:

> Another idea that was coined on IRC is to have reviewing and commit
> after approval rules for the user manual, but to allow patches to the
> internals manual in without review.  Is that something people are
> willing to consider and discuss?

Rather than getting rid of review for the internals manual altogether, I 
think we should appoint more maintainers who can commit without review and 
review other people's patches.

It's *already* the case that if you are the listed maintainer of part of 
the compiler you also maintain documentation related to that part and 
don't need review for such documentation.  Perhaps some parts of the 
compiler need more maintainers.  In addition, if someone makes good 
contributions to the documentation in a particular area they can be made a 
maintainer for that part of the documentation.

Note that a maintainer who isn't confident of a patch within an area they 
maintain can still ask for review if they wish.  Review isn't meant to get 
in the way of people who know what they are doing in an area and know 
enough to know when they need review.  It is meant to provide a check on 
work by people with insufficient expertise to tell when review is 
appropriate.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Steven Bosscher wrote:
> Another idea that was coined on IRC is to have reviewing and commit
> after approval rules for the user manual, but to allow patches to the
> internals manual in without review.  Is that something people are
> willing to consider and discuss?

I think this needs to be decided by the current maintainers in question 
(that is, those who generally make or review patches to the internals
manual), but I'd be fine with that.

On Mon, 11 Jul 2005, Joseph S. Myers wrote:
> Perhaps some parts of the compiler need more maintainers.  In addition, 
> if someone makes good contributions to the documentation in a particular 
> area they can be made a maintainer for that part of the documentation.

Absolutely, on both regards.

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Steven Bosscher <stevenb@suse.de> writes:

| On Monday 11 July 2005 23:34, Gerald Pfeifer wrote:
| > On Mon, 11 Jul 2005, Giovanni Bajo wrote:
| > >> Perhaps the wiki could automatically send all changes to gcc-patches to
| > >> assist in review?
| > >
| > > I strongly support this (and was going to suggest this myself). I'd
| > > rather it be another list though, say wiki-patches or doc-patches,
| > > because of the amount of traffic that is going to be generated (think of
| > > all those small typo fixes, or spam reverts).
| >
| > Sounds like an interesting idea!
| >
| > (For example, it might help those volunteering to integrate stuff from
| > Wiki to the gcc/doc or wwwdocs documentation, modulo the open copyright
| > assignment question.)
| 
| Another idea that was coined on IRC is to have reviewing and commit
| after approval rules for the user manual, but to allow patches to the
| internals manual in without review.  Is that something people are
| willing to consider and discuss?

the idea that we don't review internal manual is worrysome.  Some
years ago, I based a work on doc/c-tree.texi (thanks Mark!).  But the
fact that it escaped continual revision as code gets added or improved
made it a dangerous documentation, because it led to writing codes
based on semantics that was no longer true.  Got bugs, but don't know
which side is not working prorperly.  Similarly, we don't really want
to let doc patches in without double-check.

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Steven Bosscher]

On Tuesday 12 July 2005 00:06, Gabriel Dos Reis wrote:
> Steven Bosscher <stevenb@suse.de> writes:
> | Another idea that was coined on IRC is to have reviewing and commit
> | after approval rules for the user manual, but to allow patches to the
> | internals manual in without review.  Is that something people are
> | willing to consider and discuss?
>
> the idea that we don't review internal manual is worrysome.  Some
> years ago, I based a work on doc/c-tree.texi (thanks Mark!).  But the
> fact that it escaped continual revision as code gets added or improved
> made it a dangerous documentation, because it led to writing codes
> based on semantics that was no longer true.  Got bugs, but don't know
> which side is not working prorperly.  Similarly, we don't really want
> to let doc patches in without double-check.

Think about what you are saying: "Because almost nobody is working on
the internals manual, the documentation bit-rotted."

One way to get more people to work on the internals manual is by taking
away the barriers.

Gr.
Steven

Re: Some notes on the Wiki (was: 4.1 news item)

[Joe Buck]

On Tue, Jul 12, 2005 at 12:07:01AM +0200, Gerald Pfeifer wrote:
> On Mon, 11 Jul 2005, Steven Bosscher wrote:
> > Another idea that was coined on IRC is to have reviewing and commit
> > after approval rules for the user manual, but to allow patches to the
> > internals manual in without review.  Is that something people are
> > willing to consider and discuss?
> 
> I think this needs to be decided by the current maintainers in question 
> (that is, those who generally make or review patches to the internals
> manual), but I'd be fine with that.

What if we had a clean way to flag reviewed and unreviewed text for the
internals manual?  This could be easier with a wiki; when first entered
the text might be (for example) red, and then it would change to black
when a reviewer approves it.  That way material can be added quickly by
developers and we can keep track of what has been checked or not checked.

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Steven Bosscher <stevenb@suse.de> writes:

| On Tuesday 12 July 2005 00:06, Gabriel Dos Reis wrote:
| > Steven Bosscher <stevenb@suse.de> writes:
| > | Another idea that was coined on IRC is to have reviewing and commit
| > | after approval rules for the user manual, but to allow patches to the
| > | internals manual in without review.  Is that something people are
| > | willing to consider and discuss?
| >
| > the idea that we don't review internal manual is worrysome.  Some
| > years ago, I based a work on doc/c-tree.texi (thanks Mark!).  But the
| > fact that it escaped continual revision as code gets added or improved
| > made it a dangerous documentation, because it led to writing codes
| > based on semantics that was no longer true.  Got bugs, but don't know
| > which side is not working prorperly.  Similarly, we don't really want
| > to let doc patches in without double-check.
| 
| Think about what you are saying: "Because almost nobody is working on
| the internals manual, the documentation bit-rotted."

In fact, you just invented that and you're trying to credit me fort
it?  No, thanks.  Stick to what I wrote and if you think there is
something unclear, please ask.  But refrain from crediting me for
something I did not say.

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

| On Mon, 11 Jul 2005, Steven Bosscher wrote:
| 
| > Another idea that was coined on IRC is to have reviewing and commit
| > after approval rules for the user manual, but to allow patches to the
| > internals manual in without review.  Is that something people are
| > willing to consider and discuss?
| 
| Rather than getting rid of review for the internals manual altogether, I 
| think we should appoint more maintainers who can commit without review and 
| review other people's patches.

I 100% agree.  

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

On Mon, 2005-07-11 at 15:21 -0700, Joe Buck wrote:
> On Tue, Jul 12, 2005 at 12:07:01AM +0200, Gerald Pfeifer wrote:
> > On Mon, 11 Jul 2005, Steven Bosscher wrote:
> > > Another idea that was coined on IRC is to have reviewing and commit
> > > after approval rules for the user manual, but to allow patches to the
> > > internals manual in without review.  Is that something people are
> > > willing to consider and discuss?
> > 
> > I think this needs to be decided by the current maintainers in question 
> > (that is, those who generally make or review patches to the internals
> > manual), but I'd be fine with that.
> 
> What if we had a clean way to flag reviewed and unreviewed text for the
> internals manual?  This could be easier with a wiki; when first entered
> the text might be (for example) red, and then it would change to black
> when a reviewer approves it.  That way material can be added quickly by
> developers and we can keep track of what has been checked or not checked.
> 
> 

This is probably possible, but may be easier with other wiki software,
but if that was the direction we wanted to take, i'm happy to convert
us.

Re: 4.1 news item

[Daniel Berlin]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Sun, 2005-07-10 at 00:16 +0200, Gerald Pfeifer wrote:
> On Fri, 8 Jul 2005, Daniel Berlin wrote:
> > Here's a patch.
> 
> Thanks.
> 
> There are a couple of commas between items missing (usually when
> there is a line break)
fixed.

>  and some of the lines are too long (as with
> GCC sources we generally prefer lines no longer than ~77 characters).

Fixed.

> 
> Is the new stack checking infrastructure really a port of IBM Pro
> Police, or a reimplementation by RTH and Jakub?

Reimplementation, but that was the item listed in the wiki.
I'll change both.

How about now?

> 
> Gerald

[-- Attachment #2: index.diff --]
[-- Type: text/x-patch, Size: 1293 bytes --]

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.507
diff -u -p -r1.507 index.html
--- index.html	8 Jul 2005 06:50:42 -0000	1.507
+++ index.html	17 Jul 2005 01:33:55 -0000
@@ -84,6 +84,25 @@ mission statement</a>.</p>
 
 <dl>
 
+<dt><b>July 8, 2005</b></dt>
+<dd>
+GCC 4.1 stage 2 has been closed.  The following projects were contributed
+during stage 1 and stage 2: 
+New C Parser, LibAda GNATTools Branch, Code Sinking, Improved phi-opt, 
+Structure Aliasing, Autovectorization Enhancements, Hot and Cold Partitioning,
+SMS Improvements, Integrated Immediate Uses, Tree Optimizer Cleanups, 
+Variable-argument Optimization, Redesigned VEC API, IPA Infrastructure, 
+Altivec Rewrite Warning Message Control, New SSA Operand Cache Implementation, 
+Safe Builtins, Reimplementation of IBM Pro Police Stack Detector, 
+New DECL hierarchy.
+
+More information about these projects can be found at 
+<a href="http://gcc.gnu.org/wiki/GCC%204.1%20Projects">GCC 4.1 projects</a>
+
+Thank you to all contributors, testers, and everyone else for making stage 1 and stage 2 
+of GCC 4.1 a success.
+</dd>
+
 <dt><b>July 7, 2005</b></dt>
 <dd>
 <a href="gcc-4.0/">GCC 4.0.1</a> has been released.

Re: 4.1 news item

[Gerald Pfeifer]

On Sat, 16 Jul 2005, Daniel Berlin wrote:
> How about now?

Thanks for the update, Dan!

I saw that I had forgot to preapprove this in my previous message, so I 
went ahead an installed the patch right away (after updating the date and 
removing the "Thanks" part which we haven't doing historically).

Gerald

Re: Some notes on the Wiki

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Steven Bosscher wrote:
> Unless we are going to require reviewing for wiki changes now, too,
> there is no point in this entire discussion.

I beg to disagree: first, we again raised the GFDL issue with RMS,
we may have some new volunteers to help with web pages/documentation,
got some discussions on the Wiki going (partly including RMS as well),
and put some of the true motiviations for (not) doing specific things
on the table.  All of these are useful in my book.

Gerald

Re: Some notes on the Wiki

[Alexandre Oliva]

On Jul 11, 2005, Daniel Berlin <dberlin@dberlin.org> wrote:

> In fact, a lot of projects don't even bother to distribute anything but
> HTML docs anymore (regardless of how they browse it).

And that's a pity, because it's a bit of a pain to turn the output of
grep -r regexp docs/HTML into something the browser will display
properly, especially when there are multiple hits.

The stand-alone info tool just rules at that; it's invaluable to
search GCC docs like that.  Having dozens of web pages instead would
make such searches intolerable.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: Some notes on the Wiki

[Robert Thorpe]

 -------- Original Message --------
> From: Daniel Berlin <dberlin@dberlin.org>
> Sent: Monday, July 11, 2005 1:28 PM
> To: rthorpe@realworldtech.com
> Subject: Re: Some notes on the Wiki
> 
> On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
> > >     I believe the Wiki is an invaluable documentation tool, precisely
> > >     because it allows such an unencumbered contribution process.
> > >    
> > > I agree.  I wasn't suggesting that the Wiki has no value, but rather
> > > that it's not a substitute for the more formal documentation.  Were it
> > > not for copyright issues, one could view the Wiki as an ongoing draft
> > > process for the documentation.
> > 
> > A comment from a user...
> > 
> > Please, please, please don't move GCC internals documentation to a Wiki.
> > 
> Nobody has suggested that we wouldn't ship docs.

Great
 
> > Even to users the internals documentation is useful.  It's useful when trying to find out why GCC is doing the things it does with the code given to it, it indicates where to look to find things in the source. 
> 
> >  This would be much harder if it were a wiki, in particular finding information on the version of GCC you're using would be much more difficult.
> 
> However, this isn't true.  The wiki stores every version of a page. We
> could make sure we know what versions of the wiki pages refer to what
> releases, and link them accordingly.

Please do that if you're going to use the wiki seriously for lots of docs.

> > Also, a web-browser is much slower than an info-browser, especially when doing searchs.
> 
> You must be close to the only user i've met who uses the info browser :)

When I said "an info-browser" I meant info-browsers in general, not standalone info in particular. Both Emacs and stand-alone info are fast (I think the Vim one is too).
I use Emacs Info, but the standalone browser is useful on Cygwin; it means you don't need to install Emacs just to read the cygwin docs.

Anyway, it doesn't matter much if your going to keep the docs in texi format,  people who want pdf's or html can generate those formats.

Re: Some notes on the Wiki

[Bernd Schmidt]

Kurt Wall wrote:
> On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write:
> 
>>On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
>>
>>>Also, a web-browser is much slower than an info-browser, especially 
>>>when doing searchs.
>>
>>You must be close to the only user i've met who uses the info browser :)
> 
> 
> We haven't met, but I use the info browser. :-) I used to hate it but
> finally decided that since texi was the format that existed, I might
> as well suck it up and learn to use it.

I learned how to use it more than a decade ago when I was playing with 
gcc-2.3.3 on my Amiga :-)  Can't say I really really like it, but at 
least you can quickly search through the whole file, which isn't so easy 
with most browsers when you have multiple pages of HTML documentation.


Bernd

Re: Some notes on the Wiki

[Kurt Wall]

On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write:
> On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
> > Also, a web-browser is much slower than an info-browser, especially 
> > when doing searchs.
> 
> You must be close to the only user i've met who uses the info browser :)

We haven't met, but I use the info browser. :-) I used to hate it but
finally decided that since texi was the format that existed, I might
as well suck it up and learn to use it.

Kurt
-- 
"I thought you were trying to get into shape."
"I am. The shape I've selected is a triangle."

Re: Some notes on the Wiki

[Andreas Schwab]

Daniel Berlin <dberlin@dberlin.org> writes:

> Let's see. The last time i tried to use info (the program) was about 6 
> weeks ago, 

I was refering to a recent version, not a recent use.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Some notes on the Wiki

[Daniel Berlin]

> >  
> >
> I just had a quick quiz in the C++ IRC channel I was in, and very few
> people there like info, and very few are comfortable using it. There was
> a general agreement HTML, PDF and docbook are the best ways to recieve
> documentation.
> 
> Chris

It's possible these people ride the short development bus too, which
apparently i do :(

Re: Some notes on the Wiki

[chris jefferson]

Gabriel Dos Reis wrote:

>Daniel Berlin <dberlin@dberlin.org> writes:
>
>| On Mon, 11 Jul 2005, Nicholas Nethercote wrote:
>| 
>| > On Mon, 11 Jul 2005, Daniel Berlin wrote:
>| >
>| >>> Also, a web-browser is much slower than an info-browser,
>| >>> especially when doing searchs.
>| >> You must be close to the only user i've met who uses the info
>| >> browser :)
>| >
>| > I use it.  Info pages suck in many ways, but they're fast to load
>| > from an xterm, fast to search, and even faster when you know where
>| > they are in the docs (eg. I find myself looking at the GCC C
>| > extensions quite often, and I can get there very quickly).
>| 
>| Most people i've met can't undertand the commands for info (pinfo is
>| nicer in this regard).
>
>maybe the conclusion to draw is that you've met some special people in
>a small part of the community.
>
>  
>
I just had a quick quiz in the C++ IRC channel I was in, and very few
people there like info, and very few are comfortable using it. There was
a general agreement HTML, PDF and docbook are the best ways to recieve
documentation.

Chris

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 11 Jul 2005, Andreas Schwab wrote:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
>> Most people i've met can't undertand the commands for info (pinfo is
>> nicer in this regard).
>
> There exist many alternative info browsers (this includes konqueror).

Yet the amount of docs available in info is dwindling :)
And in fact, most of the ones i see on my system are mostly for the gnu 
development things (ddd, gdb, gcc, make, gmp, glibc) and emacs packages 
(viper, gnus).

>
>> Those who use info religiously seem to be emacs users, not "info browser"
>> users.
>
> I bet you have never used any recent version of info (the program).

Let's see. The last time i tried to use info (the program) was about 6 
weeks ago, 
when i was trying to get info about a function in glibc.
I could not for the life of me determine why it felt the need to jump 
topics when i was just trying to scroll up or down more.

I'm in the "I hate info" camp, and happily so.  I'm happy that most docs 
i want to view are either hyperlinked pdf or searchable html.

Anyhoo, this is offtopic

--Dan

Re: Some notes on the Wiki

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| On Mon, 11 Jul 2005, Nicholas Nethercote wrote:
| 
| > On Mon, 11 Jul 2005, Daniel Berlin wrote:
| >
| >>> Also, a web-browser is much slower than an info-browser,
| >>> especially when doing searchs.
| >> You must be close to the only user i've met who uses the info
| >> browser :)
| >
| > I use it.  Info pages suck in many ways, but they're fast to load
| > from an xterm, fast to search, and even faster when you know where
| > they are in the docs (eg. I find myself looking at the GCC C
| > extensions quite often, and I can get there very quickly).
| 
| Most people i've met can't undertand the commands for info (pinfo is
| nicer in this regard).

maybe the conclusion to draw is that you've met some special people in
a small part of the community.

-- Gaby

Re: Some notes on the Wiki

[Andreas Schwab]

Daniel Berlin <dberlin@dberlin.org> writes:

> Most people i've met can't undertand the commands for info (pinfo is 
> nicer in this regard).

There exist many alternative info browsers (this includes konqueror).

> Those who use info religiously seem to be emacs users, not "info browser" 
> users.

I bet you have never used any recent version of info (the program).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 11 Jul 2005, Nicholas Nethercote wrote:

> On Mon, 11 Jul 2005, Daniel Berlin wrote:
>
>>> Also, a web-browser is much slower than an info-browser, especially when 
>>> doing searchs.
>> 
>> You must be close to the only user i've met who uses the info browser :)
>
> I use it.  Info pages suck in many ways, but they're fast to load from an 
> xterm, fast to search, and even faster when you know where they are in the 
> docs (eg. I find myself looking at the GCC C extensions quite often, and I 
> can get there very quickly).

Most people i've met can't undertand the commands for info (pinfo is 
nicer in this regard).
Those who use info religiously seem to be emacs users, not "info browser" 
users.
Hence my surprise.

--Dan

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 22:47 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> [...]
> 
> | > Also, a web-browser is much slower than an info-browser, especially when doing searchs.
> | 
> | You must be close to the only user i've met who uses the info browser :)
> 
> Ahem; is your world that small?

No, i'm actually talking about ~50 users from all walk of life and no
relation to each other (which is a pretty statistically significant
sample)

In fact, a lot of projects don't even bother to distribute anything but
HTML docs anymore (regardless of how they browse it).

> 
> -- Gaby

Re: Some notes on the Wiki

[Nicholas Nethercote]

On Mon, 11 Jul 2005, Daniel Berlin wrote:

>> Also, a web-browser is much slower than an info-browser, especially 
>> when doing searchs.
>
> You must be close to the only user i've met who uses the info browser :)

I use it.  Info pages suck in many ways, but they're fast to load from an 
xterm, fast to search, and even faster when you know where they are in the 
docs (eg. I find myself looking at the GCC C extensions quite often, and I 
can get there very quickly).

Nick

Re: Some notes on the Wiki

[Paul Koning]

>>>>> "Kevin" == Kevin Handy <kth@srv.net> writes:

 Kevin> Paul Koning wrote:
 >>>>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:
 >>>>>>> 
 >>>>>>> 
 >>
 Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
 >> >> I also could convert parts of the ggcinternals manual into wiki
 >> >> pages.  But only if there is a consensus about this being the
 >> way >> to go.
 >> 
 Joseph> I'm sure it's the wrong way to go.  I find a properly
 Joseph> formatted and indexed book far more convenient for learning
 Joseph> about substantial areas of compiler internals, or for finding
 Joseph> what some particular macro is specified to do, than a wiki.
 >> I'll second that.  Unlike some other major GNU projects, GCC's
 >> internals manual is substantial and very good.  Yes, it needs
 >> ongoing improvement, but I'd prefer that rather than flipping to
 >> Twiki.
 >> 
 Kevin> In order to show how good the internals documents are, try to
 Kevin> build a very simple front end using ONLY the documentation.
 Kevin> Make it of the order of a hardwired "int main() { return 0}".
 Kevin> Or better yet, find an outsider who knows C, but not GCC
 Kevin> internals, to write it.

 Kevin> No outside source can be used (i.e. no source code not
 Kevin> included in the documentation).

 Kevin> It cannot be done. Not even close. Not even if you allow
 Kevin> tree.def.

Quite true.  On the other hand, for backends things are in far better
shape.  And for my comment on other projects, compare the GCC
internals doc with the internals doc for GDB -- you'll see the point.

	  paul

Re: Some notes on the Wiki

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

[...]

| > Also, a web-browser is much slower than an info-browser, especially when doing searchs.
| 
| You must be close to the only user i've met who uses the info browser :)

Ahem; is your world that small?

-- Gaby

Re: Some notes on the Wiki

[Kevin Handy]

Paul Koning wrote:

>>>>>>"Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:
>>>>>>            
>>>>>>
>
> Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
> >> I also could convert parts of the ggcinternals manual into wiki
> >> pages.  But only if there is a consensus about this being the way
> >> to go.
>
> Joseph> I'm sure it's the wrong way to go.  I find a properly
> Joseph> formatted and indexed book far more convenient for learning
> Joseph> about substantial areas of compiler internals, or for finding
> Joseph> what some particular macro is specified to do, than a wiki.
>
>I'll second that.  Unlike some other major GNU projects, GCC's
>internals manual is substantial and very good.  Yes, it needs ongoing
>improvement, but I'd prefer that rather than flipping to Twiki.
>
>  
>
In order to show how good the internals documents are, try to
build a very simple front end using ONLY the documentation.
Make it of the order of a hardwired "int main() { return 0}".
Or better yet, find an outsider who knows C, but not GCC
internals, to write it.

No outside source can be used (i.e. no source code not included
in the documentation).

It cannot be done. Not even close. Not even if you allow tree.def.

Too much stuff exists outside of the documentation.

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
> >     I believe the Wiki is an invaluable documentation tool, precisely
> >     because it allows such an unencumbered contribution process.
> >    
> > I agree.  I wasn't suggesting that the Wiki has no value, but rather
> > that it's not a substitute for the more formal documentation.  Were it
> > not for copyright issues, one could view the Wiki as an ongoing draft
> > process for the documentation.
> 
> A comment from a user...
> 
> Please, please, please don't move GCC internals documentation to a Wiki.
> 
Nobody has suggested that we wouldn't ship docs.

> Even to users the internals documentation is useful.  It's useful when trying to find out why GCC is doing the things it does with the code given to it, it indicates where to look to find things in the source. 

>  This would be much harder if it were a wiki, in particular finding information on the version of GCC you're using would be much more difficult.

However, this isn't true.  The wiki stores every version of a page. We
could make sure we know what versions of the wiki pages refer to what
releases, and link them accordingly.


> 
> Also, a web-browser is much slower than an info-browser, especially when doing searchs.

You must be close to the only user i've met who uses the info browser :)

> 
> 
> 
> 

Re: Some notes on the Wiki

[Robert Thorpe]

>     I believe the Wiki is an invaluable documentation tool, precisely
>     because it allows such an unencumbered contribution process.
>    
> I agree.  I wasn't suggesting that the Wiki has no value, but rather
> that it's not a substitute for the more formal documentation.  Were it
> not for copyright issues, one could view the Wiki as an ongoing draft
> process for the documentation.

A comment from a user...

Please, please, please don't move GCC internals documentation to a Wiki.

Even to users the internals documentation is useful.  It's useful when trying to find out why GCC is doing the things it does with the code given to it, it indicates where to look to find things in the source.  This would be much harder if it were a wiki, in particular finding information on the version of GCC you're using would be much more difficult.

Also, a web-browser is much slower than an info-browser, especially when doing searchs.

Re: Some notes on the Wiki

[Mike Stump]

On Monday, July 11, 2005, at 08:30 AM, Steven Bosscher wrote:
> In practice, people have already contributed significants amount of
> documentation as comment because they disagree with the GFDL.

I'm of the opinion we never should have allowed the GFDL into our 
source tree, no thanks should have been our response.  I'd like to urge 
the SC to pester the FSF on this point continuously until they relent.  
I keep hoping it was just an experiment that one day the FSF will see 
the errors of their ways and just stop.  That, or they will try and 
introduce yet more non-freeisms into the source code base, we should 
uniformly reject all such incursions.

Re: Some notes on the Wiki

[Richard Kenner]

    I believe the Wiki is an invaluable documentation tool, precisely
    because it allows such an unencumbered contribution process.

I agree.  I wasn't suggesting that the Wiki has no value, but rather
that it's not a substitute for the more formal documentation.  Were it
not for copyright issues, one could view the Wiki as an ongoing draft
process for the documentation.

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 15:19 +0000, Joseph S. Myers wrote:
> On Mon, 11 Jul 2005, Steven Bosscher wrote:
> 
> > On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> > > Steven Bosscher wrote:
> > > > I guess that, apart from the legal discussion of whether this enough,
> > > > such a statement would not apply to existing content.  It was certainly
> > > > not my intention to sign over the various Wiki contributions I have
> > > > made to the FSF.
> > >
> > > This strikes me as shortsighted.
> > 
> > Call it what you will.  For me it is a matter of choice and freedom.
> > 
> > > If we're getting into a situation 
> > > where we can't freely move documentation from one place to another,
> > > we're shooting ourselves in the foot.
> > 
> > We already can't do that.  We can't move documentation from the manual
> > into the code, and vice versa, because of the GPL vs. GFDL issue.  It
> > is that kind of thing that completely takes away any motivation I might
> > otherwise have to contribute to the manual.
> 
> 1. If GCC developers wish to move documentation from the GPL code to the 
> GFDL manuals, or vice versa, what procedures need to be followed?
> 
> 2. Do existing GCC copyright assignments cover the GCC Wiki 
> <http://gcc.gnu.org/wiki/>?
> 

No, and again, i don't understand why we can't do what *everyone else on
the planet who transfers docs between the two do* and just make users
agree that they are giving the right to do that when they submit
contributions to the wiki.


See, for example, the wikipedia contribution page.
"
________________________________________________________________________
DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!
      * you agree that all contributions to any page on Wikipedia are
        released under the GNU Free Documentation License (see
        Project:Copyrights for details).
      * If you do not want your writing to be edited mercilessly and
        redistributed at will, do not submit it.
      * By submitting your work you promise you wrote it yourself, or
        copied it from public domain resources—this does not include
        most web page."

Re: Some notes on the Wiki

[Steven Bosscher]

*sigh*

> To play the Devil's advocate: One could argue that someone contributing
> to the GCC code under the GPL does not agree with the GFDL, and therefore
> the FSF can't live up to its promise (that iirc it makes in the copyright
> assignment) to keep the code under a free license.
... if comments from that code are moved into the manual,

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 17:21, Andrew Haley wrote:
>  > We already can't do that.  We can't move documentation from the manual
>  > into the code, and vice versa, because of the GPL vs. GFDL issue.
>
> Actually, that's not true because *we* (or to be accurate the FSF) own
> the copyright on both.

To play the Devil's advocate: One could argue that someone contributing
to the GCC code under the GPL does not agree with the GFDL, and therefore
the FSF can't live up to its promise (that iirc it makes in the copyright
assignment) to keep the code under a free license.

In practice, people have already contributed significants amount of
documentation as comment because they disagree with the GFDL.

Gr.
Steven

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 16:22 +0200, Steven Bosscher wrote:
> On Monday 11 July 2005 16:19, Diego Novillo wrote:
> > Would a blanket statement at the start of the wiki be enough?
> > Who gets to decide this?
> 
> I guess that, apart from the legal discussion of whether this enough,
> such a statement would not apply to existing content.  It was certainly
> not my intention to sign over the various Wiki contributions I have
> made to the FSF.
We can't get copyright assignments, we can however get effective online
estoppel agreements, like wikipedia does.

This should be enough for documentation, one would hope.

Re: Some notes on the Wiki

[Andrew Haley]

Steven Bosscher writes:
 > On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
 > > Steven Bosscher wrote:
 > > > I guess that, apart from the legal discussion of whether this enough,
 > > > such a statement would not apply to existing content.  It was certainly
 > > > not my intention to sign over the various Wiki contributions I have
 > > > made to the FSF.
 > >
 > > This strikes me as shortsighted.
 > 
 > Call it what you will.  For me it is a matter of choice and freedom.
 > 
 > > If we're getting into a situation 
 > > where we can't freely move documentation from one place to another,
 > > we're shooting ourselves in the foot.
 > 
 > We already can't do that.  We can't move documentation from the manual
 > into the code, and vice versa, because of the GPL vs. GFDL issue.

Actually, that's not true because *we* (or to be accurate the FSF) own
the copyright on both.

 > It is that kind of thing that completely takes away any motivation
 > I might otherwise have to contribute to the manual.
 > 
 > And again, if you're going to require reviewing and copyright assignment
 > for wiki contributions, we might as well not have a wiki at all.

Good idea.

Andrew.

Re: Some notes on the Wiki

[Joseph S. Myers]

On Mon, 11 Jul 2005, Steven Bosscher wrote:

> On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> > Steven Bosscher wrote:
> > > I guess that, apart from the legal discussion of whether this enough,
> > > such a statement would not apply to existing content.  It was certainly
> > > not my intention to sign over the various Wiki contributions I have
> > > made to the FSF.
> >
> > This strikes me as shortsighted.
> 
> Call it what you will.  For me it is a matter of choice and freedom.
> 
> > If we're getting into a situation 
> > where we can't freely move documentation from one place to another,
> > we're shooting ourselves in the foot.
> 
> We already can't do that.  We can't move documentation from the manual
> into the code, and vice versa, because of the GPL vs. GFDL issue.  It
> is that kind of thing that completely takes away any motivation I might
> otherwise have to contribute to the manual.

1. If GCC developers wish to move documentation from the GPL code to the 
GFDL manuals, or vice versa, what procedures need to be followed?

2. Do existing GCC copyright assignments cover the GCC Wiki 
<http://gcc.gnu.org/wiki/>?

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Some notes on the Wiki

[Haren Visavadia]

> --- Diego Novillo wrote:
> > Sorry, I don't understand what you're asking.
> > 
> > My line of thought was described in the text that
> > you removed:
> > "However, it would be very useful for us to
> transfer
> > information
> > from the wiki into the manual from time to time."
> > 
I am suggesting is if the content is on Wiki and not
in the manual and you can not get the copyright
assignment, there is nothing you can do about it
except live with it.
 
In fact, you would be lucky to have the content on
Wiki.
 


		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> Steven Bosscher wrote:
> > I guess that, apart from the legal discussion of whether this enough,
> > such a statement would not apply to existing content.  It was certainly
> > not my intention to sign over the various Wiki contributions I have
> > made to the FSF.
>
> This strikes me as shortsighted.

Call it what you will.  For me it is a matter of choice and freedom.

> If we're getting into a situation 
> where we can't freely move documentation from one place to another,
> we're shooting ourselves in the foot.

We already can't do that.  We can't move documentation from the manual
into the code, and vice versa, because of the GPL vs. GFDL issue.  It
is that kind of thing that completely takes away any motivation I might
otherwise have to contribute to the manual.

And again, if you're going to require reviewing and copyright assignment
for wiki contributions, we might as well not have a wiki at all.

Gr.
Steven

Re: Some notes on the Wiki

[Bernd Schmidt]

Steven Bosscher wrote:
> I guess that, apart from the legal discussion of whether this enough,
> such a statement would not apply to existing content.  It was certainly
> not my intention to sign over the various Wiki contributions I have
> made to the FSF.

This strikes me as shortsighted.  If we're getting into a situation 
where we can't freely move documentation from one place to another, 
we're shooting ourselves in the foot.


Bernd

Re: Some notes on the Wiki

[Diego Novillo]

On Mon, Jul 11, 2005 at 03:41:25PM +0100, Haren Visavadia wrote:
> --- Diego Novillo wrote:
> > And we cannot
> > do that if we don't have cleared out the copyright
> > assignment of
> > wiki content.
> 
> And so?
> 
Sorry, I don't understand what you're asking.

My line of thought was described in the text that you removed:
"However, it would be very useful for us to transfer information
from the wiki into the manual from time to time."


Diego.

Re: Some notes on the Wiki

[Haren Visavadia]

--- Diego Novillo wrote:
> And we cannot
> do that if we don't have cleared out the copyright
> assignment of
> wiki content.

And so?




		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 16:19, Diego Novillo wrote:
> Would a blanket statement at the start of the wiki be enough?
> Who gets to decide this?

I guess that, apart from the legal discussion of whether this enough,
such a statement would not apply to existing content.  It was certainly
not my intention to sign over the various Wiki contributions I have
made to the FSF.

Gr.
Steven

Re: Some notes on the Wiki

[Diego Novillo]

On Mon, Jul 11, 2005 at 04:10:56PM +0200, Steven Bosscher wrote:

> So, contribute to the manual then.  And let the folks who prefer to
> work on the wiki work on the wiki.
> 
I believe the Wiki is an invaluable documentation tool, precisely
because it allows such an unencumbered contribution process.
Also, some of the things documented in the wiki are either
inappropriate for the manual or too dynamic in nature.  I can see
both co-existing for a long time.

However, it would be very useful for us to transfer information
from the wiki into the manual from time to time.  And we cannot
do that if we don't have cleared out the copyright assignment of
wiki content.

Would a blanket statement at the start of the wiki be enough?
Who gets to decide this?


Diego.

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 15:54, Paul Koning wrote:
> >>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:
>
>  Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
>  >> I also could convert parts of the ggcinternals manual into wiki
>  >> pages.  But only if there is a consensus about this being the way
>  >> to go.
>
>  Joseph> I'm sure it's the wrong way to go.  I find a properly
>  Joseph> formatted and indexed book far more convenient for learning
>  Joseph> about substantial areas of compiler internals, or for finding
>  Joseph> what some particular macro is specified to do, than a wiki.
>
> I'll second that.  Unlike some other major GNU projects, GCC's
> internals manual is substantial and very good.  Yes, it needs ongoing
> improvement, but I'd prefer that rather than flipping to Twiki.

So, contribute to the manual then.  And let the folks who prefer to
work on the wiki work on the wiki.

Unless we are going to require reviewing for wiki changes now, too,
there is no point in this entire discussion.  And if we are going
to require reviewing for the wiki, there is no point in having the
wiki.

Gr.
Steven

Re: Some notes on the Wiki

[Russell Shaw]

Joseph S. Myers wrote:
> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
> 
>>I also could convert parts of the ggcinternals manual into wiki pages.
>>But only if there is a consensus about this being the way to go.
> 
> I'm sure it's the wrong way to go.  I find a properly formatted and 
> indexed book far more convenient for learning about substantial areas of 
> compiler internals, or for finding what some particular macro is specified 
> to do, than a wiki.  And since some people seem to think the internal 
> manual is of no use: it's the first place I refer to for information on 
> the areas of internals it covers; after that source code and mailing list 
> archives, the wiki very rarely.
> 
> I think the wiki is certainly useful for rough notes such as 
> <http://gcc.gnu.org/wiki/general%20backend%20cleanup>, synthesised from 
> mailing list discussions.
> 
> It may be useful as an intermediate step in putting together 
> reverse-engineered information about internals in order to specify it 
> properly in the internals manual - but only provided authorship and 
> copyright assignment information is rigorously tracked as required by the 
> FSF.

Just put in a clause that copyright of all additions automatically
reverts to FSF.

Re: Some notes on the Wiki

[Michael Cieslinski]

I converted this patch because I thought it would be helpful after
reading this message from Giovanni Bajo:
http://gcc.gnu.org/ml/gcc/2005-03/msg00552.html
> 
> I had provided this patch in the past, but was rejected:
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
> 
> I never had time to split, rewrite in tex, and update it as requested.
> Janis recently incorporated some parts into the internal manuals, but I
> believe that we still nedd provide a "tutorial for GCC testcase 
> writing". Like I'm trying to explain in another thread, I believe that
> we are being way too picky on www/documentation patches than we should
> be.
> 
> For instance, my patch could have been committed immediatly and been
> refined over time. In fact, I should find a couple of hours to add it
> to the Wiki.
> -- 
> Giovanni Bajo
> 

From my point of view the wiki is THE place for documentation. It is very
easy to put new things in, edit or correct it. I'm familiar with it but I
never used texinfo nor did I ever sent a patch.

I look daily at the wiki and check if somebody puts spam in it. 

I would also propose to make the wiki the primary source of documentation
and derive a static html page from it which could be downloaded and used
locally.

I volunteer to convert the 104 page RTL pdf into wiki pages (if Daniel
sends it to me).

I also could convert parts of the ggcinternals manual into wiki pages.
But only if there is a consensus about this being the way to go.


Michael Cieslinski