OpenRISC port ready for inclusion

OpenRISC port ready for inclusion

[Olof Kindgren]

Hi,

My name is Olof and I'm writing as a member of the OpenRISC project.
We have been maintaining ports for a lot of software including
binutils for many years, but we are now trying to push our work
upstream bit by bit. The turn has now come to binutils.

What we have is a repo tracking upstream,a diff against
binutils-2.24.1 and all contributors to the OpenRISC-specific parts
are ready to sign over their respective parts to FSF... so how do we
proceed?

Regards,
Olof Kindgren

Re: OpenRISC port ready for inclusion

[Nicholas Clifton]

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

Hi Olaf,

> What we have is a repo tracking upstream,a diff against
> binutils-2.24.1 and all contributors to the OpenRISC-specific parts
> are ready to sign over their respective parts to FSF... so how do we
> proceed?

Thanks very much for considering contributing this work.  The first step 
is to make sure that all of the copyright holders for the work have FSF 
copyright assignments in place.  (I am attaching the form necessary to 
apply for this assignment in case you need it).

Next, send the patches to the binutils list for review.  It helps if you 
can break the patches down by sub-directory, ie bfd, opcodes, gas, ld 
etc.  It also helps if the code has been written following the GNU 
Coding Standards:

   http://www.gnu.org/prep/standards/

The patches should made against the current development sources and 
should compile without any problems on both 32-bit and 64-bit hosts. 
There is no need to submit patches against generate files (eg configure, 
bfd-in2.h, etc).  It is helpful however if you can include ChangeLog 
entries describing the patches, although these are best presented as 
plain text rather than context diffs.

It is also helpful if you can include some target specific testcases for 
both the assembler and the linker, to verify that the port is working. 
You should also build a toolchain configured with 
"--enable-targets=all", just to make sure that your changes do not 
affect any other targets.

You should also consider who will be maintaining the port.  If the port 
is not going to have a maintainer who will help to look after it then it 
is unlikely to be accepted in the first place.  (Unmaintained code tends 
to bit-rot and cause complications for other targets).

Cheers
   Nick


[-- Attachment #2: request-assign.future --]
[-- Type: text/plain, Size: 965 bytes --]

Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]