linux-kernel - Re: [PATCH 01/19] Add XHFC support for embedded Speech-Design board to hfcmulti

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 20 May 2009 11:12:21 +0200
From:	Karsten Keil <keil@...systems.de>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	sfr@...b.auug.org.au, i4ldeveloper@...tserv.isdn4linux.de
Subject: Re: [PATCH 01/19] Add XHFC support for embedded Speech-Design board to hfcmulti

Hi Marcel,
Hi Dave,

On Mittwoch, 20. Mai 2009 05:13:01 Marcel Holtmann wrote:
> Hi Karsten,
>
> > I have been applying some gigaset patches into the net-next-2.6
> > and I would therefore suggest that you push ISDN changes bound
> > for the next kernel release via the networking tree as well.
> >
> > In fact I'm very surprised that you're not at least CC:'ing
> > netdev@...r.kernel.org with these patches.  Not only would they get
> > review for networking specific issues they would also get your patches
> > tracked automatically at:

My idea was to not send it on too much lists, but I think you are right, 
netdev@...r.kernel.org should be  used here and since it should go via the net 
tree it should be the default.

> >
> > 	http://patchwork.ozlabs.org/project/netdev/list/
> >
> > Can you at least state how you intend to manage the ISDN changes you
> > queue up?  Are you going to submit them independantly and straight to
> > Linus or are you going to play along and get them in via my
> > net-next-2.6 tree in order to avoid all of the merge hassles?
>
> since mISDN uses AF_ISDN and sockets, I personally would prefer if they
> go via net-2.6 and net-next-2.6 trees. This makes it a lot simpler in
> case of merge conflicts during the merge windows.
>

Yes, you are right, I queued it for linux-next because I was remembering that 
somebody did suggest this in the past, but this was not really a good idea.
I will setup a new merge tree based on net-2.6-next  (or better net-2.6) ?

Karsten

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/