mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bryan Wu" <cooloney.lkml@gmail.com>
To: "Michal Simek" <simekm2@fel.cvut.cz>
Cc: linux-kernel@vger.kernel.org, monstr@monstr.eu
Subject: Re: New linux arch
Date: Tue, 8 Jan 2008 16:28:10 +0800	[thread overview]
Message-ID: <386072610801080028w7bb9735cs7c104af146c0ab3d@mail.gmail.com> (raw)
In-Reply-To: <47820D24.3060800@fel.cvut.cz>

On Jan 7, 2008 7:29 PM, Michal Simek <simekm2@fel.cvut.cz> wrote:
> Hi all,
>
> I redesigned all files for microblaze cpu (xilinx fpga).
> All code is FDT compatible.
>
> I would like to ask you what is the best way to push these changes to
> kernel.org.
>

Welcome to the home of kernel.
I remember Blackfin maybe is the most recently new arch accept by
kernel mainline. So maybe some information can be shared with you
guys.


> I would like to know step by step how to do.
>

1. Push patches to LKML when merge window open (2 weeks after a stable
kernel version release, for example 2 weeks after 2.6.24 released)

2. Patches will be reviewed by kernel gurus and please update your
patches according to their comments. (It will take some time to get
ack from them -:)) ).

3. Reviewed patches will be accept to -mm tree by Andrew. (And please
do development and updates based on -mm tree)

4. After one or more development cycle, the patches will be sent to
Linus to merge into mainline kernel at another merge window.

5. Use GIT to maintain the Microblaze subsystem development and you
can apply an account on kernel.org. Then setup a public GIT tree for
Linus pull and development.

> I have some question about.
>
> I have changes in my internal git repository. I don't have public git
> repository.
> Is it possible to create git repository in git.kernel.org for Microblaze
> cpu?
>

Currently no need public git tree, after it is merged into mainline,
you can apply one for maintaining and development.

> What are maintainers responsibilities? Do you have any page about?
> I am  U-BOOT maintainer at denx.de and I hope that the responsibilities
> will be similar.
>

IMO, maintainer of one subsystem should review all the patches related
your subsystem,
test the patches at real hardware, fix bugs and send them to upstream
mainline at the right time.

> How many maintainers are acceptable? (one or more)
>

It depends on your internal development style. There is a team in
Analog Devices for Blackfin Linux development.
But I am responsible for kernel maintaining currently.

> I checked whole code with checkpatch.pl script to avoid code violations.
> I hope I resolve the most of coding style problems.
>

Yes, passing checkpatch.pl is required by LKML.

> I see the right way to push all changes to public git repository and
> then send patches in small logical group to LKML with CC to people from
> microblaze community.
>

No, please send out all your patches to LKML and CC to Microblaze world.
People from LKML will review your patches.

> And then wait for comments from you, solve problems, update git
> repository and send changes again.
>
No. update your patches and send the patches to LKML again.
GIT pull is only validated after your patches are in mainline.

Thanks
Regards,
-Bryan Wu

  parent reply	other threads:[~2008-01-08  8:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-07 11:29 Michal Simek
2008-01-07 12:34 ` Sam Ravnborg
2008-01-07 12:51   ` Michal Simek
2008-01-07 19:16     ` Sam Ravnborg
2008-01-07 12:47 ` Pekka Enberg
2008-01-07 13:00   ` Michal Simek
2008-01-07 13:12     ` Pekka Enberg
2008-01-07 13:34   ` Jan Engelhardt
2008-01-07 17:26     ` Stefan Richter
2008-01-07 17:39       ` Jan Engelhardt
2008-01-07 17:54         ` H. Peter Anvin
2008-01-07 18:20   ` Stefan Richter
2008-01-07 22:00 ` Benjamin Herrenschmidt
2008-01-07 22:39   ` Michal Simek
2008-01-08  8:28 ` Bryan Wu [this message]
2008-01-08  8:49   ` Pekka Enberg
2008-01-08  9:00     ` Bryan Wu
2008-01-08 17:05       ` Stefan Richter
2008-01-08 17:12   ` Stefan Richter
2008-01-09  1:16 ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=386072610801080028w7bb9735cs7c104af146c0ab3d@mail.gmail.com \
    --to=cooloney.lkml@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --cc=simekm2@fel.cvut.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®