[lkml]   [2008]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: New linux arch
Pekka Enberg wrote:
> On Jan 7, 2008 1:29 PM, Michal Simek <> wrote:
>> How many maintainers are acceptable? (one or more)
> You can have as many maintainers as you want but you probably don't
> want to make it too many.

Bug reporters and patch submitters shouldn't be required to CC too many

>> 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.
>> And then wait for comments from you, solve problems, update git
>> repository and send changes again.
> You don't necessarily need a public git repository before sending your
> patches to LKML but yeah, you definitely want some public exposure
> before asking for Linus/Andrew to merge your port.

Yes, patch review is always done on the mailing list(s). Not only
during the initial submission, but also for all later changes.

A git repository provided by you could be used

- by interested people to fetch your pre-integrated development

- by Andrew Morton to pull into -mm. This needs to be a branch in
your repo which only contains stuff which works to the best of your
knowledge, i.e. is already tested and got at least some basic review
by those involved in the subproject. It always has to give a clean
and working diff against Linus' current tree, because that's what
Andrew bases -mm on. (This means you have to rebase or otherwise
update this branch whenever there were conflicting changes in Linus'
tree.) Also, if you need to do changes outside your subsystem,
coordinate it with the tree owners of the other subsystems to
minimize conflicts when Andrew assembles -mm.
Alternatively to git, you could also work with Andrew via a quilt
tree or via e-mail, depending on what turns out as most effective.

- by Linus to pull into his tree if he thinks he can work with your
tree better than via e-mail. Regardless if git or e-mail, you are
of course supposed to only offer stuff to Linus which is known to
work and has been fully reviewed.
New work (feature additions or removals, refactoring, intrusive bug
fixes) needs to be sent to Linus early before an -rc1 release.
Between -rc1 and -final, only bug fixes are acceptable. (In early
-rc's maybe also a few other small nonintrusive changes that can't
possibly break anything...)

Note, everything which I said here only reflects what I remember as
required or most desirable; it's not a canonical list of requirements.

Anyway, it may be a little bit too early to think about those things
before you posted your initial submission for review and re-review...
Stefan Richter
-=====-==--- ---= --===

 \ /
  Last update: 2008-01-07 19:23    [W:0.079 / U:12.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site