This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Manual patch: terminology
"Joseph S. Myers" <jsm@polyomino.org.uk> writes:
> On Tue, 3 Feb 2004, James Morrison wrote:
>
> > This plan may generate more traffic than you want. However, what happened
>
> gcc-patches runs fine at >100 messages a day. If contributors send their
> proposed patches and rationale individually over the period of a few
> months over which a manual edition is prepared, and are willing to engage
> in the usual discussion of those patches and iteration to an acceptable
> version, I don't see a problem in getting them reviewed.
Good point.
> > Anyway, I'm not too sure if the above story has any meaning. However, I
> > think what I would like to see is to have a branch off of the release branch
> > for the gnupress manual which could be regularily merged one or both ways.
> > Obviously merging back into mainline would require the normal procedure,
> > but I don't think a gnupress branch would require anything too special.
>
> It shouldn't be a matter of merging back into mainline; changes need to go
> on mainline first before the release branch, and I can't think of any
> manual changes likely to be disruptive in a way that would merit a
> development branch rather than going direct to mainline (and the
> appropriate release branch) in the first instance. Having a gnupress
> branch wouldn't stop people from vanishing as soon as the manual had been
> prepared without completing the responsibility to merge changes back into
> mainline.
>
> --
> Joseph S. Myers
> jsm@polyomino.org.uk
You are right, a separate branch wouldn't stop people from disappearing.
I was just thinking of a branch off mainline that could have changes that
shouldn't go into the non-printed manual. I think you have dealt with those
situations with the FSFPRINT macro.
Jim