quite a bit needs to be done and I personally think it's unlikely any new architectures will make it in time for the jessie freeze at this point.I would like to share the ppc64el port's status with you, and check if it is feasible to consider it as an official port for the next Debian release, or, what it may be missing for that.
The first step is going to be persuading the ftp masters to let you into the debian archive. You can see the ftpmasters critera at https://ftp-master.debian.org/archive-criteria.html . It sounds like the main thing you will need to do to meet them is push your fixes into debian proper so ppc64el can be built without external patches. Merely submitting patches to the BTS for issues specific to your architecture is not sufficient. You will almost certainly have to perform non-maintainer uploads (NMUs) to deal with unresponsive maintainers. While in principle you can ask for sponsorship for NMUs if you want to actually get things moving in a reasonable timeframe you will need at least one Debian Developer (DD) on your team to upload them.
You will also need at least one DD on the port team to satisfy the ftpmaster critera. Ideally you want more.
Another question the ftpmasters will likely have is what is the relationship between ppc64 and ppc64el. Is there hardware that will run ppc64 but not ppc64el? is there hardware that will run ppc64el but not ppc64? is there hardware that will run both? what is the relative prevalance of each of these. If most hardware that can run ppc64el can also run ppc64 then are there significant technical advantages other than compatibility with badly written software of going little endian?
It's not strictly a requirement but it would likely help immensely to get the architecture on debian-ports.org so that maintainers can easilly see if their packages are failing and porters for other new ports (i've been helping out a bit with arm64 myself) can see if ppc64el is also failing.
If and when the ftpmasters decide to include your architecture a minimal set of packages will be imported and everything (including when possible the minimal set) must be rebuilt. This will take time and will likely involve more NMUs. It is likely you will need to NMU to fix issues that are not strictly related to your port but are nevertheless blocking your build.
Once you are in the official archive and have rebuilt (nearly) everything you need to convince the release team that you meet the release critera. You can find the full details at https://release.debian.org/wheezy/arch_policy.html but the main ones are you have to have built almost all of debian*, you have to have a working installer, you have to actually have users and developers of the debian port, you have to be keeping up (which means both having plenty of build hardware AND stomping on architecture specific build failures)
When you are added to testing you will be added as a "broken and fucked" (release team's terminology not mine) architecture. To get out of this state you will need to get and keep your port in a healthy state in testing. That will mean fixing (in some cases through NMUs) issues that are blocking migration of packages you need (whether or not those issues are related to your architecture) and fixing any architecture specific build failures as quickly as possible (since when you are in the "broken and fucked" state your builds will not be blockers for testing migration so a new upload that breaks your architecture will be able to migrate).
Once your port reaches a healty state in testing (most packages present, virtually no packages outdated, very few architecture specific packages uninstallable), the release team will remove the "broken and fucked" status and you will become a release architecture. You then need to maintain your port in a healthy condition until release time.
*the release team say 98% but that number excludes certain poorly defined categories of package and so there is no easy way to measure it. Going by the statss on buildd.debian.org (which include everything including packages that are fundamentally architecture specific) the lowest release linux architecture according is currently at about 96% while kfreebsd is at about 90%. Realistically you probablly need to at least match the lowest release linux architecture.