[U-Boot-Users] Changes to U-Boot Development Process

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Hello,

many of you know  all  too  well  that  we  have  problems  with  the
development  process  of U-Boot. The biggest problem is that it takes
much too long until new contributed code  finds  it's  way  into  the
public source code repository.

Switching from CVS to git helped a lot on the technical side. It  was
especially  important  as  it also opened the door for organizational
changes, which are urgently needed.

We've been discussion these issues for some time,  and  here  is  our
joint proposal. "We", that is mostly Detlev Zundel, Stefan Roese, and
me  (Wolfgang  Denk).  Of  course  we  also had input form many other
sources.


As this mail will propose quite a fundamental change for  the  U-Boot
project, please allow us to introduce it with a few short reflections
on the current state of affairs.

Being a regular reader of this list you will be well aware that  even
with  all the problems in the development process and some ugly areas
in the U-Boot code (like the #ifdef mazes)  there  is  one  important
feature:  that's  the  quality  of  the  U-Boot  code  base  -  being
highlighted quite well by the literal absence of temporary  breakages
in  the  development  code base. This alone allows for the well known
"use the latest code from the repository" answer when someone  enters
the  grounds  of this project for the first time. It is well worth to
reflect on this quality for a little while.

Having done that we may well ask where this quality  comes  from?  We
think  that anybody reading this list only for a limited time will be
able to come up with the answer, namely  the  continuous  maintenance
effort  of  Wolfgang  and  his modus operandi of personally reviewing
nearly each and every contribution in this multi-architecture project
supporting hundreds of boards. It should  be  obvious  how  important
such  a  level  of  code  review  is to keep U-Boot from falling into
disconnected pieces - just think of the effort  to  keep  aspects  of
U-Boot similar across all supported architectures.

But of course even Wolfgang only  has  24  hours  per  day,  and  the
positive  effect  of this maintenance mode has shrunk continuously in
comparison to the downside  of  the  embarassingly  long  backlog  of
patches  posted  on  this  mailing  list  waiting  to  be  processed,
rendering new lines of development very difficult to say the least.

So the time is more than ripe to change this while explicitely trying
to keep the quality of the  project  on  the  high  grounds  that  we
brazenly claim for it :)

Gladly there are other projects in the F/OSS community that are worth
taking a peek at to snatch a hint or two on how we  can  tackle  this
task.

Considering all this we propose a change in  maintaining  the  U-Boot
code base to a model similar to what is currently being done with the
Linux  kernel,  namely  we  would  like  to  establish a community of
"custodian"  maintainers,  responsible   for   certain   sub-systems,
aspects, architectures, or board families of the U-Boot source tree.

We would like to follow the Linux precedent by assembling a  list  of
people  willing  to  invest  time  and  effort into this; the already
existing MAINTAINERS file will serve  a  new  function  to  list  the
individual  custodians with their corresponding area of responsibilty
and contact information.

Each custodian will have to administrate  his  or  her  git  tree  to
streamline transparent development and integration (pulling) into the
"official"  U-Boot repository. If the need should arise (for example,
if a custodian doesn't have convenient means  to  host  it  himself),
DENX will of course be glad to host such trees.

The stated goal of this change of course is to spread the  burden  of
maintaining U-Boot to more shoulders so we can hopefully dramatically
cut  down  on  the  current lag between a patch being proposed on the
mailing list and being processed - be that  accepting,  rejecting  or
openly discussing it with the community.

As you must have realized by now, this cannot  be  done  without  the
community  participating,  so  what  do  you  think of this idea? Any
comments or suggestions?


Of course we should be honest right  upfront  and  state  that  as  a
custodian  you  would  be  fully  responsible  for "your" part of the
U-Boot source tree and it is unfortunately necessary,  that  you  are
able to commit to a certain amount of time and willingness to discuss
topics on the mailing list for this maintenance.

Do we have an immediate line of volunteers raising in the first row?

Skimming through the archives we came up with a list of people  which
the  U-Boot  project  already  is indebted to and probably being good
candidates for custodians. Of course this list cannot  and  does  not
want  to  be  a  "credits"  list  of  all  the valuable people having
contributed, so please don't attribute anything else to it as being a
starting point for this new maintenance mode. Also there are multiple
suggestions where ultimately of course we would like the community to
decide.

So with all these precautions in place, here we go:

ARM architecture	Richard Woodruff, Peter Pearse
AVR32 architecture	Haavard Skinnemoen
Blackfin architecture	Aubrey Li
Intel IXP architecture	Stefan Roese
ColdFire architecture	Stefan Roese
Microblaze architecture	Michal Simek
MIPS architecture	Rodolfo Giometti, Andrew Dyer
MPC83xx architecture	Kim Phillips
MPC85xx architecture	Jon Loelinger
MPC86xx architecture	Jon Loelinger
MPC8xx architecture	Wolfgang Denk
NIOS(2)			Scott McNutt
PPC4xx architecture	Stefan Roese

CFI FLASH driver	Tolunay Orkun
NAND FLASH subsystem	Ladislav Michl, Stefan Roese
USB drivers		Markus Klotzb?cher

So thanks for bearing with  us  through  this  longwinded  mail  that
hopefully starts to pave the way to a new level of quality and extent
of  the  U-Boot project that is only possibly through its very active
community - you!


Best regards,

Wolfgang Denk, Stefan Roese, Detlev Zundel

[U-Boot-Users] Changes to U-Boot Development Process

[Scott McNutt]

Hi Wolfgang,

> The stated goal of this change of course is to spread the  burden
...
> cut  down  on  the  current lag between a patch being proposed on the
> mailing list and being processed - be that  accepting,  rejecting

I have bothered you far too often in this matter WRT Nios II ;-)
So ...

> Do we have an immediate line of volunteers raising in the first row?

... I would be just another LID if I didn't offer my time to support
Nios II. I'd be honored to take responsibility for Nios II.

Best Regards,
--Scott

[U-Boot-Users] Changes to U-Boot Development Process

[Rodolfo Giometti]

On Wed, Jan 17, 2007 at 10:24:47PM +0100, Wolfgang Denk wrote:

> So with all these precautions in place, here we go:
> 
> ARM architecture	Richard Woodruff, Peter Pearse
> AVR32 architecture	Haavard Skinnemoen
> Blackfin architecture	Aubrey Li
> Intel IXP architecture	Stefan Roese
> ColdFire architecture	Stefan Roese
> Microblaze architecture	Michal Simek
> MIPS architecture	Rodolfo Giometti, Andrew Dyer

Currently I have just one MIPS based board (the AU1100 one) so I don't
know if I can be really useful to this subpart. However I'd be honored
to take responsibility for the MIPS architecture! :)

> MPC83xx architecture	Kim Phillips
> MPC85xx architecture	Jon Loelinger
> MPC86xx architecture	Jon Loelinger
> MPC8xx architecture	Wolfgang Denk
> NIOS(2)			Scott McNutt
> PPC4xx architecture	Stefan Roese
> 
> CFI FLASH driver	Tolunay Orkun
> NAND FLASH subsystem	Ladislav Michl, Stefan Roese
> USB drivers		Markus Klotzb?cher

About USB drivers, I did on this topic several activities and some
drivers (the AU1x00 OHCI fixup and ISP116x support) and in a few days
I should start developing PXA270 support, so I think I can help much
more on this subpart.

Thanks and regards,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] Changes to U-Boot Development Process

[Jerry Van Baren]

Wolfgang Denk wrote:
> Hello,

[snip]

> We would like to follow the Linux precedent by assembling a  list  of
> people  willing  to  invest  time  and  effort into this; the already
> existing MAINTAINERS file will serve  a  new  function  to  list  the
> individual  custodians with their corresponding area of responsibilty
> and contact information.
> 
> Each custodian will have to administrate  his  or  her  git  tree  to
> streamline transparent development and integration (pulling) into the
> "official"  U-Boot repository. If the need should arise (for example,
> if a custodian doesn't have convenient means  to  host  it  himself),
> DENX will of course be glad to host such trees.

It I don't know if the request is reasonable in terms of disk space and 
burdening denx.de with administrative work, but it would be nice if the 
primary maintainers had their official feeder repositories on the 
denx.de site.  It is _very_ useful to have the feeder git repositories 
in one place for easy reference, and that way the repositories would 
tend to be more stable and available.

[snip]

> Best regards,
> 
> Wolfgang Denk, Stefan Roese, Detlev Zundel

As always, thank you very much for your efforts in the past and your 
thoughtful work to always improve both u-boot and the development 
methodology!

Best regards,
gvb

[U-Boot-Users] Changes to U-Boot Development Process

[Josh Boyer]

On 1/18/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> Wolfgang Denk wrote:
> > Hello,
>
> [snip]
>
> > We would like to follow the Linux precedent by assembling a  list  of
> > people  willing  to  invest  time  and  effort into this; the already
> > existing MAINTAINERS file will serve  a  new  function  to  list  the
> > individual  custodians with their corresponding area of responsibilty
> > and contact information.
> >
> > Each custodian will have to administrate  his  or  her  git  tree  to
> > streamline transparent development and integration (pulling) into the
> > "official"  U-Boot repository. If the need should arise (for example,
> > if a custodian doesn't have convenient means  to  host  it  himself),
> > DENX will of course be glad to host such trees.
>
> It I don't know if the request is reasonable in terms of disk space and
> burdening denx.de with administrative work, but it would be nice if the
> primary maintainers had their official feeder repositories on the
> denx.de site.  It is _very_ useful to have the feeder git repositories
> in one place for easy reference, and that way the repositories would
> tend to be more stable and available.

Git can clone on a local machine and use the --reference option to
point to the official tree.  That means that the maintainer's trees
would not need the full set of all the objects in the tree as the main
tree will be used as a reference for those.  This greatly reduces the
storage overhead for those trees.

Just an FYI.

josh

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Dear Josh,

in message <625fc13d0701180651n613aacb3lf263715d02bb7dcb@mail.gmail.com> you wrote:
>
> Git can clone on a local machine and use the --reference option to
> point to the official tree.  That means that the maintainer's trees
> would not need the full set of all the objects in the tree as the main
> tree will be used as a reference for those.  This greatly reduces the
> storage overhead for those trees.

Right. OTOH, fro all repos hosted  on  the  same  server  the  object
database  would  consist  of hardlinks anyway, which is very cheap in
terms of storage overhead.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Work 8 hours, sleep 8 hours; but not the same 8 hours.

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Dear Jerry,

in message <45AF8834.9050904@smiths-aerospace.com> you wrote:
> 
> It I don't know if the request is reasonable in terms of disk space and 
> burdening denx.de with administrative work, but it would be nice if the 
> primary maintainers had their official feeder repositories on the 

There is no problem with that from our side, but I tend to leave  the
decision up to the respective custodians. They will have wo work with
the  repos,  and  they  should be able to do it in the way that seems
most efficient to them.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Use the Force, Luke.

[U-Boot-Users] Changes to U-Boot Development Process

[Kim Phillips]

On Thu, 18 Jan 2007 17:23:01 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Dear Jerry,
> 
> in message <45AF8834.9050904@smiths-aerospace.com> you wrote:
> > 
> > It I don't know if the request is reasonable in terms of disk space and 
> > burdening denx.de with administrative work, but it would be nice if the 
> > primary maintainers had their official feeder repositories on the 
> 
> There is no problem with that from our side, but I tend to leave  the
> decision up to the respective custodians. They will have wo work with
> the  repos,  and  they  should be able to do it in the way that seems
> most efficient to them.
> 
thanks Wolfgang.

I'm also honoured to help, and I'll try, but I still have a couple of questions:

1. what can we do about the 40KB limit on u-boot-users?  A patch for new board support usually requires more than that, and even when given a URL, it's not as easy for people to review the patches properly.

2. what is the utility of the "U-Boot spam^H^H^H^Hpatch tracking system"? and the "DENX Support System" for that matter?  Is it me or are they just cluttering people's inboxes?

3. does a subsystem maintainer get leverage into changes made in the higher level components of Das U-Boot?  E.g., I'm still a firm believer that the device tree source should live in the bootloader ;)

Kim

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Dear Kim,

in message <20070118114051.5c1c64a5.kim.phillips@freescale.com> you wrote:
>
> 1. what can we do about the 40KB limit on u-boot-users? A patch for
> new board support usually requires more than that, and even when
> given a URL, it's not as easy for people to review the patches
> properly.

We may see changes to the mailing list soon. The whole way how SF is
running there "services" and how they (not) respond to support
requests is more and more annoying to me.

Nevertheless, I see actually no reason to change the  size  limit.  I
haven't  seen  any  many  board/ directories that exceed 40..50 kB in
size, and if you compress the patch than the size  limit  should  not
affect you.

It *does* bite you if you ignore the patch submission rules, though,
i. e. the requirement to break patches up into independent, orthogonal
pieces, etc. But that's actually a good thing.

So if you should hit the size limit, the first thing you should do is
asking yourself what you did wrong ;-)

> 2. what is the utility of the "U-Boot spam^H^H^H^Hpatch tracking
> system"? and the "DENX Support System" for that matter? Is it me or
> are they just cluttering people's inboxes?

We (DENX) use OTRS (see http://otrs.org/) for ticket tracking (i.  e.
to handle support calls), and we are also experimenting with using it
as  a  patch  database system. I have to admit that we have not found
yet a configuration that looks satisfying to us, and thus  I  refrain
from making the current state available to others.

I apologize if you feel annoyed by the mails sent by our system,  but
we  need  some tests with the real "public" setup, too. Maybe you can
setup a filter to automatically drop all messages containing  "[DNX#'
in the subject line?

> 3. does a subsystem maintainer get leverage into changes made in the
> higher level components of Das U-Boot? E.g., I'm still a firm
> believer that the device tree source should live in the bootloader ;)

Of course the custodians will play a special role when  it  comes  to
moving  code  upstream. But that does NOT mean that we intend to stop
listening to "normal" users, too. And even as a  custodian  you  will
run into situations where several people will have different point of
views.  Actually  I  expect  that  you would see such situations more
frequently, as then you have to negotiate both up- and downstream.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Nature is very un-American.  Nature never hurries."
- William George Jordan

[U-Boot-Users] Changes to U-Boot Development Process

[Timur Tabi]

Wolfgang Denk wrote:

> Nevertheless, I see actually no reason to change the  size  limit.  I
> haven't  seen  any  many  board/ directories that exceed 40..50 kB in
> size, and if you compress the patch than the size  limit  should  not
> affect you.

Well, compressing makes it difficult to read inside an email.  I think patches 
shouldn't be compressed.

However, I don't know why you would say that adding a new board should be under 
40KB.  Adding a new board typically requires two files: a header file in 
include/configs/, and a .c file in board/xxx/.  The .c file is actually 
accompanied by a config file, a Makefile, an lds file, and maybe some other .c 
files.

The sum total of all these files is usually more than 40KB.  I think what you're 
suggesting is that the patch be divided into two patches: one that contains the 
header file, and the other that contains the rest, but that doesn't make sense. 
  All of these files belong together as a single commit, because U-Boot can't be 
compiled without all of them together.

I think the 40KB limit should be increased to 100KB.  That's enough to support 
all files for an entire board.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <45AFE49B.8080909@freescale.com> you wrote:
> 
> However, I don't know why you would say that adding a new board should be under 
> 40KB.  Adding a new board typically requires two files: a header file in 
> include/configs/, and a .c file in board/xxx/.  The .c file is actually 
> accompanied by a config file, a Makefile, an lds file, and maybe some other .c 
> files.

Right.

> The sum total of all these files is usually more than 40KB.  I think what you're 

Just run a check like "du -sh board/*" - most board directories  take
20...50  kB,  plus  - say - 8...15 kB for the board config file. This
fits easily in the 40 kB limit if compressed.

And, let's face it, adding new boards is the exception. Count how many
patches have been submitted so far, and how many boards we support.
It's a completely insignificant fraction. I don't think it would be a
good idea to fix the limits to suite such exceptions. These can be
compressed. 

And if a normal patch, uncompressed, exceeds the 40 kB limit, then it
should be probably be split  up  because  it's  too  big  for  review
anyway.

> suggesting is that the patch be divided into two patches: one that contains the 
> header file, and the other that contains the rest, but that doesn't make sense. 
>   All of these files belong together as a single commit, because U-Boot can't be 
> compiled without all of them together.

Agreed.

> I think the 40KB limit should be increased to 100KB.  That's enough to support 
> all files for an entire board.

I still disagree. Believe me, the 40 kB size has never  been  a  real
problem  for regular patch submissions so far. The cases where it hit
where usually when the poster did not follow the rules, and I want to
keep such a built-in filter function.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The optimum committee has no members.
                                                   - Norman Augustine

[U-Boot-Users] Changes to U-Boot Development Process

[Stefan Roese]

Hi Wolfgang,

On Thursday 18 January 2007 22:40, Wolfgang Denk wrote:
> > The sum total of all these files is usually more than 40KB.  I think what
> > you're
>
> Just run a check like "du -sh board/*" - most board directories  take
> 20...50  kB,  plus  - say - 8...15 kB for the board config file. This
> fits easily in the 40 kB limit if compressed.
>
> And, let's face it, adding new boards is the exception. Count how many
> patches have been submitted so far, and how many boards we support.
> It's a completely insignificant fraction. I don't think it would be a
> good idea to fix the limits to suite such exceptions. These can be
> compressed.

I'm with the Freescale guys here. I don't like compressed patches. This 
requires some extra steps to review (at least for me) and normally I am too 
lazy to do this right away when reading the mails. Even if these boards 
support patches are not that frequent, there should be no "obstacle" to send 
them inline.

Best regards,
Stefan

[U-Boot-Users] Changes to U-Boot Development Process

[Grant Likely]

On 1/19/07, Stefan Roese <sr@denx.de> wrote:
> On Thursday 18 January 2007 22:40, Wolfgang Denk wrote:
> > And, let's face it, adding new boards is the exception. Count how many
> > patches have been submitted so far, and how many boards we support.
> > It's a completely insignificant fraction. I don't think it would be a
> > good idea to fix the limits to suite such exceptions. These can be
> > compressed.
>
> I'm with the Freescale guys here. I don't like compressed patches. This
> requires some extra steps to review (at least for me) and normally I am too
> lazy to do this right away when reading the mails. Even if these boards
> support patches are not that frequent, there should be no "obstacle" to send
> them inline.

Throw my vote in there too.  I tend not to read non-inline patches.

g.

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

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <528646bc0701182337s7467482tba38b3aba66e7de4@mail.gmail.com> you wrote:
>
> Throw my vote in there too.  I tend not to read non-inline patches.

Seems I'm standing in the corner here.

But be honest: do you really read patches of 40  kB  and  more  using
your MUA? IF you do, then it's probably a powerful tool (emacs?) that
can  be  configured  to automatically display compressed attachments,
too?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nothing ever becomes real until it is experienced.       - John Keats

[U-Boot-Users] Changes to U-Boot Development Process

[Grant Likely]

On 1/19/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc0701182337s7467482tba38b3aba66e7de4@mail.gmail.com> you wrote:
> >
> > Throw my vote in there too.  I tend not to read non-inline patches.
>
> Seems I'm standing in the corner here.
>
> But be honest: do you really read patches of 40  kB  and  more  using
> your MUA? IF you do, then it's probably a powerful tool (emacs?) that
> can  be  configured  to automatically display compressed attachments,
> too?

I was only commenting on non-inline patches, not the message size limit.

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

[U-Boot-Users] Changes to U-Boot Development Process

[Timur Tabi]

Wolfgang Denk wrote:

> But be honest: do you really read patches of 40  kB  and  more  using
> your MUA? 

Yes, I do.

> IF you do, then it's probably a powerful tool (emacs?) that
> can  be  configured  to automatically display compressed attachments,
> too?

Maybe there is, but I doubt there will be such a tool for everyone.  I 
use Mozilla to read email, and I know of no plugin that can display a 
compressed text file on my Mac.

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Dear Stefan,

in message <200701190818.08895.sr@denx.de> you wrote:
> 
> > And, let's face it, adding new boards is the exception. Count how many
> > patches have been submitted so far, and how many boards we support.
> > It's a completely insignificant fraction. I don't think it would be a
> > good idea to fix the limits to suite such exceptions. These can be
> > compressed.
> 
> I'm with the Freescale guys here. I don't like compressed patches. This 

I agree 100% with you  here.  But  we  should  not  try  to  use  the
exceptions  as standard for setting up the message limits. The number
of cases, where a good and valid patch exceeds the  40  kB  limit  is
*very* small. And if somebody submits new code, you will probably not
only view it in your mailer, you will apply the patch, run MAKEALL to
see  if  it  comples  cleanly,  etc. - which means that you will most
probably use your  preferred  text  editor  for  reviewing  the  code
instead of reading it in your MUA.

In the past, you helped a lot to  review  patches  for  coding  style
violations.  I  guess  you  did  not do this in your MUA context, but
using a text editor instead?

Also, there is always the possibility to split a patch.

Ummm... is there a size limit on other mailing lists - say on lkml or
linuxppc-dev?

> requires some extra steps to review (at least for me) and normally I am too 
> lazy to do this right away when reading the mails. Even if these boards 
> support patches are not that frequent, there should be no "obstacle" to send 
> them inline.

Well, you have never seen the messages that have been blocked by  the
mailing  list's  size  limit.  I *did* see (and usually reject) them.
Believe me, this filter function has always been very useful.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All this doesn't alter anything, you know. The world is still full of
stupid people. They don't use their brains. They don't seem  to  want
to think straight.                    - Terry Pratchett, _Soul Music_

[U-Boot-Users] Changes to U-Boot Development Process

[Stefan Roese]

Hi Wolfgang,

On Friday 19 January 2007 11:05, Wolfgang Denk wrote:
> > I'm with the Freescale guys here. I don't like compressed patches. This
>
> I agree 100% with you  here.  But  we  should  not  try  to  use  the
> exceptions  as standard for setting up the message limits. The number
> of cases, where a good and valid patch exceeds the  40  kB  limit  is
> *very* small. And if somebody submits new code, you will probably not
> only view it in your mailer, you will apply the patch, run MAKEALL to
> see  if  it  comples  cleanly,  etc. - which means that you will most
> probably use your  preferred  text  editor  for  reviewing  the  code
> instead of reading it in your MUA.
>
> In the past, you helped a lot to  review  patches  for  coding  style
> violations.  I  guess  you  did  not do this in your MUA context, but
> using a text editor instead?

It would have been a lot easier _if_ I could have reviewed the patch in my MUA 
context. At least this is my working experience. It is always a hassle for me 
to get the quoted code ("> ") back to the list when the original mail is not 
inlined.

You're right of course, this inline review is "only" helpful for coding style 
violations and apparently wrong or buggy code. But for this it makes the 
review much easier andI can do the review "on the fly", by just reading the 
mail and simply responding.

> Also, there is always the possibility to split a patch.
>
> Ummm... is there a size limit on other mailing lists - say on lkml or
> linuxppc-dev?

I would be very interested how this is handled in other lists too.

> > requires some extra steps to review (at least for me) and normally I am
> > too lazy to do this right away when reading the mails. Even if these
> > boards support patches are not that frequent, there should be no
> > "obstacle" to send them inline.
>
> Well, you have never seen the messages that have been blocked by  the
> mailing  list's  size  limit.  I *did* see (and usually reject) them.
> Believe me, this filter function has always been very useful.

Yes, you're right here. :-)

Best regards,
Stefan

[U-Boot-Users] Changes to U-Boot Development Process

[Timur Tabi]

Stefan Roese wrote:

> It would have been a lot easier _if_ I could have reviewed the patch in my MUA 
> context. At least this is my working experience. It is always a hassle for me 
> to get the quoted code ("> ") back to the list when the original mail is not 
> inlined.

I agree with this 100%.

>> Also, there is always the possibility to split a patch.
>>
>> Ummm... is there a size limit on other mailing lists - say on lkml or
>> linuxppc-dev?
> 
> I would be very interested how this is handled in other lists too.

u-boot-users is the only mailing list I've encountered that has an (in 
my opinion) unreasonably low limit.  That's why I suggested increasing 
the limit to 100KB.

One person in Freescale once made a patch that was over 400KB, and we 
asked him to rewrite it because he included multiple types of changes 
into one patch.  Even with the changes, the 40KB limit was a real 
problem, but 100KB would have made things a lot easier.

[U-Boot-Users] Changes to U-Boot Development Process

[Josh Boyer]

On 1/19/07, Wolfgang Denk <wd@denx.de> wrote:
>
> Ummm... is there a size limit on other mailing lists - say on lkml or
> linuxppc-dev?

lkml (actually I think any list on vger.kernel.org) has a size limit of 100K.

josh

[U-Boot-Users] Changes to U-Boot Development Process

[Haavard Skinnemoen]

On 1/19/07, Josh Boyer <jwboyer@gmail.com> wrote:
> On 1/19/07, Wolfgang Denk <wd@denx.de> wrote:
> >
> > Ummm... is there a size limit on other mailing lists - say on lkml or
> > linuxppc-dev?
>
> lkml (actually I think any list on vger.kernel.org) has a size limit of 100K.

But compressed patches are not allowed (or at least frowned upon) on
lkml. Documentation/SubmittingPatches actually states that the limit
is 40K uncompressed:

"Large changes are not appropriate for mailing lists, and some
maintainers.  If your patch, uncompressed, exceeds 40 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch."

However, I think the actual hard limit is 100k as you say. If we're
going to raise the size limit, I vote for requiring patches to be
inline or, for large patches, at a web server.

Haavard

[U-Boot-Users] Changes to U-Boot Development Process

[Rodolfo Giometti]

On Thu, Jan 18, 2007 at 09:46:12AM -0500, Jerry Van Baren wrote:

> It I don't know if the request is reasonable in terms of disk space and 
> burdening denx.de with administrative work, but it would be nice if the 
> primary maintainers had their official feeder repositories on the 
> denx.de site.  It is _very_ useful to have the feeder git repositories 
> in one place for easy reference, and that way the repositories would 
> tend to be more stable and available.

I can offer part of my disk space with absolutely no problem!

Currently my main problem is the download bandwidth (from my server to the
internet) but I'm planning to double it ASAP.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <20070118185057.GC12754@enneenne.com> you wrote:
> 
> I can offer part of my disk space with absolutely no problem!

Thanks, but we're really short on space or bandwidth. We  can  handle
this easily if the custodians want it that way.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sometimes a feeling is all we humans have to go on.
	-- Kirk, "A Taste of Armageddon", stardate 3193.9

[U-Boot-Users] Changes to U-Boot Development Process

[Tolunay Orkun]

Wolfgang Denk wrote:

> Do we have an immediate line of volunteers raising in the first row?
>
> Skimming through the archives we came up with a list of people  which
> the  U-Boot  project  already  is indebted to and probably being good
> candidates for custodians. Of course this list cannot  and  does  not
> want  to  be  a  "credits"  list  of  all  the valuable people having
> contributed, so please don't attribute anything else to it as being a
> starting point for this new maintenance mode. Also there are multiple
> suggestions where ultimately of course we would like the community to
> decide.
>
> So with all these precautions in place, here we go:
>
> ARM architecture	Richard Woodruff, Peter Pearse
> AVR32 architecture	Haavard Skinnemoen
> Blackfin architecture	Aubrey Li
> Intel IXP architecture	Stefan Roese
> ColdFire architecture	Stefan Roese
> Microblaze architecture	Michal Simek
> MIPS architecture	Rodolfo Giometti, Andrew Dyer
> MPC83xx architecture	Kim Phillips
> MPC85xx architecture	Jon Loelinger
> MPC86xx architecture	Jon Loelinger
> MPC8xx architecture	Wolfgang Denk
> NIOS(2)			Scott McNutt
> PPC4xx architecture	Stefan Roese
>
> CFI FLASH driver	Tolunay Orkun
>   

I am honored. I do not have hosting capability right now so this part of 
the tree will need to be hosted on your site for the time being.

I guess you will detail the working protocol push/pull, conflict 
resolution, documentation etc. in more detail in the near future.

> NAND FLASH subsystem	Ladislav Michl, Stefan Roese
> USB drivers		Markus Klotzb?cher
>
> So thanks for bearing with  us  through  this  longwinded  mail  that
> hopefully starts to pave the way to a new level of quality and extent
> of  the  U-Boot project that is only possibly through its very active
> community - you!
>   

Thanks for being such a good (and sometimes mis-understood) gatekeeper. 
Your leadership made U-Boot an open source standard.

Best regards,
Tolunay

[U-Boot-Users] Changes to U-Boot Development Process

[Haavard Skinnemoen]

On 1/17/07, Wolfgang Denk <wd@denx.de> wrote:

> Do we have an immediate line of volunteers raising in the first row?
>
> AVR32 architecture      Haavard Skinnemoen

Thanks, I'll do my best in keeping the quality of the AVR32 port as
good as the rest of the tree. I welcome this change in the development
process, since I believe the new model will scale very well, as the
Linux Kernel project has shown.

I think I will keep publishing our stuff on www.atmel.no, since I'm
working behind a proxy and that's the only server I can push to
directly. But if all the other arch trees end up on denx.de, I can
probably set up a cronjob somewhere to sync the two trees, or just do
the push in two stages.

Best regards,
Haavard

[U-Boot-Users] Changes to U-Boot Development Process

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> On 1/17/07, Wolfgang Denk <wd@denx.de> wrote:
> 
>> Do we have an immediate line of volunteers raising in the first row?
>>
>> AVR32 architecture      Haavard Skinnemoen
> 
> Thanks, I'll do my best in keeping the quality of the AVR32 port as
> good as the rest of the tree. I welcome this change in the development
> process, since I believe the new model will scale very well, as the
> Linux Kernel project has shown.
> 
> I think I will keep publishing our stuff on www.atmel.no, since I'm
> working behind a proxy and that's the only server I can push to
> directly. But if all the other arch trees end up on denx.de, I can
> probably set up a cronjob somewhere to sync the two trees, or just do
> the push in two stages.
> 
> Best regards,
> Haavard

...or Wolfgang can mirror the remote repositories by simply having a 
cron job do a git pull periodically.  That is probably the easiest and 
best solution.  It is trivial to pull, harder to push.

It sounds like denx.de has both the disk and bandwidth resources to 
support the feeder repositories (Wolfgang's message on that was a little 
confusing).  I continue to advocate having all the git repositories 
(either mirror or primary) on one site for easy reference and availability.

Thanks,
gvb

[U-Boot-Users] Changes to U-Boot Development Process

[Michal Simek]

Hi,

> Microblaze architecture Michal Simek

Thanks, I am honored.  I'll do my best in keeping the quality of the 
Microblaze
port as good as the rest of the tree.

Best regards,
Michal Simek 

[U-Boot-Users] Changes to U-Boot Development Process

[Guennadi Liakhovetski]

On Wed, 17 Jan 2007, Wolfgang Denk wrote:

> ARM architecture	Richard Woodruff, Peter Pearse
> AVR32 architecture	Haavard Skinnemoen
> Blackfin architecture	Aubrey Li
> Intel IXP architecture	Stefan Roese
> ColdFire architecture	Stefan Roese
> Microblaze architecture	Michal Simek
> MIPS architecture	Rodolfo Giometti, Andrew Dyer
> MPC83xx architecture	Kim Phillips
> MPC85xx architecture	Jon Loelinger
> MPC86xx architecture	Jon Loelinger
> MPC8xx architecture	Wolfgang Denk
> NIOS(2)			Scott McNutt
> PPC4xx architecture	Stefan Roese
> 
> CFI FLASH driver	Tolunay Orkun
> NAND FLASH subsystem	Ladislav Michl, Stefan Roese
> USB drivers		Markus Klotzb?cher

Wolfgang, thanks for maintaining this whole zoo alone up to now and for 
doing this, I too hope this change will be to the better.

One question, what is a u-boot architecture? If it is equivalent to a 
directory under cpu/ tree, then does it mean that directories not listed 
here are still maintained by you? Ok, ARM is a collection of about a half 
of those directories:-) But you splitted (almost) every PPC directory 
separately. But what about 82xx (8220, 824x, 8260 directories)? Or are 
they counted under 4xx?

Thanks
Guennadi
---
Guennadi Liakhovetski

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Dear Guennadi,

in message <Pine.LNX.4.60.0701212118370.4555@poirot.grange> you wrote:
> 
> Wolfgang, thanks for maintaining this whole zoo alone up to now and for 
> doing this, I too hope this change will be to the better.

So do I.

> One question, what is a u-boot architecture? If it is equivalent to a 

It's a processor architecture.
> directory under cpu/ tree, then does it mean that directories not listed 
> here are still maintained by you? Ok, ARM is a collection of about a half

Well, yes, unless we have a volunteer I will continue to take care of
all the rest.

The problem is that it's not at all clear how to divide everything
into subsystems such that there is no overlapping and everything is
still covered. So we try and start with the obvious.

> of those directories:-) But you splitted (almost) every PPC directory 
> separately. But what about 82xx (8220, 824x, 8260 directories)? Or are 
> they counted under 4xx?

They were simply forgotten. And no, 82xx not the same as  4xx  -  the
former  is  Freesale, the latter is AMCC processors, which are pretty
different.

As long as nobody volunteers these are simply still on my list - they
are low traffic these days anyway.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Your own mileage may vary.

[U-Boot-Users] Changes to U-Boot Development Process

[Guennadi Liakhovetski]

On Sun, 21 Jan 2007, Wolfgang Denk wrote:

> The problem is that it's not at all clear how to divide everything
> into subsystems such that there is no overlapping and everything is
> still covered. So we try and start with the obvious.

That's exactly why I asked "what you mean by an architecture":-)

> > of those directories:-) But you splitted (almost) every PPC directory 
> > separately. But what about 82xx (8220, 824x, 8260 directories)? Or are 
> > they counted under 4xx?
> 
> They were simply forgotten. And no, 82xx not the same as  4xx  -  the
> former  is  Freesale, the latter is AMCC processors, which are pretty
> different.
> 
> As long as nobody volunteers these are simply still on my list - they
> are low traffic these days anyway.

Good.

Thanks
Guennadi
---
Guennadi Liakhovetski

[U-Boot-Users] Changes to U-Boot Development Process

[Sam Song]

Wolfgang Denk <wd@denx.de> wrote:
> > separately. But what about 82xx (8220, 824x, 8260
> > directories)? Or are they counted under 4xx?
> 
> They were simply forgotten. And no, 82xx not the
> same as  4xx - the former  is  Freesale, the latter 
> is AMCC processors, which are pretty
> different.
> 
> As long as nobody volunteers these are simply still
> on my list - they are low traffic these days anyway.

So it does for 74xx_7xx as well?

Thanks,

Sam



		
___________________________________________________________ 
??????-3.5G???20M?? 
http://cn.mail.yahoo.com/

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <201842.62473.qm@web15906.mail.cnb.yahoo.com> you wrote:
>
> > As long as nobody volunteers these are simply still
> > on my list - they are low traffic these days anyway.
> 
> So it does for 74xx_7xx as well?

If nobody else volunteers for it...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nobody goes to that restaurant anymore. It's too crowded.

[U-Boot-Users] Changes to U-Boot Development Process

[Aubrey Li]

On 1/18/07, Wolfgang Denk <wd@denx.de> wrote:
> Hello,
>
> many of you know  all  too  well  that  we  have  problems  with  the
> development  process  of U-Boot. The biggest problem is that it takes
> much too long until new contributed code  finds  it's  way  into  the
> public source code repository.
>
> Switching from CVS to git helped a lot on the technical side. It  was
> especially  important  as  it also opened the door for organizational
> changes, which are urgently needed.
>
> We've been discussion these issues for some time,  and  here  is  our
> joint proposal. "We", that is mostly Detlev Zundel, Stefan Roese, and
> me  (Wolfgang  Denk).  Of  course  we  also had input form many other
> sources.
>
>
> As this mail will propose quite a fundamental change for  the  U-Boot
> project, please allow us to introduce it with a few short reflections
> on the current state of affairs.
>
> Being a regular reader of this list you will be well aware that  even
> with  all the problems in the development process and some ugly areas
> in the U-Boot code (like the #ifdef mazes)  there  is  one  important
> feature:  that's  the  quality  of  the  U-Boot  code  base  -  being
> highlighted quite well by the literal absence of temporary  breakages
> in  the  development  code base. This alone allows for the well known
> "use the latest code from the repository" answer when someone  enters
> the  grounds  of this project for the first time. It is well worth to
> reflect on this quality for a little while.
>
> Having done that we may well ask where this quality  comes  from?  We
> think  that anybody reading this list only for a limited time will be
> able to come up with the answer, namely  the  continuous  maintenance
> effort  of  Wolfgang  and  his modus operandi of personally reviewing
> nearly each and every contribution in this multi-architecture project
> supporting hundreds of boards. It should  be  obvious  how  important
> such  a  level  of  code  review  is to keep U-Boot from falling into
> disconnected pieces - just think of the effort  to  keep  aspects  of
> U-Boot similar across all supported architectures.
>
> But of course even Wolfgang only  has  24  hours  per  day,  and  the
> positive  effect  of this maintenance mode has shrunk continuously in
> comparison to the downside  of  the  embarassingly  long  backlog  of
> patches  posted  on  this  mailing  list  waiting  to  be  processed,
> rendering new lines of development very difficult to say the least.
>
> So the time is more than ripe to change this while explicitely trying
> to keep the quality of the  project  on  the  high  grounds  that  we
> brazenly claim for it :)
>
> Gladly there are other projects in the F/OSS community that are worth
> taking a peek at to snatch a hint or two on how we  can  tackle  this
> task.
>
> Considering all this we propose a change in  maintaining  the  U-Boot
> code base to a model similar to what is currently being done with the
> Linux  kernel,  namely  we  would  like  to  establish a community of
> "custodian"  maintainers,  responsible   for   certain   sub-systems,
> aspects, architectures, or board families of the U-Boot source tree.
>
> We would like to follow the Linux precedent by assembling a  list  of
> people  willing  to  invest  time  and  effort into this; the already
> existing MAINTAINERS file will serve  a  new  function  to  list  the
> individual  custodians with their corresponding area of responsibilty
> and contact information.
>
> Each custodian will have to administrate  his  or  her  git  tree  to
> streamline transparent development and integration (pulling) into the
> "official"  U-Boot repository. If the need should arise (for example,
> if a custodian doesn't have convenient means  to  host  it  himself),
> DENX will of course be glad to host such trees.
>
> The stated goal of this change of course is to spread the  burden  of
> maintaining U-Boot to more shoulders so we can hopefully dramatically
> cut  down  on  the  current lag between a patch being proposed on the
> mailing list and being processed - be that  accepting,  rejecting  or
> openly discussing it with the community.
>
> As you must have realized by now, this cannot  be  done  without  the
> community  participating,  so  what  do  you  think of this idea? Any
> comments or suggestions?
>
>
> Of course we should be honest right  upfront  and  state  that  as  a
> custodian  you  would  be  fully  responsible  for "your" part of the
> U-Boot source tree and it is unfortunately necessary,  that  you  are
> able to commit to a certain amount of time and willingness to discuss
> topics on the mailing list for this maintenance.
>
> Do we have an immediate line of volunteers raising in the first row?
>
> Skimming through the archives we came up with a list of people  which
> the  U-Boot  project  already  is indebted to and probably being good
> candidates for custodians. Of course this list cannot  and  does  not
> want  to  be  a  "credits"  list  of  all  the valuable people having
> contributed, so please don't attribute anything else to it as being a
> starting point for this new maintenance mode. Also there are multiple
> suggestions where ultimately of course we would like the community to
> decide.
>
> So with all these precautions in place, here we go:
>
> ARM architecture        Richard Woodruff, Peter Pearse
> AVR32 architecture      Haavard Skinnemoen
> Blackfin architecture   Aubrey Li

I'd be honored to take responsibility for Blackfin architecture.

Best regards,
-Aubrey

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Dear Aubrey,

in message <27d85ee10701252022n2540839at6767798f8baabdb@mail.gmail.com> you wrote:
>
> I'd be honored to take responsibility for Blackfin architecture.

Thanks a lot!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Es ist offensichtlich, dass das menschliche Gehirn wie  ein  Computer
funktioniert.  Da  es  keine  dummen Computer gibt, gibt es also auch
keine dummen Menschen. Nur ein paar Leute, die unter DOS laufen.
                                                       -- <unbekannt>

[U-Boot-Users] Changes to U-Boot Development Process

[Aubrey Li]

On 1/18/07, Wolfgang Denk <wd@denx.de> wrote:
> Hello,
>
> many of you know  all  too  well  that  we  have  problems  with  the
> development  process  of U-Boot. The biggest problem is that it takes
> much too long until new contributed code  finds  it's  way  into  the
> public source code repository.
>
> Switching from CVS to git helped a lot on the technical side. It  was
> especially  important  as  it also opened the door for organizational
> changes, which are urgently needed.
>
> We've been discussion these issues for some time,  and  here  is  our
> joint proposal. "We", that is mostly Detlev Zundel, Stefan Roese, and
> me  (Wolfgang  Denk).  Of  course  we  also had input form many other
> sources.
>
>
> As this mail will propose quite a fundamental change for  the  U-Boot
> project, please allow us to introduce it with a few short reflections
> on the current state of affairs.
>
> Being a regular reader of this list you will be well aware that  even
> with  all the problems in the development process and some ugly areas
> in the U-Boot code (like the #ifdef mazes)  there  is  one  important
> feature:  that's  the  quality  of  the  U-Boot  code  base  -  being
> highlighted quite well by the literal absence of temporary  breakages
> in  the  development  code base. This alone allows for the well known
> "use the latest code from the repository" answer when someone  enters
> the  grounds  of this project for the first time. It is well worth to
> reflect on this quality for a little while.
>
> Having done that we may well ask where this quality  comes  from?  We
> think  that anybody reading this list only for a limited time will be
> able to come up with the answer, namely  the  continuous  maintenance
> effort  of  Wolfgang  and  his modus operandi of personally reviewing
> nearly each and every contribution in this multi-architecture project
> supporting hundreds of boards. It should  be  obvious  how  important
> such  a  level  of  code  review  is to keep U-Boot from falling into
> disconnected pieces - just think of the effort  to  keep  aspects  of
> U-Boot similar across all supported architectures.
>
> But of course even Wolfgang only  has  24  hours  per  day,  and  the
> positive  effect  of this maintenance mode has shrunk continuously in
> comparison to the downside  of  the  embarassingly  long  backlog  of
> patches  posted  on  this  mailing  list  waiting  to  be  processed,
> rendering new lines of development very difficult to say the least.
>
> So the time is more than ripe to change this while explicitely trying
> to keep the quality of the  project  on  the  high  grounds  that  we
> brazenly claim for it :)
>
> Gladly there are other projects in the F/OSS community that are worth
> taking a peek at to snatch a hint or two on how we  can  tackle  this
> task.
>
> Considering all this we propose a change in  maintaining  the  U-Boot
> code base to a model similar to what is currently being done with the
> Linux  kernel,  namely  we  would  like  to  establish a community of
> "custodian"  maintainers,  responsible   for   certain   sub-systems,
> aspects, architectures, or board families of the U-Boot source tree.
>
> We would like to follow the Linux precedent by assembling a  list  of
> people  willing  to  invest  time  and  effort into this; the already
> existing MAINTAINERS file will serve  a  new  function  to  list  the
> individual  custodians with their corresponding area of responsibilty
> and contact information.
>
> Each custodian will have to administrate  his  or  her  git  tree  to
> streamline transparent development and integration (pulling) into the
> "official"  U-Boot repository. If the need should arise (for example,
> if a custodian doesn't have convenient means  to  host  it  himself),
> DENX will of course be glad to host such trees.

So does custodian have permission to push his commit into the official
repository or the present maintainers are still responsible for
pulling all of the subpart trees regularly and integrate into upstream
repository?

-Aubrey

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <27d85ee10701260031s5a67f074x3bee8c4590df97e1@mail.gmail.com> you wrote:
>
> So does custodian have permission to push his commit into the official
> repository or the present maintainers are still responsible for
> pulling all of the subpart trees regularly and integrate into upstream
> repository?

The custodians will have their own repository, from where I will pull
it into the official repo. But we  intend  to  host  the  custodian's
repositories  (or  at least an automatically updated copy) all on the
same server, so it will be possible for everyone to access this  code
even if the merging in the official tree should get delayed.

At lest that's the current theory. We'll probably  learn  what  works
bet when we are on that way.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I've got to get something inside me. Some coffee  or  something.  And
then the world will somehow be better.
                                     - Terry Pratchett, _Men at Arms_

[U-Boot-Users] Changes to U-Boot Development Process

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <27d85ee10701260031s5a67f074x3bee8c4590df97e1@mail.gmail.com> you wrote:
>> So does custodian have permission to push his commit into the official
>> repository or the present maintainers are still responsible for
>> pulling all of the subpart trees regularly and integrate into upstream
>> repository?
> 
> The custodians will have their own repository, from where I will pull
> it into the official repo. But we  intend  to  host  the  custodian's
> repositories  (or  at least an automatically updated copy) all on the
> same server, so it will be possible for everyone to access this  code
> even if the merging in the official tree should get delayed.
> 
> At lest that's the current theory. We'll probably  learn  what  works
> bet when we are on that way.
> 
> Best regards,
> 
> Wolfgang Denk

My somewhat limited experience with git has been _very_ positive WRT 
pulling from multiple git sources to make a "mash-up" git.  The best 
case scenario I envision is that the feeder git repos maintain patches 
as individual branches.  This way, not only can denx.de (Wolfgang) pull 
patches individually into the master repo, but also I can make my own 
"mash-up" git is based on the master repo with my favorite/necessary 
patches pulled in as branches and merged into my working branch.

Git has tracking knowledge of changes, full genealogy of the sources. 
When a patch is accepted and pulled into the master repo, git recognizes 
that my local "mash-up" already has that patch and simply fast-forwards 
in my "mash-up" repo and says "my, that was easy."  At that point, the 
branches in the feeder repo and my "mash-up" repo can be deleted.

Cheap ASCII art

denx.de
   |   \ \__________
   |    \           \
   |    Feeder1 ... FeederN
   |    |   \  \___
   |    |   |      \
   |    | (Patch1) (Patch2)
   |    |
   |   /
   |  /
Mashup

Mashup Branches:
* denx          - tracks the master repo (or just use "origin")
* Feeder1       - branch tracking the feeder (one per feeder)
* MyPatch1      - my patch waiting to be pulled by a feeder
* working       - my test area, merges (locally pulls in) the
                     branches denx, Feeder1-Patch1, Feeder1-Patch2,
                     MyPatch1, etc.
* releaseXX     - branch for a release made up of appropriate
                     patches merged in (Q: should this be a branch
                     at all, one branch for all releases, or a
                     branch for each release?)
* ...others

Disclaimer: I have not actually done _all_ of the above, just pieces of 
it.  I could be full of BS and misunderstandings.  Any corrections and 
advice from Those With Real Experience[tm]?

Best regards,
gvb

[U-Boot-Users] Changes to U-Boot Development Process

[Aubrey Li]

On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <27d85ee10701260031s5a67f074x3bee8c4590df97e1@mail.gmail.com> you wrote:
> >
> > So does custodian have permission to push his commit into the official
> > repository or the present maintainers are still responsible for
> > pulling all of the subpart trees regularly and integrate into upstream
> > repository?
>
> The custodians will have their own repository, from where I will pull
> it into the official repo. But we  intend  to  host  the  custodian's
> repositories  (or  at least an automatically updated copy) all on the
> same server, so it will be possible for everyone to access this  code
> even if the merging in the official tree should get delayed.
>

It's good, :).
I'm glad to place blackfin's git repo at denx server.
How to apply an account to access the server?

Best regards,
-Aubrey

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <27d85ee10701260752t670ea4a7wda632d7605b72699@mail.gmail.com> you wrote:
>
> It's good, :).
> I'm glad to place blackfin's git repo at denx server.
> How to apply an account to access the server?

Patience, please. We're not that far yet.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Compatibility:
     your old Windows 3.11 application crash exactly as the new ones.

[U-Boot-Users] Changes to U-Boot Development Process

[Grant Likely]

On 1/17/07, Wolfgang Denk <wd@denx.de> wrote:
> We would like to follow the Linux precedent by assembling a  list  of
> people  willing  to  invest  time  and  effort into this; the already
> existing MAINTAINERS file will serve  a  new  function  to  list  the
> individual  custodians with their corresponding area of responsibilty
> and contact information.
>
> Each custodian will have to administrate  his  or  her  git  tree  to
> streamline transparent development and integration (pulling) into the
> "official"  U-Boot repository. If the need should arise (for example,
> if a custodian doesn't have convenient means  to  host  it  himself),
> DENX will of course be glad to host such trees.

With this new process, can I request that *ALL* patches still go
across the list before being pushed to mainline by the custodian?  I
include here patches written by the custodian him/herself.

I worry that we'll end up with an uncontrolled free for all if
custodians start pushing patches that haven't been posted here first.

Cheers,
g.

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

[U-Boot-Users] Changes to U-Boot Development Process

[Josh Boyer]

On 1/26/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/17/07, Wolfgang Denk <wd@denx.de> wrote:
> > We would like to follow the Linux precedent by assembling a  list  of
> > people  willing  to  invest  time  and  effort into this; the already
> > existing MAINTAINERS file will serve  a  new  function  to  list  the
> > individual  custodians with their corresponding area of responsibilty
> > and contact information.
> >
> > Each custodian will have to administrate  his  or  her  git  tree  to
> > streamline transparent development and integration (pulling) into the
> > "official"  U-Boot repository. If the need should arise (for example,
> > if a custodian doesn't have convenient means  to  host  it  himself),
> > DENX will of course be glad to host such trees.
>
> With this new process, can I request that *ALL* patches still go
> across the list before being pushed to mainline by the custodian?  I
> include here patches written by the custodian him/herself.

That seems like a good idea.

josh

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <528646bc0701260049g59aa159fua9e06b75c914c25d@mail.gmail.com> you wrote:
>
> With this new process, can I request that *ALL* patches still go
> across the list before being pushed to mainline by the custodian?  I
> include here patches written by the custodian him/herself.

We didn't always do this so far. In the past,  me  and  others  (like
Stefan  Roese)  checked  in a lot of stuff that was not posted on the
list before. I  guess  I  would  have  problems  changing  such  opld
habits...

But in general, yes, patches will still be required to be sent to the
mailing list.

> I worry that we'll end up with an uncontrolled free for all if
> custodians start pushing patches that haven't been posted here first.

Agreed.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The easiest way to figure the cost of living is to take  your  income
and add ten percent.

[U-Boot-Users] Changes to U-Boot Development Process

[Peter.Pearse]

Am I on the right lines here?

U-Boot development process
==========================
Gatekeepers have responsibility for some area of U-Boot.

A developer submits a patch via email or requests git pull
[Gatekeepers possibly contend for patch]
Chosen gatekeeper inspects patch for
	Coding style
	Basic logic
	U-Boot ethos (e.g lowest possible size) **1
	MAKEALL **2 
until satisfied
[If not rejected]
Gatekeeper pushes new branch for the patch to the "area git",
and notifies the user list.
As well as a short summary the description may include
	Affected board or area
	Suggested tests
If unable to test sufficiently themselves **2, the gatekeeper request tests 
from specific maintainers and U-Boot users. 
Tests by the original developer are not sufficient.
Once tests are passed, or some agreed time limit expires **3, 
the gatekeeper requests that the area branch be merged into the main tree.
[If necessary, patch is reworked to allow merge] 
	
**1:: Ethos - whereas this used to be in Wolfgang's head we may need to
document some of it.	
**2:: Gatekeepers may not have access to all necessary tools and/or boards
**3:: I think patches should be accepted if no-one (other than the original
developer) 
has tested them within a certain time, but they meet all other criteria.
 

Regards

Peter Pearse

[U-Boot-Users] Changes to U-Boot Development Process

[Grant Likely]

On 2/1/07, Peter.Pearse <peter.pearse@arm.com> wrote:
> Am I on the right lines here?
>
> U-Boot development process
> ==========================
> Gatekeepers have responsibility for some area of U-Boot.
>
> A developer submits a patch via email or requests git pull

I pretty much agree with your flow here, but I would add one thing.

I think *All* patches should go to the mailing list; even gatekeeper
authored ones.  It's not the gatekkeepers responsibility to review
every patch, but rather to make sure all patches are reviewed.  For
example, if a patch is not contentious and has been Ack'd by someone
he/she trusts, then the gatekeeper can probably merge it without
personally reviewing it.

> [Gatekeepers possibly contend for patch]
> Chosen gatekeeper inspects patch for
>         Coding style
>         Basic logic
>         U-Boot ethos (e.g lowest possible size) **1
>         MAKEALL **2
> until satisfied
> [If not rejected]
> Gatekeeper pushes new branch for the patch to the "area git",
> and notifies the user list.
> As well as a short summary the description may include
>         Affected board or area
>         Suggested tests
> If unable to test sufficiently themselves **2, the gatekeeper request tests
> from specific maintainers and U-Boot users.
> Tests by the original developer are not sufficient.
> Once tests are passed, or some agreed time limit expires **3,
> the gatekeeper requests that the area branch be merged into the main tree.
> [If necessary, patch is reworked to allow merge]

Having a merge window has worked extremely well for the Linux kernel.
Does anyone think the same process is appropriate here?

Cheers,
g.

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

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Hello,

it is more than time for a summary of the reactions to  our  proposal
to  split the U-Boot development into several subsystems and to share
the responsibility for these in a  group  of  "custodians".  Here  it
comes:

1) The reaction was all positive. So we will take the next steps in
   that direction.

2) There was a general agreement that it would be beneficial to  have
   all  the  custodian's  (public)  repositories  located on the same
   server, so we willdo that. If nobody objects, we will host this on
   www.denx.de

   We intend to name these repositories after their function (rather,
   for example, after the name of the custodian), so we don't have to
   modify  anything  in  case  there  should  be  a  change  of   the
   custodians.

3) It was no problem to find custodians for all suggested areas.
   Thanks a lot to all of you who volunteered!


You can find an overview about the current situation at
http://www.denx.de/wiki/UBoot/Custodians

This also includes the suggested names for the git repositories.
Please feel free to comment.


To avoid conflicts, I would like to establish a strict match  between
a  repository and a custodian, i. e. each of the git repositories can
be pushed into by exactly one custodian. As you can see,  we  already
have  mostly such matches, only for MIPS we have three instead of one
volunteer.

It's really great to receive so much voluntary help, but in  the  end
we  can  have  only  one  custodian  for  MIPS. However, for me it is
impossible to decide who to chose of Robert, Rodolfo or Hans. Can you
please try to sort this out among the three of you,  eventually  with
feedback from the list?


Custodians: can each of you please send me your public SSH  keys?  We
will  then  set up the git repositories so we can get the whole thing
rocking ASAP... [If you don't want to send it by e-mail, you can also
use jabber: wd at jabber.denx.de].

Thanks in advance,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If the facts don't fit the theory, change the facts.
                                                   -- Albert Einstein

[U-Boot-Users] Changes to U-Boot Development Process

[Rodolfo Giometti]

On Thu, Feb 08, 2007 at 01:52:10AM +0100, Wolfgang Denk wrote:
> 
> To avoid conflicts, I would like to establish a strict match  between
> a  repository and a custodian, i. e. each of the git repositories can
> be pushed into by exactly one custodian. As you can see,  we  already
> have  mostly such matches, only for MIPS we have three instead of one
> volunteer.

No problem for me. I can drop my "nomination" if someone else suppose
to better help the MIPS subtree than me. As already said I have just
one MIPS based board (AU1100)...

On the other side, I'm currently working on LCD and boot LOGO support
for the PXA270 (in the past I sent a patch on these topics for AU1100
but it losts in deep space... :) so, if you agree, I can switch my
nomination on LCD and LOGO support.

Regards,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] Changes to U-Boot Development Process

[Peter Pearse]

Dear All

Anyone volunteering to help test ARM based boards is welcome to add
their details on

http://www.linux-arm.org/LinuxBootLoader/ARMTester

No commitment - when I have a patch for your board I'll notify you, 
you can accept/decline the individual patch.....

Regards

Peter

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Hello,

I would like to get the custodian system finally up and running.

All the  custodian's  (public)  repositories  have  been  set  up  on
www.denx.de and are ready for use.

You can find an overview about the current situation at
	http://www.denx.de/wiki/UBoot/Custodians
plus some usage instructions at
	http://www.denx.de/wiki/UBoot/CustodianGitTrees


As mentioned before, I would like to establish a strict match between
a repository and a custodian, i. e. each of the git repositories  can
be pushed into by exactly one custodian. This is already the case for
all repositories except for the MIPS repo.

For MIPS, we have 3 volunteers. I wrote before:

> It's really great to receive so much voluntary help, but in  the  end
> we  can  have  only  one  custodian  for  MIPS. However, for me it is
> impossible to decide who to chose of Robert, Rodolfo or Hans. Can you
> please try to sort this out among the three of you,  eventually  with
> feedback from the list?

I have received zero responses about this so far. Robert, Rodolfo and
Hans - please comment.

Custodians: those of you who already sent me their SSH keys should be
able to start using their respective repositories immediately.

All the others (i. e. Peter Pearse, Tolunay Orkun, Rafal  Jaworowski,
the  MIPS  custodian,  Andy Fleming, Jon Loelinger, Scott McNutt, and
Markus Klotzb?cher): can each of you please send me your  public  SSH
keys?  [If  you  don't  want  to  send it by e-mail, you can also use
jabber: wd at jabber.denx.de].

Thanks in advance,

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As far as the laws of mathematics refer  to  reality,  they  are  not
certain;  and  as  far  as  they  are  certain,  they do not refer to
reality.                                           -- Albert Einstein

[U-Boot-Users] Changes to U-Boot Development Process

[Aubrey Li]

On 3/6/07, Wolfgang Denk <wd@denx.de> wrote:
> Hello,
>
> I would like to get the custodian system finally up and running.
>
> All the  custodian's  (public)  repositories  have  been  set  up  on
> www.denx.de and are ready for use.
>
> You can find an overview about the current situation at
>         http://www.denx.de/wiki/UBoot/Custodians
> plus some usage instructions at
>         http://www.denx.de/wiki/UBoot/CustodianGitTrees
>
>To start out, after the acoount has been setup, Dave simply clones
the publicly
>available tree as usual:
>
>$ git clone git://www.denx.de/git/u-boot-or32 u-boot-or32

I'm behind of a firewall in office, I can't get the repository by git protocol.
Is it http available like that?
        git-clone http://www.denx.de/git/u-boot.git u-boot-git

Thanks,
-Aubrey

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <27d85ee10703052246m590a2cfev76372ae3cd9d4b6@mail.gmail.com> you wrote:
>
> >To start out, after the acoount has been setup, Dave simply clones the publicly
> >available tree as usual:
> >
> >$ git clone git://www.denx.de/git/u-boot-or32 u-boot-or32
> 
> I'm behind of a firewall in office, I can't get the repository by git protocol.
> Is it http available like that?
>         git-clone http://www.denx.de/git/u-boot.git u-boot-git

For cloning you can use http (or even rsync) as well. But to push your
changes back, you need SSH (+ git).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Success covers a multitude of blunders."       - George Bernard Shaw

[U-Boot-Users] Changes to U-Boot Development Process

[Aubrey Li]

On 3/6/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <27d85ee10703052246m590a2cfev76372ae3cd9d4b6@mail.gmail.com> you wrote:
> >
> > >To start out, after the acoount has been setup, Dave simply clones the publicly
> > >available tree as usual:
> > >
> > >$ git clone git://www.denx.de/git/u-boot-or32 u-boot-or32
> >
> > I'm behind of a firewall in office, I can't get the repository by git protocol.
> > Is it http available like that?
> >         git-clone http://www.denx.de/git/u-boot.git u-boot-git
>
> For cloning you can use http (or even rsync) as well. But to push your
> changes back, you need SSH (+ git).
>
Sorry, it doesn't work on my side.
aubrey at ubuntu-feisty:/tmp$ git-clone
http://www.denx.de/git/u-boot-blackfin u-boot-blackfin
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?

Best Regards,
-Aubrey

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <27d85ee10703060129u26582066kc55912a9424cafe0@mail.gmail.com> you wrote:
>
> > For cloning you can use http (or even rsync) as well. But to push your
> > changes back, you need SSH (+ git).
> >
> Sorry, it doesn't work on my side.
> aubrey at ubuntu-feisty:/tmp$ git-clone http://www.denx.de/git/u-boot-blackfin u-boot-blackfin
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?

You must append ".git" to the repo name. Please try again with

git-clone http://www.denx.de/git/u-boot-blackfin.git u-boot-blackfin

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Wait!  You have not been prepared!
	-- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2

[U-Boot-Users] Changes to U-Boot Development Process

[Aubrey Li]

On 3/6/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <27d85ee10703060129u26582066kc55912a9424cafe0@mail.gmail.com> you wrote:
> >
> > > For cloning you can use http (or even rsync) as well. But to push your
> > > changes back, you need SSH (+ git).
> > >
> > Sorry, it doesn't work on my side.
> > aubrey at ubuntu-feisty:/tmp$ git-clone http://www.denx.de/git/u-boot-blackfin u-boot-blackfin
> > Cannot get remote repository information.
> > Perhaps git-update-server-info needs to be run there?
>
> You must append ".git" to the repo name. Please try again with
>
> git-clone http://www.denx.de/git/u-boot-blackfin.git u-boot-blackfin
>
Oh, It works.
Thanks,
-Aubrey

[U-Boot-Users] Changes to U-Boot Development Process

[Rodolfo Giometti]

On Tue, Mar 06, 2007 at 12:09:38AM +0100, Wolfgang Denk wrote:
> For MIPS, we have 3 volunteers. I wrote before:
> 
> > It's really great to receive so much voluntary help, but in  the  end
> > we  can  have  only  one  custodian  for  MIPS. However, for me it is
> > impossible to decide who to chose of Robert, Rodolfo or Hans. Can you
> > please try to sort this out among the three of you,  eventually  with
> > feedback from the list?
> 
> I have received zero responses about this so far. Robert, Rodolfo and
> Hans - please comment.

I wrote to you on this topic several letters. Maybe you didn't recived
them?! =:-o

However, here my last comment:

On Thu, 8 Feb 2007 16:12:14 +0100, Rodolfo Giometti wrote:

> No problem for me. I can drop my "nomination" if someone else suppose
> to better help the MIPS subtree than me. As already said I have just
> one MIPS based board (AU1100)...
>
> On the other side, I'm currently working on LCD and boot LOGO support
> for the PXA270 (in the past I sent a patch on these topics for AU1100
> but it losts in deep space... :) so, if you agree, I can switch my
> nomination on LCD and LOGO support.

Please, let me know if you receive this message.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <20070306075759.GA6726@gundam.enneenne.com> you wrote:
>
> > I have received zero responses about this so far. Robert, Rodolfo and
> > Hans - please comment.
> 
> I wrote to you on this topic several letters. Maybe you didn't recived
> them?! =:-o

I found just one when I searched my logs; sorry for overlooking this.

> However, here my last comment:

That's what I found.

> On Thu, 8 Feb 2007 16:12:14 +0100, Rodolfo Giometti wrote:
> 
> > No problem for me. I can drop my "nomination" if someone else suppose
> > to better help the MIPS subtree than me. As already said I have just
> > one MIPS based board (AU1100)...

Let's see what Robert and Hans say...

> > On the other side, I'm currently working on LCD and boot LOGO support
> > for the PXA270 (in the past I sent a patch on these topics for AU1100
> > but it losts in deep space... :) so, if you agree, I can switch my
> > nomination on LCD and LOGO support.

Good idea, but let's use a more general name and not restrict  it  to
LCD;  I'll set up a u-boot-video repo. Please send me your public SSH
key.

> Please, let me know if you receive this message.

ACK.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Success covers a multitude of blunders."       - George Bernard Shaw

[U-Boot-Users] Changes to U-Boot Development Process

[Rodolfo Giometti]

On Tue, Mar 06, 2007 at 11:08:18AM +0100, Wolfgang Denk wrote:
> 
> Let's see what Robert and Hans say...

Ok.

> Good idea, but let's use a more general name and not restrict  it  to
> LCD;  I'll set up a u-boot-video repo. Please send me your public SSH
> key.

I'll send it privately. :)

Thanks,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127

[U-Boot-Users] Changes to U-Boot Development Process

[Jon Loeliger]

On Mon, 2007-03-05 at 17:09, Wolfgang Denk wrote:

> 
> Custodians: those of you who already sent me their SSH keys should be
> able to start using their respective repositories immediately.
> 
> All the others (i. e. Peter Pearse, Tolunay Orkun, Rafal  Jaworowski,
> the  MIPS  custodian,  Andy Fleming, Jon Loelinger, Scott McNutt, and
> Markus Klotzb??cher): can each of you please send me your  public  SSH
> keys?  [If  you  don't  want  to  send it by e-mail, you can also use
> jabber: wd at jabber.denx.de].
> 
> Thanks in advance,
> 
> Best regards,
> 
> Wolfgang Denk

Wolfgang,

I will not be able to use ssh to push to your repositories
from Freescale.  Is there any chance you could instead
pull from Freescale's public repository at:

    http://opensource.freescale.com

Thanks,
jdl

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <1173195728.23776.47.camel@ld0161-tx32> you wrote:
>
> I will not be able to use ssh to push to your repositories
> from Freescale.  Is there any chance you could instead
> pull from Freescale's public repository at:

You mean cron-job based? That would be possible, although I'd  prefer
if  we  had a more contolled way to make sure that the content of the
repo is in a sane state.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.

[U-Boot-Users] Changes to U-Boot Development Process

[Jon Loeliger]

On Tue, 2007-03-06 at 09:59, Wolfgang Denk wrote:
> In message <1173195728.23776.47.camel@ld0161-tx32> you wrote:
> >
> > I will not be able to use ssh to push to your repositories
> > from Freescale.  Is there any chance you could instead
> > pull from Freescale's public repository at:
> 
> You mean cron-job based?

Hmmm.  I wasn't thinking cron-based at all, but
rather in the usual "Please Pull" request mode
that we see on other lists.

>  That would be possible, although I'd  prefer
> if  we  had a more contolled way to make sure that the content of the
> repo is in a sane state.

Right.  Arbitrary grabbing isn't a good model.

jdl

[U-Boot-Users] Changes to U-Boot Development Process

[Jerry Van Baren]

Jon Loeliger wrote:
> On Tue, 2007-03-06 at 09:59, Wolfgang Denk wrote:
>> In message <1173195728.23776.47.camel@ld0161-tx32> you wrote:
>>> I will not be able to use ssh to push to your repositories
>>> from Freescale.  Is there any chance you could instead
>>> pull from Freescale's public repository at:
>> You mean cron-job based?
> 
> Hmmm.  I wasn't thinking cron-based at all, but
> rather in the usual "Please Pull" request mode
> that we see on other lists.
> 
>>  That would be possible, although I'd  prefer
>> if  we  had a more contolled way to make sure that the content of the
>> repo is in a sane state.
> 
> Right.  Arbitrary grabbing isn't a good model.
> 
> jdl

Hi Jon, WD,

Does your ssh account to denx.de get you shell access?  If so, you could 
do your own pull when you are at a location that has an enlightened IT 
department (i.e. from home ;-).

gvb

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <45ED92C7.3000301@smiths-aerospace.com> you wrote:
>
> Does your ssh account to denx.de get you shell access?  If so, you could 

No, it does not. It's restricted to command="git-receive-pack u-boot-???"

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The number  of  Unix  installations  has  grown  to  10,  with  more
expected."    - The Unix Programmer's Manual, 2nd Edition, June, 1972

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <1173197134.23776.64.camel@ld0161-tx32> you wrote:
>
> > > I will not be able to use ssh to push to your repositories
> > > from Freescale.  Is there any chance you could instead
> > > pull from Freescale's public repository at:
> > 
> > You mean cron-job based?
> 
> Hmmm.  I wasn't thinking cron-based at all, but
> rather in the usual "Please Pull" request mode
> that we see on other lists.

No. You send me a "please pull" when you want me to pull from / merge
with your custodian repository into the "official" master repository.

But what and when you check into your custodian repo, which  branches
you  use  there  etc. should be completely under your control only. I
don't want to get involved there. 

If you cannot push, all we can  do  is  run  automatic  (cron  based)
updates  which  sync  against  another repo of your choice; note that
probably restricts your options.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is fluid ... like a river with currents, eddies, backwash.
	-- Spock, "The City on the Edge of Forever", stardate 3134.0

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

Hello,

based on earlier input from Peter Pearse  (thanks,  Peter!)  I  added
some  initial  draft  for  a  descritpion  of  the U-Boot development
process. You can find it at
	http://www.denx.de/wiki/UBoot/CustodianGitTrees

Please review and comment. [Note: this is a wiki. Instead of sending
your comments by e-mail, you also edit this document yourself.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The optimum committee has no members.
                                                   - Norman Augustine

[U-Boot-Users] Changes to U-Boot Development Process

[Peter Pearse]

 

> -----Original Message-----
> From: Ulf Samuelsson [mailto:ulf at atmel.com] 
> Sent: 06 March 2007 08:33
> To: Peter Pearse
> Subject: Re: [U-Boot-Users] Changes to U-Boot Development Process
> 
> > Hello,
> > 
> > I would like to get the custodian system finally up and running.
> > All the  custodian's  (public)  repositories  have  been  
> set  up  on 
> > www.denx.de and are ready for use.
> > ...
> 
> Hi Peter, can you inform me (or the list), when you are ready 
> to accept patches for review?
> 

Ulf

	You are welcome to submit your patch as the first 
ARM based board patch under the new system as at:- 
http://www.denx.de/wiki/UBoot/CustodianGitTrees

Unfortunately you will receive no prize for this, 
and possibly suffer from my learning process ;-)

Regards

Peter

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

[U-Boot-Users] Changes to U-Boot Development Process

[Wolfgang Denk]

In message <89A528FE6DB0FA44877BB2F05B84671805650B1A@ZIPPY.Emea.Arm.com> you wrote:
>  
> > Hi Peter, can you inform me (or the list), when you are ready 
> > to accept patches for review?
> 
> 	You are welcome to submit your patch as the first 
> ARM based board patch under the new system as at:- 
> http://www.denx.de/wiki/UBoot/CustodianGitTrees
> 
> Unfortunately you will receive no prize for this, 
> and possibly suffer from my learning process ;-)

We all will have to larn a lot in this process.

I appreciate all sort of feedback and reports  of  experiences,  good
and  bad - I'd like to collec tthis information in the U-Boot wiki so
we can all together find a workign style that fits.


...which opens another question: as many of you know, we have a  long
list  of  unprocessed  patches in my queue. The most efficient way to
move things forward would be if the new custodians started looking at
these old patches, too.

What is the best way to inform you about what is still open?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Don't panic.