From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Pull request for u-boot-arm -> u-boot?
Date: Mon, 5 May 2014 20:54:50 +0200 [thread overview]
Message-ID: <201405052054.50260.marex@denx.de> (raw)
In-Reply-To: <20140505184034.GR22182@bill-the-cat>
On Monday, May 05, 2014 at 08:40:34 PM, Tom Rini wrote:
> On Mon, May 05, 2014 at 12:15:50PM -0600, Stephen Warren wrote:
> > On 05/05/2014 11:59 AM, Fabio Estevam wrote:
> > > On Mon, May 5, 2014 at 1:46 PM, Stephen Warren <swarren@wwwdotorg.org>
wrote:
> > >> Albert,
> > >>
> > >> I was wondering when the next pull request for u-boot-arm/master ->
> > >> u-boot/master was likely to be?
> > >>
> > >> I asked because some changes to the Tegra USB driver went through the
> > >> u-boot-tegra/master and hence are now in u-boot-arm/master, but not in
> > >> u-boot-usb/master. I have some more USB driver changes which rely on
> > >> the earlier USB patches, and these should really go through
> > >> u-boot-usb/master rather than the Tegra/ARM tree. For this to happen,
> > >> u-boot-usb/master needs to contain the patches currently in
> > >> u-boot-arm/master, and the best way for that to happen is for those
> > >> patches to get into u-boot/master so that u-boot-usb/master can merge
> > >> them.
> > >>
> > >> Or, should Marek just merge u-boot-arm/master into his tree directly?
> > >
> > > Or should we have a 'u-boot-next' tree using the same concept as the
> > > kernel 'linux-next'?
> >
> > Having a u-boot-next won't solve this particular problem in any way.
> >
> > Having a u-boot-next allows any end-developer to develop on top of the
> > combined code in all trees, thus detecting/avoiding any conflicts with
> > them.
> >
> > However, my issue above is that a patch that's already applied in tree A
> > needs to make its way into tree B, so that further patches can be
> > *applied* in tree B. This is all about applying patches, not developing
> > patches. The existence (or not) of a u-boot-next tree doesn't affect
> > this issue at all.
>
> This is in fact a usual problem in Linux land where it seems like we
> have much more stringent rules on how things can go in. So long as
> people can collect the needed acks, I'm fine pulling things that touch a
> few areas into master.
The problem here is that I cannot apply the USB patches from Stephen until
Albert gets his stuff into U-Boot/master, which I would then merge back into
mine. Only then I can apply the USB patches. So we're waiting for Albert ...
Best regards,
Marek Vasut
prev parent reply other threads:[~2014-05-05 18:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 16:46 [U-Boot] Pull request for u-boot-arm -> u-boot? Stephen Warren
2014-05-05 17:46 ` Marek Vasut
2014-05-09 8:39 ` Albert ARIBAUD
2014-05-05 17:46 ` Tom Rini
2014-05-09 9:57 ` Albert ARIBAUD
2014-05-05 17:59 ` Fabio Estevam
2014-05-05 18:12 ` Otavio Salvador
2014-05-05 18:53 ` Marek Vasut
2014-05-05 18:15 ` Stephen Warren
2014-05-05 18:40 ` Tom Rini
2014-05-05 18:52 ` Stephen Warren
2014-05-05 18:54 ` Marek Vasut [this message]
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=201405052054.50260.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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