linux-kernel - Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

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]

Message-ID: <AANLkTimDUx-by0MStp3O0L0xGW-okdCqAbDrJHuCewd7@mail.gmail.com>
Date:	Tue, 9 Nov 2010 12:40:51 -0600
From:	"Ramirez Luna, Omar" <omar.ramirez@...com>
To:	Greg KH <greg@...ah.com>
Cc:	"Guzman Lugo, Fernando" <fernando.lugo@...com>,
	Arnd Bergmann <arnd@...db.de>,
	Felipe Contreras <felipe.contreras@...il.com>,
	linux-omap@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

Hi,

> Seriously, I'm getting very confused here, and am very annoyed by the
> whole thing.
>
> Here's what I don't like:
>  - the original driver didn't even seem to work properly
>  - people sent me patches they never tested and broke things even worse
>  - some people have no respect for the omap maintainers and what they
>    think about things, or even basic knowledge of the kernel
>    development cycle.
>  - I do not have this hardware so I can't test anything.
>
> So, from now on, I'm not taking ANYONES patches for this driver unless
> it gets an ack from the driver maintainer, Omar Luna.
>
> Actually, no, I'm not going to take any patch unless it _comes from_
> Omar.  Omar, please work to queue up patches and test them, and then
> send them to me for merging.
>
> Any questions?
>
> If anyone doesn't like this because they feel that the current driver is
> broken, well, I can easily solve that by just deleting the whole thing
> from the tree right now.  Would that be a better idea?

I'm fine to queue the patches.

For now, yes, the driver is/has-been broken, and everybody has been
trying for the last two cycles to fix some dependencies (and
unfortunately we do it at the last minute or even after it can't be
done anymore, *sometimes*)... I have been kindly educated by both LO
and staging tree maintainers that it is just a bad practice to hurry
things up and not comply with the development standards.

If 2.6.36 or .37 tidspbridge is needed I'll keep each branch with
their dependent patches in d.o-z (TI's git server), if anybody
(Felipe) wants to keep their own branches I'm fine with that I can
sync with them privately to hear any concerns or something else.

I'll create the branches and sent an announce to both lists.

All dependencies need to be acked long before 2.6.38-rc1 and it is the
responsibility of the senders to track their acceptance.

Thanks for your suggestions and bearing with this situation, I'll
follow them and solve your dislikes about it (the hardware part it
might not be possible :/).

BTW, the testing environment for tidspbridge will be gst-dsp, any
stress testsuites will be run in addition, I'll detail more of it in
the upcoming mail.

Regards,

Omar
--
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/