I have my own server 100mbps up/down, but I never created my own GIT
repository before.

On May 15, 9:00 am, Yi Sun <beyo...@gmail.com> wrote:
> Ya ya.... in where (don't tell me github, it costs money)? I need not
> only just a server but also a set of tools to manager the code
> review/checking and bug tracking.
>
> Anyway, I'm still trying to see if I can find some work around.
>
> On Thu, 2009-05-14 at 23:56 -0700, Androidphan wrote:
> > You should get a hold of a GIT repository instead.
>
> > On May 15, 7:59 am, Yi Sun <beyo...@gmail.com> wrote:
> > > Sigh..... it is just impossible to upload android source code the google
> > > code. I have tried different version of the svn but I can barely upload
> > > the kernel directory. It always failed with different errors.
> > > I will have to find a server to host the source code.
>
> > > On Wed, 2009-05-13 at 10:39 +0530, Ravishankar Haranath wrote:
> > > > This seems to be a good idea to me to have a x86/generic structure.
>
> > > > On Wed, May 13, 2009 at 10:03 AM, Yi Sun <beyo...@gmail.com> wrote:
>
> > > >         x86/generic should be the major part of the whole project.
> > > >         Let's wait
> > > >         for Chih-wei and others to give more comments.
> > > >         Currently, I'm trying to upload a baseline tree to google
> > > >         code, but my
> > > >         svn keep screws up. It is very hard to upload a large scale
> > > >         project.
> > > >         On Tue, 2009-05-12 at 19:00 -0700, adam singer wrote:
> > > >         > I agree with the 3 level structure for x86/eeepc/generic,
> > > >         etc.. But I
> > > >         > think one main starting point will be needed which would be
> > > >         > x86/generic . Just cause it seems like more than a few
> > > >         people are
> > > >         > targeting x86 as a hardware platform.
>
> > > >         > Kind Regards.
>
> > > >         > PS: has anyone hosted builds for installer.img and
> > > >         live-usb ?
>
> > > >         > On Mon, May 11, 2009 at 10:07 AM, Yi Sun <beyo...@gmail.com>
> > > >         wrote:
>
> > > >         > > My 2 cents inline.....
> > > >         > > On Mon, 2009-05-11 at 02:03 -0700, Chih-Wei wrote:
> > > >         > >> On 5月10日, 上午4時08分, Yi Sun <beyo...@gmail.com>
> > > >         wrote:
> > > >         > >> > There are a few things planed in my mind for next:
> > > >         > >> > 1. a mail list for Eeepc/X86 issues only
>
> > > >         > >> I think android-porting list is just good for it.
> > > >         > >> Unless the topics are too hot, then we can fork a new
> > > >         list.
> > > >         > > A new list will allow people to look up information in a
> > > >         easier way. I
> > > >         > > have a few hundred e-mails flood in every day from
> > > >         different places, a
> > > >         > > separate list gives me a better choice to config my e-mail
> > > >         box to filter
> > > >         > > e-mails.
> > > >         > > Because the traffic in Android-porting is not too big at
> > > >         today,
> > > >         > > with/without a new e-mail list is not a very critical
> > > >         issue for me at
> > > >         > > the moment and we can postpone the discussion to the time
> > > >         when someone
> > > >         > > feels that we really need a new list for some reason.
>
> > > >         > >> > 2. a git server for Eeepc/x86 platforms.
>
> > > >         > >> Yes. Since the eee_701 project is almost dead,
> > > >         > >> I do think to re-invent a new one is better.
>
> > > >         > >> Actually I'm planning to do that. But there are something
> > > >         I need to
> > > >         > >> figure out first.
> > > >         > >> Instead of eee_701, I plan to use a more generic name
> > > >         like eeepc (more
> > > >         > >> generic? please suggest).
> > > >         > > Good, people are all on the same line now. It is just
> > > >         about execution
> > > >         > > now :-)
> > > >         > > Actually, there may be differences among eeepcs (later we
> > > >         may have new
> > > >         > > wifi driver, new camera driver, new video card and new
> > > >         something
> > > >         > > else...). We may still end up with something like
> > > >         asus/eeepc/eee_bla.
> > > >         > > And we still need to cover the VM support as well.
> > > >         > > So, could we do two or three level structure (maybe you
> > > >         are talking
> > > >         > > about the same thing)?
> > > >         > > product_line_name/platform_name
> > > >         > > Like:
> > > >         > > eeepc/eee_701
> > > >         > > eeepc/eee_1000e
> > > >         > > eeepc/generic
> > > >         > > If you don't have anything special for a platform, then
> > > >         use generic
> > > >         > > otherwise, create a special directory for the platform and
> > > >         put all
> > > >         > > special things in it.
>
> > > >         > > Talking about emulator, to me emulator is based on CPU
> > > >         type. I think
> > > >         > > eventually, we may end up with:
> > > >         > > x86/eeeepc
> > > >         > > x86/emulator
> > > >         > > x86/hp
> > > >         > > x86/dell
>
> > > >         > > So if people can agree, then we can have 3 levels
> > > >         structure like:
> > > >         > > x86/eeepc/generic
>
> > > >         > >> And I hope to add some scripts to automatically detect
> > > >         the hardware
> > > >         > >> and load appropriate drivers or configurations.
> > > >         > > This is very important. I think.
> > > >         > >> The problem is, now it is not possible to use shell
> > > >         scripts in android
> > > >         > >> ramdisk(boot.img).
> > > >         > >> Current I'm considering two approaches:
> > > >         > >> 1. Add /system/bin/sh (+linker, all necessary libraries)
> > > >         to ramdisk. I
> > > >         > >> also have to add toolbox
> > > >         > >>    that provides utilities for scripts. However, android
> > > >         toolbox lacks
> > > >         > >> some important utilities like sed and cut.
> > > >         > >>    Without them it's hard to write useful scripts.
> > > >         > >>    So I may have to add the necessary utilities to
> > > >         toolbox first.
> > > >         > >> 2. Add a prebuilt, static linked busybox with all
> > > >         utilities I need to
> > > >         > >> ramdisk.
> > > >         > >>    The approach may be much easier, but I don't know if
> > > >         it is
> > > >         > >> acceptable by google.
>
> > > >         > > I think Makefile may be able to solve your problem (if you
> > > >         only want to
> > > >         > > be able to load the right drivers).
> > > >         > > You can have makefile to automatically generate platform
> > > >         specific
> > > >         > > init.rc to do this.
> > > >         > > If you want to install drivers during run time, we maybe
> > > >         able to do it
> > > >         > > by extending system prop and vold.
>
> > > >         > > But in any case, adding a busybox is good idea, I always
> > > >         use it when I
> > > >         > > debug something.
>
> > > >         > >> I may need your comments to move on.
>
> > > > --
> > > > Ravishankar Haranath
> > > >http://www.linmaya.net
>
> > > > We should be taught not to wait for inspiration to start a thing.
> > > > Action always generates inspiration. Inspiration seldom generates
> > > > action.
> > > >  - Frank Tibolt
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to