In message <[EMAIL PROTECTED]> you wrote:
>
> of course i have. writing out rules is to codify the spirit of the process
> so
> that people can jump in and know how things works. however, the point of the
> rules isnt to have a rigid unchanging methodology, but to keep things flowing
> in the spirit: merge windows allow new fun stuff while the non-merge time is
> for bugfixes only. this of course assumes that the tree in question is
> stable/usable in the first place. if it isnt, then there isnt much point to
> locking out changes to move it in that direction.
The tree in general is actually pretty stable/usable as of now; I
know only of a few (minor) problems.
If the BF stuff is in bad shape, then I'm sorry about this, but 1)
you could have posted your stuff in the merge window like everybody
else, or 2) you have to wait until the next merge window like
everybody else. I will not destabilize the whole tree for a single
architecture.
If you have bug fixes, please go on and post these and I will make
sure they go in as fast as possible.
But I will not add major new code now.
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: [EMAIL PROTECTED]
Q: How do you play religious roulette?
A: You stand around in a circle and blaspheme and see who gets
struck by lightning first.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/u-boot-users
