Re: [U-Boot-Users] uboot custodian question
I bottom post
-----Original Message----- From: Nishanth Menon [mailto:menon.nishanth@gmail.com] Sent: 01 August 2007 03:53 To: Peter Pearse Subject: uboot custodian question
Hi Peter, am wondering if OMAP patches are expected to be pushed to u or not.. thought i'd do a bit of devel as i get time.. Regards, Nishanth Menon
Until such time as we get a volunteer for arm/OMAP custodian I will be checking them.
But patches should be pushed to the list, not direct to me......
Peter
On Wed, 1 Aug 2007, Peter Pearse wrote:
Hey, any chances that TI DaVinci will come into the main tree until it's too late for this release? Patches won't be accepted after August 19th or so according to the new release schedule...
I bottom post
-----Original Message----- From: Nishanth Menon [mailto:menon.nishanth@gmail.com] Sent: 01 August 2007 03:53 To: Peter Pearse Subject: uboot custodian question
Hi Peter, am wondering if OMAP patches are expected to be pushed to u or not.. thought i'd do a bit of devel as i get time.. Regards, Nishanth Menon
Until such time as we get a volunteer for arm/OMAP custodian I will be checking them.
But patches should be pushed to the list, not direct to me......
Peter
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
In message Pine.LNX.4.64ksi.0708010957430.5139@home-gw.koi8.net you wrote:
Hey, any chances that TI DaVinci will come into the main tree until it's too late for this release? Patches won't be accepted after August 19th or so according to the new release schedule...
August 17...
Best regards,
Wolfgang Denk
ksi@koi8.net wrote:
On Wed, 1 Aug 2007, Peter Pearse wrote:
Hey, any chances that TI DaVinci will come into the main tree until it's too late for this release?
Which TI DaVinci patches do you refer to? Any pointers?
Many thanks
Dirk
ksi@koi8.net stated on 8/1/2007 12:00 PM:
Hey, any chances that TI DaVinci will come into the main tree until it's too late for this release? Patches won't be accepted after August 19th or so according to the new release schedule...
I think there'd be some amount of work to do before we can get davinci and other OMAP platforms (2430,3430) in the system.. I am CCying davinci list for their opinions and contributions if any..
Regards, Nishanth Menon
On Wed, 1 Aug 2007, Nishanth Menon wrote:
ksi@koi8.net stated on 8/1/2007 12:00 PM:
Hey, any chances that TI DaVinci will come into the main tree until
it's
too late for this release? Patches won't be accepted after August 19th or
so
according to the new release schedule...
I think there'd be some amount of work to do before we can get davinci and other OMAP platforms (2430,3430) in the system.. I am CCying davinci list for their opinions and contributions if any..
What work? It's been 3 months since I've submitted patches for fully working U-Boot on TMS320DM6446 platform. I do already have some patches to those patches. We do run it for something like 6 months on various boards. What work are you talking about, man?
I'm really really angry, nobody seems to care... What else should I do to get the _PERFECTLY WORKING_ port into the main tree? What's the problem?
I do also have an initial bootloader that allows to program a virgin system and makes it boot off of NAND and NOR Flash. Without Windo$e and without that stupid dotnet or whatever. What else should I do? Fall to my knees and beg? Bribe someone?
It looks like some kind of omerta here... I do _NOT_ need any opinions or contributions from any list, I submitted a fully working port :(
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
Ksi,
ksi@koi8.net stated on 8/1/2007 11:39 PM:
What work? It's been 3 months since I've submitted patches for fully working U-Boot on TMS320DM6446 platform. I do already have some patches to those patches. We do run it for something like 6 months on various boards. What work are you talking about, man?
I'm really really angry, nobody seems to care... What else should I do to get the _PERFECTLY WORKING_ port into the main tree? What's the problem?
My apologies on not following up mails in the uboot list.. I was not aware of your work.. but I do know that OMAP24xx and OMAP34xx patches need a lot of rework.. I could be wrong to imagine that these could share some files with Davinci and viceversa... I can see the patch here in the ARM queue: http://www.denx.de/wiki/UBoot/PatchStatus (posted on 2007-05-08) maybe Peter can comment on his plans of merger.. Regards, Nishanth Menon
Nishanth Menon wrote:
Ksi,
ksi@koi8.net stated on 8/1/2007 11:39 PM:
What work? It's been 3 months since I've submitted patches for fully working U-Boot on TMS320DM6446 platform. I do already have some patches to those patches. We do run it for something like 6 months on various boards. What work are you talking about, man?
I'm really really angry, nobody seems to care... What else should I do to get the _PERFECTLY WORKING_ port into the main tree? What's the problem?
My apologies on not following up mails in the uboot list.. I was not aware of your work.. but I do know that OMAP24xx and OMAP34xx patches need a lot of rework.. I could be wrong to imagine that these could share some files with Davinci and viceversa... I can see the patch here in the ARM queue: http://www.denx.de/wiki/UBoot/PatchStatus (posted on 2007-05-08) maybe Peter can comment on his plans of merger..
Let us start to get an overview regarding TI DaVinci patches floating around. Sorry if anything is wrong or missing, please correct then.
First, I think we should split the discussion for OMAP24xx and OMAP34xx from DaVinci.
So, looking at DaVinci, I can at least identify three patchsets floating around, not sure if and what the relationship is between them.
1. (Original?) patch from Ksi:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
I think these are the patches mentioned in
http://www.denx.de/wiki/UBoot/PatchStatus
2.Patch from Philip Balister:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/29399
http://www.balister.org/~balister/u-boot-sffsdr.patch
3. Patch from Ivan Tonchev:
http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/003645.h... http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/003652.h...
I haven't looked at all of these.
A short discussion with Philip Balister showed some basic requirements for a merge candidate: At least support for TMS320DM6446 based DV-EVM with default/basic NOR and EMIF configuration. Further, it would be nice if the initial work is easily extendable to machines beyond the EVM. May be we need to split the processor stuff off from the board stuff so that it is easy to add additional boards later.
Opinions?
Best regards
Dirk
P.S.: DaVinci list in CC for information.
On Thu, 2 Aug 2007, Dirk Behme wrote:
Nishanth Menon wrote:
Ksi,
ksi@koi8.net stated on 8/1/2007 11:39 PM:
What work? It's been 3 months since I've submitted patches for fully working U-Boot on TMS320DM6446 platform. I do already have some patches to
those
patches. We do run it for something like 6 months on various boards.
What
work are you talking about, man?
I'm really really angry, nobody seems to care... What else should I
do to
get the _PERFECTLY WORKING_ port into the main tree? What's the
problem?
My apologies on not following up mails in the uboot list.. I was not aware of your work.. but I do know that OMAP24xx and OMAP34xx patches need a lot of rework.. I could be wrong to imagine that these could share some files with Davinci and viceversa... I can see the patch
here
in the ARM queue: http://www.denx.de/wiki/UBoot/PatchStatus (posted
on
2007-05-08) maybe Peter can comment on his plans of merger..
Let us start to get an overview regarding TI DaVinci patches floating around. Sorry if anything is wrong or missing, please correct then.
First, I think we should split the discussion for OMAP24xx and OMAP34xx from DaVinci.
So, looking at DaVinci, I can at least identify three patchsets floating around, not sure if and what the relationship is between them.
- (Original?) patch from Ksi:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
I think these are the patches mentioned in
http://www.denx.de/wiki/UBoot/PatchStatus
2.Patch from Philip Balister:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/29399
http://www.balister.org/~balister/u-boot-sffsdr.patch
- Patch from Ivan Tonchev:
http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/0036 45.html http://linux.omap.com/pipermail/davinci-linux-open-source/2007-July/0036 52.html
I haven't looked at all of these.
A short discussion with Philip Balister showed some basic requirements for a merge candidate: At least support for TMS320DM6446 based DV-EVM with default/basic NOR and EMIF configuration. Further, it would be nice if the initial work is easily extendable to machines beyond the EVM. May be we need to split the processor stuff off from the board stuff so that it is easy to add additional boards later.
If you take a look at my patch you can find that it works at least on 3 different boards. It has a separate CPU directory and it is very easy to extend for a new board (as a matter of fact it should work on any board with minor changes if any.) We do run it on 2 additional boards since it's been posted.
Also it is _FULLY_ working port, with all the peripherals properly supported and DV-EVM is just _A_ target, not _THE_ target. Both NOR and NAND flash supported. For NAND both small and large page devices supported with full hardware-assisted ECC fully compatible with Linux MTD implementation.
There is a bug in large page NAND ECC code though that makes U-Boot hang after showing detected NAND Flash info. That came from TI kernel code and it is fixed long ago but I can not send a patch for it because there is nothing I can make that patch against. That's why I keep pushing for inclusion it into the main tree so I would be able to send a fix.
I do also have an initial bootloader (UBL in TI's terms) that allows for programming a virgin system and works as NAND UBL booting _ANY_ user app (including U-Boot) from NAND, both small and large page. It's nothing like that TI's weirdo with dotnet or whatever and Windo$e. And it makes automated programming of freshly manufactured boards very easy.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
ksi@koi8.net wrote:
On Thu, 2 Aug 2007, Dirk Behme wrote:
...
So, looking at DaVinci, I can at least identify three patchsets floating around, not sure if and what the relationship is between them.
- (Original?) patch from Ksi:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
I think these are the patches mentioned in
...
A short discussion with Philip Balister showed some basic requirements for a merge candidate: At least support for TMS320DM6446 based DV-EVM with default/basic NOR and EMIF configuration. Further, it would be nice if the initial work is easily extendable to machines beyond the EVM. May be we need to split the processor stuff off from the board stuff so that it is easy to add additional boards later.
If you take a look at my patch you can find that it works at least on 3 different boards. It has a separate CPU directory and it is very easy to extend for a new board (as a matter of fact it should work on any board with minor changes if any.) We do run it on 2 additional boards since it's been posted.
Also it is _FULLY_ working port, with all the peripherals properly supported and DV-EVM is just _A_ target, not _THE_ target. Both NOR and NAND flash supported. For NAND both small and large page devices supported with full hardware-assisted ECC fully compatible with Linux MTD implementation.
Sounds good! Many thanks for summarizing this again for everybody who missed your older infos!
Looking at your patches, some quick thoughts. Most of them are really minor ones:
- While they still apply against recent git, would be good to update them to cleanly apply. There is a newer mach-types.h as well.
- There are some #if 0 and #if 1 throughout the code. I think Peter would like to see this fixed.
- Do we really need an additional types.h include/asm-arm/arch-tms320dm6446/types.h?
- Why not calling the directories
cpu/arm926ejs/tms320dm6446/ include/asm-arm/arch-tms320dm6446/
"davinci" instead? davinci sounds more generic.
- Not sure about this, but instead of introducing additional
nand.c nand_defs.h
is there a chance to use more from the existing NAND code?
- Any chance to reuse anything from drivers/ns8382x.c for DP83848?
Do you like to split the patches in smaller chunks (main stuff, drivers) and then sending them unzipped (except mach-types.h) as plain text to the list? Maybe this could help people to directly comment.
Best regards
Dirk
In message 46B2C9DA.4070608@googlemail.com you wrote:
Do you like to split the patches in smaller chunks (main stuff, drivers) and then sending them unzipped (except mach-types.h) as plain text to the list? Maybe this could help people to directly comment.
This is definitely a good idea; compressed patched tend to get ignored as they violate the requirements for a proper patch - see http://www.denx.de/wiki/UBoot/Patches
Dirk - thanks a lot for all the other very helpful comments. I appreciate that we get this thing rolling finally!
Best regards,
Wolfgang Denk
On Fri, 3 Aug 2007, Wolfgang Denk wrote:
In message 46B2C9DA.4070608@googlemail.com you wrote:
Do you like to split the patches in smaller chunks (main stuff, drivers) and then sending them unzipped (except mach-types.h) as plain text to the list? Maybe this could help people to directly comment.
This is definitely a good idea; compressed patched tend to get ignored as they violate the requirements for a proper patch - see http://www.denx.de/wiki/UBoot/Patches
These requirements are broken. It is a good idea for patches that fix something but it is absolutely bad for adding new port. Initial set of patches for it is big and it is much better to use a compressed patch (or even set of such) than posting 30 or 50 small patches in separate emails.
When it is already in the tree, yes, it is possible to use small patches and it is good to do so.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
In message Pine.LNX.4.64ksi.0708031047300.23796@home-gw.koi8.net you wrote:
These requirements are broken. It is a good idea for patches that fix something but it is absolutely bad for adding new port. Initial set of patches for it is big and it is much better to use a compressed patch (or even set of such) than posting 30 or 50 small patches in separate emails.
This is your opinion; others voted differently.
Note that nobody asked for lots of tiny patches. Please re-read the text, especially the part "[if] ... you are absolutely sure that you should not split it" ...
When it is already in the tree, yes, it is possible to use small patches and it is good to do so.
compressed -> unreadable -> ignored.
Please do not complain then.
Best regards,
Wolfgang Denk
On Fri, 3 Aug 2007, Dirk Behme wrote:
ksi@koi8.net wrote:
On Thu, 2 Aug 2007, Dirk Behme wrote:
...
So, looking at DaVinci, I can at least identify three patchsets
floating
around, not sure if and what the relationship is between them.
- (Original?) patch from Ksi:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27603 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27604 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27605 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28314
I think these are the patches mentioned in
...
A short discussion with Philip Balister showed some basic
requirements
for a merge candidate: At least support for TMS320DM6446 based DV-EVM
with
default/basic NOR and EMIF configuration. Further, it would be nice
if
the initial work is easily extendable to machines beyond the EVM. May
be
we need to split the processor stuff off from the board stuff so that it
is
easy to add additional boards later.
If you take a look at my patch you can find that it works at least on
3
different boards. It has a separate CPU directory and it is very easy
to
extend for a new board (as a matter of fact it should work on any
board
with minor changes if any.) We do run it on 2 additional boards since it's
been
posted.
Also it is _FULLY_ working port, with all the peripherals properly supported and DV-EVM is just _A_ target, not _THE_ target. Both NOR and NAND
flash
supported. For NAND both small and large page devices supported with
full
hardware-assisted ECC fully compatible with Linux MTD implementation.
Sounds good! Many thanks for summarizing this again for everybody who missed your older infos!
Looking at your patches, some quick thoughts. Most of them are really minor ones:
- While they still apply against recent git, would be good to update
them to cleanly apply. There is a newer mach-types.h as well.
Sure. But it is not possible because if I had a new patchset posted it will get outdated again because I doubt it would be processed in less than 6 months or so. So let's get _something_ in first than I'll be able to clean it up.
- There are some #if 0 and #if 1 throughout the code. I think Peter
would like to see this fixed.
I will. But let's get something in first. Otherwise it won't get in ever.
- Do we really need an additional types.h
include/asm-arm/arch-tms320dm6446/types.h?
That only has 2 typedefs for register and pointer to register. Yes, I can get rid of those but that would be just cosmetic. Again, let's get something in then I'll fix cosmetics.
- Why not calling the directories
cpu/arm926ejs/tms320dm6446/ include/asm-arm/arch-tms320dm6446/
"davinci" instead? davinci sounds more generic.
It it TOO generic. DaVinci family also includes ARM-less DSP chips. The more generic name would be tms320dm644x but that can be changed later.
- Not sure about this, but instead of introducing additional
nand.c nand_defs.h
is there a chance to use more from the existing NAND code?
No. This is board (or, in this case, CPU) specific code. This is _NOT_ NAND code, this is CPU/board NAND hardware interface code. I did use the new NAND code for NAND, absolutely generic. The same is true for NOR code -- there is no custom code, generic CFI Flash driver is used.
- Any chance to reuse anything from drivers/ns8382x.c for DP83848?
Nope. That drivers/ns8382x.c is _MAC_ driver, not PHY. And that has nothing in common with DaVinci EMAC.
DP83848 is added PHY driver. All other boards I'm aware of including DV-EVM use Intel LXT971/972 PHY. We use DP83848 here because it is better than LXT971 and much cheaper. And it is readily available.
Do you like to split the patches in smaller chunks (main stuff, drivers) and then sending them unzipped (except mach-types.h) as plain text to the list? Maybe this could help people to directly comment.
Do you want me to send 30 or so emails for a new port? That would do absolutely no sense and something will get lost in the process. Been there done that. Let's get a base in first then it will make sense to do small isolated patches.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
In message Pine.LNX.4.64ksi.0708031052420.23796@home-gw.koi8.net you wrote:
Sure. But it is not possible because if I had a new patchset posted it will get outdated again because I doubt it would be processed in less than 6 months or so. So let's get _something_ in first than I'll be able to clean it up.
U-Boot development process has changed significantly in hte last few months. But to work quick and easy it requires that you adapt to the methods and tools used in this process.
- There are some #if 0 and #if 1 throughout the code. I think Peter
would like to see this fixed.
I will. But let's get something in first. Otherwise it won't get in ever.
...
That only has 2 typedefs for register and pointer to register. Yes, I can get rid of those but that would be just cosmetic. Again, let's get something in then I'll fix cosmetics.
It seems you misunderstand how this patch review process works. You are supposed to fix your patches according to the feedback you receive, and then resubmit the cleaned up patches, until they can be merged cleanly. We don't want to add code that is known to need fixing, even if somebody promises to clean up later.
Please clean up now and resubmit.
Best regards,
Wolfgang Denk
On Fri, 3 Aug 2007, Wolfgang Denk wrote:
In message Pine.LNX.4.64ksi.0708031052420.23796@home-gw.koi8.net you wrote:
Sure. But it is not possible because if I had a new patchset posted it
will
get outdated again because I doubt it would be processed in less than
6
months or so. So let's get _something_ in first than I'll be able to
clean
it up.
U-Boot development process has changed significantly in hte last few months. But to work quick and easy it requires that you adapt to the methods and tools used in this process.
- There are some #if 0 and #if 1 throughout the code. I think Peter
would like to see this fixed.
I will. But let's get something in first. Otherwise it won't get in
ever. ...
That only has 2 typedefs for register and pointer to register. Yes, I
can
get rid of those but that would be just cosmetic. Again, let's get
something
in then I'll fix cosmetics.
It seems you misunderstand how this patch review process works. You are supposed to fix your patches according to the feedback you receive, and then resubmit the cleaned up patches, until they can be merged cleanly. We don't want to add code that is known to need fixing, even if somebody promises to clean up later.
Please clean up now and resubmit.
Clean up WHAT? Man, I'm on the verge now...
The problem is there were _ABSOLUTELY NO_ feedback, just silence. I _WOULD_ clean up or fix anything but there was _ABSOLUTELY NO_ , repeat _ABSOLUTELY NO_ feedback on that submission !!! I've just got "your patches are added to the queue" from Peter and that's all.
What feedback?! Who is reviewing those patches? It looks like you guys are desperately trying to find an excuse to NOT accept anything no matter how laughable that excuse is, pardon my French.
Have I refused to clean up or fix the code? Should one develop a sixth sense and anticipate what would you think 6 months from now? How can one submit patches against _CURRENT_ version reflecting ever changing party line if those patches are sitting dormant for 3+ months? They _WERE_ current as of the time of posting. What sense does it make to redo them from today's version if they would sit in the queue for another half year and then again declared not current enough?
I'm fed up with that nonsense. And I have much better use for my time, my prototype boards just came in so I have to grab my soldering iron and scope and make them work. I have neither time nor will to fight with windmills any more. You won, I accept my defeat.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
Clean up WHAT? Man, I'm on the verge now...
The problem is there were _ABSOLUTELY NO_ feedback, just silence. I _WOULD_ clean up or fix anything but there was _ABSOLUTELY NO_ , repeat _ABSOLUTELY NO_ feedback on that submission !!! I've just got "your patches are added to the queue" from Peter and that's all.
What feedback?! Who is reviewing those patches? It looks like you guys are desperately trying to find an excuse to NOT accept anything no matter how laughable that excuse is, pardon my French.
Well, watching and occasionally pushing fixes over the last several years, I've not observed the kind of thing you are venting about.
Generally, patch handling of large patches has been slow. Fixes and incremental changes have happened at a reasonable rate. Rate varies from project to project depending on demand. In an attempt to speed this up as Wolfgang doesn't scale the model changed recently. The project has been quite beneficial for users so it's generally worth the effort.
I have many OMAP fixes and a few more boards which would be good to get in the tree. Part of why they are there was the delays and parts are our own fault. I try to see this pragmatically not bitterly.
Regards, Richard W.
In message Pine.LNX.4.64ksi.0708031344040.24286@home-gw.koi8.net you wrote:
Clean up WHAT? Man, I'm on the verge now...
Please calm down and let's discuss this on a technical level.
The problem is there were _ABSOLUTELY NO_ feedback, just silence. I _WOULD_ clean up or fix anything but there was _ABSOLUTELY NO_ , repeat _ABSOLUTELY NO_ feedback on that submission !!! I've just got "your patches are added to the queue" from Peter and that's all.
You are right, ther ehas not been any feedback for a long, long time, and nothing happened since your submission. That is regrettable, but that was in the past. Now is now.
What feedback?! Who is reviewing those patches? It looks like you guys are
You received a few very useful comments from Dirk Behme on Fri, 03 Aug 2007. He wrote:
| - While they still apply against recent git, would be good to update | them to cleanly apply. There is a newer mach-types.h as well. | | - There are some #if 0 and #if 1 throughout the code. I think Peter | would like to see this fixed. | | - Do we really need an additional types.h | include/asm-arm/arch-tms320dm6446/types.h? ...
[I'll omit the remaining suggestions here because you already replied why you would not want to follow his suggestions. Even though this might still be debated, it is not significant here.]
But the three suggestions above *are* feedback to your patches. Let me summarize and repeat:
* Please clean up #if 0 and #if 1 in your patch. * While doing this, please rebase it against the current version of U-Boot so your patch applies cleanly. * Please avoid the new types.h file if it is not really necessary.
Have I refused to clean up or fix the code? Should one develop a sixth sense and anticipate what would you think 6 months from now? How can one submit patches against _CURRENT_ version reflecting ever changing party line if those patches are sitting dormant for 3+ months? They _WERE_ current as of the time of posting. What sense does it make to redo them from today's version if they would sit in the queue for another half year and then again declared not current enough?
It would make little sense if there was reason to believe they would indeed stew in the pot for so long.
I can understand that you ar4e frustrated, but please help us and give us a chance that the new development process is actually an improvement. If it is possible to use a simple "git am" command to add your patches to the current tree chances are *very* good that they will get added. On the other side, if they are known to need cleanup and cause a lot of conflicts with current code your chances are really small.
I'm fed up with that nonsense. And I have much better use for my time, my prototype boards just came in so I have to grab my soldering iron and scope and make them work. I have neither time nor will to fight with windmills any more. You won, I accept my defeat.
It seems an awful waste of resources to me to throw in the towel after you made 95% of the way. I suggest you leave this issue for now, and re-read the last few messages of this thread after the weekend. Then, please reconsider.
Best regards,
Wolfgang Denk
participants (6)
-
Dirk Behme -
ksi＠koi8.net -
Nishanth Menon -
Peter Pearse -
Wolfgang Denk -
Woodruff, Richard