Re: ports to 2.96 and 3.1 versions

Re: ports to 2.96 and 3.1 versions

[mike stump]

> From: "Marko Mlinar" <markom@opencores.org>
> To: <gcc@gcc.gnu.org>
> Cc: <openrisc@opencores.org>
> Date: Thu, 24 Jan 2002 08:27:05 +0100

> Well I've submitted the request for papers lat year, but after the
> investigation they found out that they overlooked them, thus
> delaying the whole process... I am still waiting for them.

:-( I think I liked the process better when we had the papers on our
web site.  :-(  This is why I tell everyone that is starting a port, to
get their paper work in first.  Because by the time they are done,
then it should be finished and on file.  Also, it makes it easier to
contribute as you develop, which increases the likelihood of code
actually getting into gcc.  Too often people do a port, and then
disappear just before or just after they finish.

> Are you currently in Stage 3?

Yes.

> Do we have any chances to be in 3.1 release?

That would be someone elses call.  Depends upon how cleanly your code
drops in.  The cleaner it is, the more likely it might be able to go
in, the less clean, the more invasive the changes, the less likely it
will make the 3.1 release, though, even if it doesn't, it should be
able to make it in for 3.1.1 (if you can clean it up for submission
quality).  Offhand, I'd say slim to none.  It should be dropped into
mainline first, before the release branch.

> Well if not, I suppose the best roadmap for us is to work on 3.1
> (and later on 3.2) version, to meet the next 3.2 release (hopefully)
> on Oct 15th, 2002.

Certainly you will want to contribute it to the main branch just as
soon as 3.1 is cut (branched off).

Re: ports to 2.96 and 3.1 versions

[David Edelsohn]

>>>>> mike stump writes:

>> Do we have any chances to be in 3.1 release?

Mike> That would be someone elses call.  Depends upon how cleanly your code
Mike> drops in.  The cleaner it is, the more likely it might be able to go
Mike> in, the less clean, the more invasive the changes, the less likely it
Mike> will make the 3.1 release, though, even if it doesn't, it should be
Mike> able to make it in for 3.1.1 (if you can clean it up for submission
Mike> quality).  Offhand, I'd say slim to none.  It should be dropped into
Mike> mainline first, before the release branch.

	If the paperwork is in place and the code is accepted into the
mainline, and the changes are localized to new files, the precedent has
been to accept new ports into release branches.  The decision is at the
discretion of the Release Manager.

David

Re: ports to 2.96 and 3.1 versions

[Robert Lipe]

> > Do we have any chances to be in 3.1 release?
> 
> That would be someone elses call.  Depends upon how cleanly your code
> drops in.  The cleaner it is, the more likely it might be able to go
> in, the less clean, the more invasive the changes, the less likely it
> will make the 3.1 release, though, even if it doesn't, it should be
> able to make it in for 3.1.1 (if you can clean it up for submission
> quality).  Offhand, I'd say slim to none.  It should be dropped into
> mainline first, before the release branch.

We really should revisit this process since we have had a couple of ports
recently that are in this same flight pattern.

If we could get the bulky stuff of a new port reviewed, approved, and
installed early, wouldn't that be a Good Thing?  If we could get all the
configury gunk and the totally new files in, there would be no risk to
existing targets and could therefore reasonably go in at this point in
the cycle.

Note that the resulting compiler might not actually *work* on that
target; that's probably OK.  Without asking, I'm sure the new CPU guys
would much rather distribute a few patches to the common files that
are still pending review or are being withheld becuase of development
risk than to distribute their own version or bulky patches.  So if they
needed a fix to a couple common/shared files that we couldn't accept at
this point in the cycle, they could distribute a much smaller patch kit
and not disrupt the targets that are in the release criteria.  It would
also help reduce divergence and merge grief becuaes the guys would be
closer to working in the official trees and would benefit from the bulk
edits that are so frequently done on the back-ends.

Would that work?

RJL

Re: ports to 2.96 and 3.1 versions

[Marc Espie]

This is one place that ought to be completely revisited. The time needed
to process copyright assignment papers is astounding. The fore-knowledge
needed to be able to participate in any FSF process is fairly large (even
knowing that those papers exist is not trivial, choosing which ones to
sign is not easy, and it takes at the least 3 months to do that).

Now, I'm wondering why any of the companies that benefit directly from
GNU software hasn't stepped forward to help organise that. Wouldn't it
make sense to find real finances to process those papers and reduce the
delay from three months/one year to a more reasonable week ?

Re: ports to 2.96 and 3.1 versions

[Paul Koning]

Excerpt of message (sent 27 January 2002) by Marc Espie:
> This is one place that ought to be completely revisited. The time needed
> to process copyright assignment papers is astounding. The fore-knowledge
> needed to be able to participate in any FSF process is fairly large (even
> knowing that those papers exist is not trivial, choosing which ones to
> sign is not easy, and it takes at the least 3 months to do that).

No, it doesn't.

I just went through that process.  It took about 3 weeks.  The reason
it took that long was because of vacations around the new year
holidays.

It may well be that the process could be made simpler (but remember
that this is a legal process, and those tend to be more complex than
you would expect).  And it may be that it sometimes takes too long.
But "at least 3 months" is false.

    paul

Re: ports to 2.96 and 3.1 versions

[Zack Weinberg]

On Mon, Jan 28, 2002 at 10:49:54AM -0500, Paul Koning wrote:
> I just went through that process.  It took about 3 weeks.  The reason
> it took that long was because of vacations around the new year
> holidays.
> 
> It may well be that the process could be made simpler (but remember
> that this is a legal process, and those tend to be more complex than
> you would expect).  And it may be that it sometimes takes too long.
> But "at least 3 months" is false.

It used to take a lot longer than it does now, Marc may be remembering
what it was like then.  For instance, I mailed in my copyright
assignment for GCC at the beginning of September 1998; RMS
countersigned it at the end of September; and I didn't get it back
until April 1999!  However, my understanding is that turnaround time
has been improved considerably.

I don't agree with the decision to remove the forms and explanations
from the web site.  (But then, neither do most of the GCC
maintainers.  I'm sure you remember that argument.)

zw

Re: ports to 2.96 and 3.1 versions

[Joe Buck]

> This is one place that ought to be completely revisited. The time needed
> to process copyright assignment papers is astounding. The fore-knowledge
> needed to be able to participate in any FSF process is fairly large (even
> knowing that those papers exist is not trivial, choosing which ones to
> sign is not easy, and it takes at the least 3 months to do that).

It doesn't take nearly that long unless something goes wrong (that is,
unless someone drops the ball).  But you only hear about the outliers,
because those are the people who (naturally) complain.

> Now, I'm wondering why any of the companies that benefit directly from
> GNU software hasn't stepped forward to help organise that.

Oh, come on.  If a company got involved and asked their legal staff to
help, the process would get *slower*, given the extreme caution and
paranoia of most lawyers.

But if you have a specific suggestion on how to make things better, by
all means send it to RMS (no one on this list has the power to make a
change).

Re: ports to 2.96 and 3.1 versions

[Marc Espie]

On Mon, Jan 28, 2002 at 09:01:51AM -0800, Joe Buck wrote:
> 
> > This is one place that ought to be completely revisited. The time needed
> > to process copyright assignment papers is astounding. The fore-knowledge
> > needed to be able to participate in any FSF process is fairly large (even
> > knowing that those papers exist is not trivial, choosing which ones to
> > sign is not easy, and it takes at the least 3 months to do that).
> 
> It doesn't take nearly that long unless something goes wrong (that is,
> unless someone drops the ball).  But you only hear about the outliers,
> because those are the people who (naturally) complain.

Well, I was speaking from past personal experience.

Apparently, things work better now. I'm fairly happy about it.

Re: ports to 2.96 and 3.1 versions

[Philipp Thomas]

* Zack Weinberg (zack@codesourcery.com) [20020128 17:22]:

> I don't agree with the decision to remove the forms and explanations
> from the web site.

The removal of the explanations I also don't understand, but I now do
understand the removal of the forms. The problem with the forms you print
out yourself is, that they have to be checked closely for alterations when
snailmailed back to the FSF because some people did change the wording of
the disclaimer before printing it out.

Sending out preprinted disclaimers you only have to sign is much easier for
the FSF and those can be signed by the FSF vice president.

What we should be able to do is make the forms for requesting such a
preprinted disclaimer from the FSF via email available from the web pages,
but I don't know if that is allowed.


Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE Linux AG, Deutscherrnstr. 15-19, D-90429 Nuremberg, Germany

Re: ports to 2.96 and 3.1 versions

[Robert Lipe]

[ Should probably drop opencores address from continued discussion. ] 

mike stump wrote:
> > Date: Thu, 24 Jan 2002 13:11:00 -0600
> > From: Robert Lipe <robertlipe@usa.net>
> > To: gcc@gcc.gnu.org
> 
> > We really should revisit this process since we have had a couple of
> > ports recently that are in this same flight pattern.
> 
> You'd need to communicate what you thought was broken with status quo
> and what changes you wanted to see to it and why it would be better.
> Absent at least a suggestion of how it could be made better...  I
> don't know what there is to talk about.

We have formal plan (that's http://gcc.gnu.org/develop.html for those
just tuning in) that is designed to mitigate risk as we iterate closer
to GCC releases.  The problem I'm seeing with the status quo is that we
don't have an exemption for accepting code that isn't risky.  By our
own chart, we could only accept a new CPU core (a truly new one, not
a mutation of an existing one) during statge1 and this could mean a
lengthy delay in getting that port into the tree.

If we'd like to say that the maintainers capable of reviewing a new port
(a known bottleneck) are just likely to be too busy to review/approve
such a port and not hold them out in the name of risk, that seems more
realistic. 

> Bear in mind, sometimes ports are invasive and do contain bugs
> that do affect other platforms.

Understood.  I'm certainly not looking for carte blanche on this.  I'm
asking if we should consider allowing new CPU ports that don't touch any
common files (well, other than configury or doc) in stages other than one.

> I guess the main one is this, can a new port be accepted in stage 3,
> if it is is clean enough in how it affects other ports?  Off hand, I
> don't see much harm in it, other than incomplete work being in the
> tree.  

That's the policy/question I'm trying to get clarified.  My reading is
that a new CPU port could happen only in stage1.  Like you, I'm thinking
it would be a good thing for everyone involved it if could.  If the
port was not cleanly self contained (that "invasive" thing above) those
specific changes might well have to wait.   

> Personally, I'm happy to let the release manager make the call how
> they may, and live with the decision and after we hear more about why
> the process is broken, then decide to change it.  If a release manager
> wanted to document his ideas about new ports and phase 2 or 3 on the
> web site, I think that would be reasonable and help set expectations
> of contributors.  If the steering committee wanted to set policy (and
> document it on the web page), that would seem to be reasonable.  I
> don't see that this _needs_ to be done however.

Maybe we really don't have a hole here or maybe we really don't want to
make an exemption for new ports.  Maybe we don't need a clarification
but the fact that you and I (and apparently Joe) are reading it
differently hints that we may.

I think a clarification of intent is in order.   It's a problem that's
come up at least twice in recent months.


RJL

Re: ports to 2.96 and 3.1 versions

[Marko Mlinar]

> I guess the main one is this, can a new port be accepted in stage 3,
> if it is is clean enough in how it affects other ports?  Off hand, I
> don't see much harm in it, other than incomplete work being in the
> tree.  If we mandate it only goes in as last as stage2, stage3 is
> there to put the finishing touches on the port.  Or, we could accept
> it as late as stage3 because it doesn't affect other ports.
> 
> Personally, I'm happy to let the release manager make the call how
> they may, and live with the decision and after we hear more about why
> the process is broken, then decide to change it.  If a release manager
> wanted to document his ideas about new ports and phase 2 or 3 on the
> web site, I think that would be reasonable and help set expectations
> of contributors.  If the steering committee wanted to set policy (and
> document it on the web page), that would seem to be reasonable.  I
> don't see that this _needs_ to be done however.

Like Damjan said, we have very isolated port, and it should not affect
others in any way. And yes, we would rather have an official port, even
if we have to submit some patches later.

best regards,
Marko

Re: ports to 2.96 and 3.1 versions

[mike stump]

> Date: Thu, 24 Jan 2002 13:11:00 -0600
> From: Robert Lipe <robertlipe@usa.net>
> To: gcc@gcc.gnu.org

> We really should revisit this process since we have had a couple of
> ports recently that are in this same flight pattern.

You'd need to communicate what you thought was broken with status quo
and what changes you wanted to see to it and why it would be better.
Absent at least a suggestion of how it could be made better...  I
don't know what there is to talk about.

> If we could get the bulky stuff of a new port reviewed, approved, and
> installed early, wouldn't that be a Good Thing?

Agreed.

> If we could get all the configury gunk and the totally new files in,
> there would be no risk to existing targets and could therefore
> reasonably go in at this point in the cycle.

Agreed (if the maintainer that is reviewing the patches feels this is
true).  Bear in mind, sometimes ports are invasive and do contain bugs
that do affect other platforms.

> Would that work?

I don't see much disagreement between what you've said, and what
little I know of the policy.


I guess the main one is this, can a new port be accepted in stage 3,
if it is is clean enough in how it affects other ports?  Off hand, I
don't see much harm in it, other than incomplete work being in the
tree.  If we mandate it only goes in as last as stage2, stage3 is
there to put the finishing touches on the port.  Or, we could accept
it as late as stage3 because it doesn't affect other ports.

Personally, I'm happy to let the release manager make the call how
they may, and live with the decision and after we hear more about why
the process is broken, then decide to change it.  If a release manager
wanted to document his ideas about new ports and phase 2 or 3 on the
web site, I think that would be reasonable and help set expectations
of contributors.  If the steering committee wanted to set policy (and
document it on the web page), that would seem to be reasonable.  I
don't see that this _needs_ to be done however.

Re: ports to 2.96 and 3.1 versions

[Marko Mlinar]

>> I am a member of OpenCores (http://www.opencores.org) an open HW
>> community.
>
>I like what you guys are doing, thanks for your hard work.
>
>> We have whole GNU toolchain ready for our CPU (OpenRisc), but we are
>> still waiting for FSF licenses, to make our ports official.

thanks :)

> I assume this means that you are trying to submit your paper work to
> the FSF for the copyright assignments.  The paper work isn't enough to
> make the ports official.  After you have your copyright assignments on
> file, this permits you to submit your work to us for inclusion into
> gcc.  After the inclusion of your work into the main gcc tree, this
> makes it official.  After the release of the code, it then is part of
> an official release of gcc.
Well I've submitted the request for papers lat year, but after the
investigation they found out that they overlooked them, thus
delaying the whole process... I am still waiting for them.

>> When do you expect current version of gcc will be included in
>> official releases of GNU software?
>
>See http://gcc.gnu.org/develop.html, according to it, our best guess
>is Apr 15th, 2002 for the release of gcc 3.1.
ok, I see.
Are you currently in Stage 3?

Do we have any chances to be in 3.1 release?

Our code was tested against our testsuite on the simulator and it appers
everything
works the same as with previous version, except code is a bit better (~3%
less
instructions with -O2, Dhrystone). We are shortly planning to compile
uCLinux and
test it thoughly.

Well if not, I suppose the best roadmap for us is to work on 3.1 (and later
on
3.2) version, to meet the next 3.2 release (hopefully) on Oct 15th, 2002.

best wishes,
Marko

Re: ports to 2.96 and 3.1 versions

[mike stump]

> From: "Marko Mlinar" <markom@opencores.org>
> To: <gcc@gcc.gnu.org>
> Date: Wed, 23 Jan 2002 16:09:23 +0100

> I am a member of OpenCores (http://www.opencores.org) an open HW
> community.

I like what you guys are doing, thanks for your hard work.

> We have whole GNU toolchain ready for our CPU (OpenRisc), but we are
> still waiting for FSF licenses, to make our ports official.

I assume this means that you are trying to submit your paper work to
the FSF for the copyright assignments.  The paper work isn't enough to
make the ports official.  After you have your copyright assignments on
file, this permits you to submit your work to us for inclusion into
gcc.  After the inclusion of your work into the main gcc tree, this
makes it official.  After the release of the code, it then is part of
an official release of gcc.

> For gcc, we have two ports 2.96 and 3.1 (todays version).

2.96 has no planned release by us and likely will not be released by
us.

> When do you expect current version of gcc will be included in
> official releases of GNU software?

See http://gcc.gnu.org/develop.html, according to it, our best guess
is Apr 15th, 2002 for the release of gcc 3.1.

> Since current gcc is not so widely spread yet, and if that is not
> likely to change soon, we would like make an official port to gcc
> version 2 also (if that is possible, of course).

You are free to do a port to any gcc 2.x compiler and put that up on
your web site, but it is very unlikely that we will make such a
release.

Re: ports to 2.96 and 3.1 versions

[Joe Buck]

> I am a member of OpenCores (http://www.opencores.org) an open HW community.
> 
> We have whole GNU toolchain ready for our CPU (OpenRisc), but we are still
> waiting for FSF licenses, to make our ports official.

I'm not sure what you mean by "waiting for FSF licenses".

Have you submitted papers to the FSF assigning your changes to gcc?

> For gcc, we have two ports 2.96 and 3.1 (todays version).

"2.96" is not an FSF release, it is a fork put out by Red Hat.

Only code that works with current CVS sources would be an acceptable
contribution to the official GCC.  Once papers are on file, you can
submit patches for review.  See

http://gcc.gnu.org/contribute.html

for details.

> When do you expect current version of gcc will be included in official
> releases
> of GNU software? Since current gcc is not so widely spread yet, and if that
> is not
> likely to change soon, we would like make an official port to gcc version 2
> also
> (if that is possible, of course).

But you don't have a port to gcc version 2.  "2.96" was a fork based on
an early snapshot of what became gcc 3.0.  Its internal structures are
closer to 3.0 than to the widely used 2.95.x.

> thanks for your help,
> 
> Marko
> 
> 

Re: ports to 2.96 and 3.1 versions

[law]

 In message <20020123101532.A27450@mediaone.net>, Craig Rodrigues writes:
 > On Wed, Jan 23, 2002 at 04:09:23PM +0100, Marko Mlinar wrote:
 > > When do you expect current version of gcc will be included in official
 > > releases
 > > of GNU software?
 > 
 > Look at http://gcc.gnu.org/develop.html.  That should give you
 > a rough idea of when gcc 3.1 will be released.
Also note carefully the timeline as it related to contributions -- there are
guidelines we work within to determine if a particular contribution makes
sense to include at a particular phase in the development/release cycle.

jeff

Re: ports to 2.96 and 3.1 versions

[Craig Rodrigues]

On Wed, Jan 23, 2002 at 04:09:23PM +0100, Marko Mlinar wrote:
> When do you expect current version of gcc will be included in official
> releases
> of GNU software?

Look at http://gcc.gnu.org/develop.html.  That should give you
a rough idea of when gcc 3.1 will be released.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

ports to 2.96 and 3.1 versions

[Marko Mlinar]

Hello!

I am a member of OpenCores (http://www.opencores.org) an open HW community.

We have whole GNU toolchain ready for our CPU (OpenRisc), but we are still
waiting
for FSF licenses, to make our ports official.

For gcc, we have two ports 2.96 and 3.1 (todays version).

When do you expect current version of gcc will be included in official
releases
of GNU software? Since current gcc is not so widely spread yet, and if that
is not
likely to change soon, we would like make an official port to gcc version 2
also
(if that is possible, of course).

thanks for your help,

Marko