[U-Boot-Users] PATCHES for next Merge Window

[U-Boot-Users] PATCHES for next Merge Window

[Wolfgang Denk]

Hello to everybody...

...who has sumbitted new patches without waiting for the official
opening of the new merge window.

Please note that I will NOT apply any of these patches yet. And I
recommend all custodians to wait, too.

The plan is as follows:

Grant Likely's patches come first, then comes the  drivers  reorgani-
zation,  and I tend to say that's what goes into 1.3.2 - after such a
significant restructuring I'd rather  want  to  have  it  tested  and
cleaned up first before adding more new stuff. Let's do a quick cycle
for 1.3.2 (which would be also good to bring us back in sync with the
Linux cycle).

In any case, after that probably  all  patches  have  to  be  rebased
against  the  new  tree  - otherwise we would run into a lot of nasty
merge conflicts.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sex is like air.  It's only a big deal if you can't get any.

[U-Boot-Users] PATCHES for next Merge Window

[Kumar Gala]

On Nov 20, 2007, at 7:41 AM, Wolfgang Denk wrote:

> Hello to everybody...
>
> ...who has sumbitted new patches without waiting for the official
> opening of the new merge window.
>
> Please note that I will NOT apply any of these patches yet. And I
> recommend all custodians to wait, too.
>
> The plan is as follows:
>
> Grant Likely's patches come first, then comes the  drivers  reorgani-
> zation,  and I tend to say that's what goes into 1.3.2 - after such a
> significant restructuring I'd rather  want  to  have  it  tested  and
> cleaned up first before adding more new stuff. Let's do a quick cycle
> for 1.3.2 (which would be also good to bring us back in sync with the
> Linux cycle).
>
> In any case, after that probably  all  patches  have  to  be  rebased
> against  the  new  tree  - otherwise we would run into a lot of nasty
> merge conflicts.

How long will that mean in terms of taking any actual new code between  
when the merge window closed for 1.3.0 and the 1.3.3 or 1.4.0 window  
opening?  Seems like it will be a very long time.

- k

[U-Boot-Users] PATCHES for next Merge Window

[Grant Likely]

On 11/20/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Nov 20, 2007, at 7:41 AM, Wolfgang Denk wrote:
>
> > Hello to everybody...
> >
> > ...who has sumbitted new patches without waiting for the official
> > opening of the new merge window.
> >
> > Please note that I will NOT apply any of these patches yet. And I
> > recommend all custodians to wait, too.
> >
> > The plan is as follows:
> >
> > Grant Likely's patches come first, then comes the  drivers  reorgani-
> > zation,  and I tend to say that's what goes into 1.3.2 - after such a
> > significant restructuring I'd rather  want  to  have  it  tested  and
> > cleaned up first before adding more new stuff. Let's do a quick cycle
> > for 1.3.2 (which would be also good to bring us back in sync with the
> > Linux cycle).
> >
> > In any case, after that probably  all  patches  have  to  be  rebased
> > against  the  new  tree  - otherwise we would run into a lot of nasty
> > merge conflicts.
>
> How long will that mean in terms of taking any actual new code between
> when the merge window closed for 1.3.0 and the 1.3.3 or 1.4.0 window
> opening?  Seems like it will be a very long time.

My patches are ready to be pulled and merged by Wolfgang now.  The
rebase/merge that everyone will need to do is to ease the pain of the
Makefile changes.  It's the sort of fixups that are a lot easier if
the custodians do them rather than Wolfgang having to figure it all
out.

I wouldn't be surprised if the new merge window should be openable in
less than a day.  The next question is how long should the window be
open?

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] PATCHES for next Merge Window

[Grant Likely]

On 11/20/07, Wolfgang Denk <wd@denx.de> wrote:
> Hello to everybody...
>
> ...who has sumbitted new patches without waiting for the official
> opening of the new merge window.
>
> Please note that I will NOT apply any of these patches yet. And I
> recommend all custodians to wait, too.
>
> The plan is as follows:
>
> Grant Likely's patches come first, then comes the  drivers  reorgani-
> zation,  and I tend to say that's what goes into 1.3.2 - after such a
> significant restructuring I'd rather  want  to  have  it  tested  and
> cleaned up first before adding more new stuff. Let's do a quick cycle
> for 1.3.2 (which would be also good to bring us back in sync with the
> Linux cycle).

Here's the updated pull request for my patches:

The following changes since commit 9a337ddc154a10a26f117fd147b009abcdeba75a:
  Wolfgang Denk (1):
        Prepare for 1.3.0 release.

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc5xxx.git kconfig-for-1.3.1

Grant Likely (10):
      Add .gitignore files
      Build: split COBJS value into multiple lines
      Group network drivers in drivers/Makefile
      Group console drivers in drivers/Makefile
      Group i2c drivers in drivers/Makefile
      Group USB drivers in drivers/Makefile
      Group block/flash drivers in drivers/Makefile
      Group PCI and PCMCIA drivers in drivers/Makefile
      Merge branch 'origin' into kconfig-for-1.3.1
      Merge branch 'origin' into kconfig-for-1.3.1

 .gitignore               |   13 ++++
 common/Makefile          |  123 +++++++++++++++++++++++++++++++--------
 disk/Makefile            |    7 ++-
 drivers/Makefile         |  143 +++++++++++++++++++++++++++++++++++++---------
 drivers/nand/Makefile    |   10 +++-
 drivers/sk98lin/Makefile |   26 +++++++--
 dtt/Makefile             |    7 ++-
 examples/.gitignore      |    5 ++
 fs/jffs2/Makefile        |   12 +++-
 include/.gitignore       |    6 ++
 lib_generic/Makefile     |   21 +++++--
 libfdt/Makefile          |    4 +-
 net/Makefile             |   11 +++-
 rtc/Makefile             |   30 ++++++++--
 tools/.gitignore         |    9 +++
 15 files changed, 347 insertions(+), 80 deletions(-)

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] PATCHES for next Merge Window

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:24 Tue 20 Nov     , Grant Likely wrote:
> On 11/20/07, Wolfgang Denk <wd@denx.de> wrote:
> > Hello to everybody...
> >
> > ...who has sumbitted new patches without waiting for the official
> > opening of the new merge window.
> >
> > Please note that I will NOT apply any of these patches yet. And I
> > recommend all custodians to wait, too.
> >
> > The plan is as follows:
> >
> > Grant Likely's patches come first, then comes the  drivers  reorgani-
> > zation,  and I tend to say that's what goes into 1.3.2 - after such a
> > significant restructuring I'd rather  want  to  have  it  tested  and
> > cleaned up first before adding more new stuff. Let's do a quick cycle
> > for 1.3.2 (which would be also good to bring us back in sync with the
> > Linux cycle).
> 
> Here's the updated pull request for my patches:
> 
> The following changes since commit 9a337ddc154a10a26f117fd147b009abcdeba75a:
>   Wolfgang Denk (1):
>         Prepare for 1.3.0 release.
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc5xxx.git kconfig-for-1.3.1
> 
I will send the drivers reorganisation patch before Friday.

If I've time tomorrow morming.

Best Regards,
J.

[U-Boot-Users] PATCHES for next Merge Window

[Wolfgang Denk]

In message <fa686aa40711200724q4ebac2bdtf3a4b9ac7b0a899b@mail.gmail.com> you wrote:
>
> Here's the updated pull request for my patches:
> 
> The following changes since commit 9a337ddc154a10a26f117fd147b009abcdeba75a:
>   Wolfgang Denk (1):
>         Prepare for 1.3.0 release.
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc5xxx.git kconfig-for-1.3.1

Merged into u-boot-testing repository.

Jean-Christophe - that's your base for the drivers reorganisation
patches.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any technology distinguishable from magic is insufficiently advanced.

[U-Boot-Users] PATCHES for next Merge Window

[Jon Loeliger]

On Tue, 2007-11-20 at 07:41, Wolfgang Denk wrote:
> Hello to everybody...
> 
> ...who has sumbitted new patches without waiting for the official
> opening of the new merge window.
> 
> Please note that I will NOT apply any of these patches yet. And I
> recommend all custodians to wait, too.

I'm not sure exactly what you are meaning here.
To be clear, I'd like to call out two separate
functions of the custodians and their repos and
see if you (Wolfgang and others) buy it.

While you (Wolfgang) are in the "stabilizing a release"
mode, it should be the time for the custodians to be
gathering and staging their patches into a repo so
that they can be pulled when a merge window opens.
So to that end, the custodians are not waiting.

But yes, if you (Wolfgang) are not yet ready to
generally pull from custodians, or have a planned
order for that, then, yes, it does make sense for
the custodians to wait to issue "pull requests"
until you are ready for them.

> The plan is as follows:
> 
> Grant Likely's patches come first, then comes the  drivers  reorgani-
> zation,  and I tend to say that's what goes into 1.3.2

Did I miss 1.3.1 already?

>  - after such a
> significant restructuring I'd rather  want  to  have  it  tested  and
> cleaned up first before adding more new stuff. Let's do a quick cycle
> for 1.3.2 (which would be also good to bring us back in sync with the
> Linux cycle).

I'd like to have the new libfdt structure in place too,
as a general goal for us is to move all the FSL boards
over to it in "the next" U-Boot release.  (For some value
of "the next", of course. :-))


Thanks,
jdl

[U-Boot-Users] PATCHES for next Merge Window

[Jerry Van Baren]

Jon Loeliger wrote:
> On Tue, 2007-11-20 at 07:41, Wolfgang Denk wrote:
>> Hello to everybody...
>>
>> ...who has sumbitted new patches without waiting for the official
>> opening of the new merge window.
>>
>> Please note that I will NOT apply any of these patches yet. And I
>> recommend all custodians to wait, too.
> 
> I'm not sure exactly what you are meaning here.
> To be clear, I'd like to call out two separate
> functions of the custodians and their repos and
> see if you (Wolfgang and others) buy it.
> 
> While you (Wolfgang) are in the "stabilizing a release"
> mode, it should be the time for the custodians to be
> gathering and staging their patches into a repo so
> that they can be pulled when a merge window opens.
> So to that end, the custodians are not waiting.
> 
> But yes, if you (Wolfgang) are not yet ready to
> generally pull from custodians, or have a planned
> order for that, then, yes, it does make sense for
> the custodians to wait to issue "pull requests"
> until you are ready for them.
> 
>> The plan is as follows:
>>
>> Grant Likely's patches come first, then comes the  drivers  reorgani-
>> zation,  and I tend to say that's what goes into 1.3.2
> 
> Did I miss 1.3.1 already?
> 
>>  - after such a
>> significant restructuring I'd rather  want  to  have  it  tested  and
>> cleaned up first before adding more new stuff. Let's do a quick cycle
>> for 1.3.2 (which would be also good to bring us back in sync with the
>> Linux cycle).
> 
> I'd like to have the new libfdt structure in place too,
> as a general goal for us is to move all the FSL boards
> over to it in "the next" U-Boot release.  (For some value
> of "the next", of course. :-))
> 
> Thanks,
> jdl

You mean, for a *sufficiently small* value of "next."  :-D

I'm planning to get libfdt improvements into the next release (1.3.1). 
My plan is to stage the libfdt improvements in a "testing" branch (I'm 
starting down that path, but have not pushed anything back to denx.de 
yet).  When the window opens and Grant's changes get pulled in, I will 
rebase and then pull the libfdt "testing" branch into my "master" 
branch.  If Something Bad[tm] happens with the rebase, it is NBD, the 
files would have to be fixed anyway and branches are cheap.  Once that 
works, I'll issue a call to Wolfgang to pull.

The nice things about git are...
1) It is easy to make a clone of a repo
2) It is easy to make a branch in a repo
3) It is easy to rebase a branch
4) It is easy to throw away a branch or repo when you screw up :-O

As long as you remember to do (1) and/or (2) before doing something 
"irreversible", (4) pulls your bacon out of the fire. ;-)

gvb

[U-Boot-Users] PATCHES for next Merge Window

[Wolfgang Denk]

Dear Jon,

in message <1195580562.25887.9.camel@ld0161-tx32> you wrote:
> 
> While you (Wolfgang) are in the "stabilizing a release"
> mode, it should be the time for the custodians to be
> gathering and staging their patches into a repo so
> that they can be pulled when a merge window opens.
> So to that end, the custodians are not waiting.

Normally, this is correct. But normally, patches are usually more  or
less  orthogonal,  and  stuff that touches the same area goes through
the one specific custodian who coordinates this.

This time, situation is  completely  different.  We  touch  a  pretty
fundamental  part  of the global infrastructure. Anybody who does not
wait will probably be hit hard,

> > Grant Likely's patches come first, then comes the  drivers  reorgani-
> > zation,  and I tend to say that's what goes into 1.3.2
> 
> Did I miss 1.3.1 already?

No, that's just my fingers being faster than my brain. Which  doesn't
imply that they were especially fast.

> I'd like to have the new libfdt structure in place too,
> as a general goal for us is to move all the FSL boards
> over to it in "the next" U-Boot release.  (For some value
> of "the next", of course. :-))

I definitely don;t intend to delay the U-Boot development if it can be
avoided. But with the Makefile reorganization *and* the driver
restructuring we have two global changed which affect nearly
everybody. 

I really think it makes sense to define some checkpoint after these
changes and verify that nothing was broken before adding many new
patches to different areas which will hide all traces.

So my idea is really to have a very  short  semi-open  merghe  window
(just  long  enough  until  Jean-Christophe has the drivers reorgani-
zation patches ready - he said that's Friday.

So assume we will have a 1.3.1-rc1 by Sunday, and 1.3.1 released by
Friday next week. Or so - if nothing goes wrong.

And then we formally open a real new merge window.

What do you think?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...this does not mean that some of us should not want, in  a  rather
dispassionate sort of way, to put a bullet through csh's head."
                   - Larry Wall in <1992Aug6.221512.5963@netlabs.com>

[U-Boot-Users] PATCHES for next Merge Window

[Josh Boyer]

On Tue, 20 Nov 2007 21:26:27 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Jon,
> 
> in message <1195580562.25887.9.camel@ld0161-tx32> you wrote:
> > 
> > While you (Wolfgang) are in the "stabilizing a release"
> > mode, it should be the time for the custodians to be
> > gathering and staging their patches into a repo so
> > that they can be pulled when a merge window opens.
> > So to that end, the custodians are not waiting.
> 
> Normally, this is correct. But normally, patches are usually more  or
> less  orthogonal,  and  stuff that touches the same area goes through
> the one specific custodian who coordinates this.
> 
> This time, situation is  completely  different.  We  touch  a  pretty
> fundamental  part  of the global infrastructure. Anybody who does not
> wait will probably be hit hard,
> 
> > > Grant Likely's patches come first, then comes the  drivers  reorgani-
> > > zation,  and I tend to say that's what goes into 1.3.2
> > 
> > Did I miss 1.3.1 already?
> 
> No, that's just my fingers being faster than my brain. Which  doesn't
> imply that they were especially fast.
> 
> > I'd like to have the new libfdt structure in place too,
> > as a general goal for us is to move all the FSL boards
> > over to it in "the next" U-Boot release.  (For some value
> > of "the next", of course. :-))
> 
> I definitely don;t intend to delay the U-Boot development if it can be
> avoided. But with the Makefile reorganization *and* the driver
> restructuring we have two global changed which affect nearly
> everybody. 
> 
> I really think it makes sense to define some checkpoint after these
> changes and verify that nothing was broken before adding many new
> patches to different areas which will hide all traces.
> 
> So my idea is really to have a very  short  semi-open  merghe  window
> (just  long  enough  until  Jean-Christophe has the drivers reorgani-
> zation patches ready - he said that's Friday.
> 
> So assume we will have a 1.3.1-rc1 by Sunday, and 1.3.1 released by
> Friday next week. Or so - if nothing goes wrong.
> 
> And then we formally open a real new merge window.
> 
> What do you think?

Not that I have any stake in this, but that seems overly cautious.
Just declare that the driver reorganization/makefile changes are the
first thing to be merged and make the maintainers rebase after.

I don't see a need for a whole separate release.

josh

[U-Boot-Users] PATCHES for next Merge Window

[Grant Likely]

On 11/20/07, Josh Boyer <jwboyer@gmail.com> wrote:
> On Tue, 20 Nov 2007 21:26:27 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> > So my idea is really to have a very  short  semi-open  merghe  window
> > (just  long  enough  until  Jean-Christophe has the drivers reorgani-
> > zation patches ready - he said that's Friday.
> >
> > So assume we will have a 1.3.1-rc1 by Sunday, and 1.3.1 released by
> > Friday next week. Or so - if nothing goes wrong.
> >
> > And then we formally open a real new merge window.
> >
> > What do you think?
>
> Not that I have any stake in this, but that seems overly cautious.
> Just declare that the driver reorganization/makefile changes are the
> first thing to be merged and make the maintainers rebase after.
>
> I don't see a need for a whole separate release.

Personally, I'm not at all concerned about it.  There isn't a lot of
risk in my changes; just merge pain if it's done out of order.  I'm
not opposed to a quick merge cycle for these changes, but I don't
think it's strictly necessary either.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] PATCHES for next Merge Window

[Jon Loeliger]

On Tue, 2007-11-20 at 14:26, Wolfgang Denk wrote:
> Dear Jon,
> 

> And then we formally open a real new merge window.
> 
> What do you think?

Sounds good to me!

jdl