CC the list. On Wed, Mar 6, 2013 at 9:36 PM, Laurent Gauch <laurent.ga...@amontec.com> wrote: > Le 06.03.2013 14:08, Xiaofan Chen a écrit : > >> On Wed, Mar 6, 2013 at 7:08 PM, Spencer Oliver<s...@spen-soft.co.uk> >> wrote: >>> >>> On 6 March 2013 10:27, Franck Jullien<franck.jull...@gmail.com> wrote: >>>> >>>> 2013/3/6 Laurent Gauch<laurent.ga...@amontec.com>: >>>> >>>>> I like the Peter's idea, but it is not realist ! >>>>> As LibUsb story, OpenOCD need to respect the patch publisher and merge >>>>> the patches faster. If not, you do not respect the patch publisher and >>>>> you will lost quickly this publisher ... >>>>> >>>> +1 >>>> >>>> I don't want to polemicate, but Laurent is right. I was ready to be >>>> involved >>>> in openocd but reviewing is to long so I moved to something else.... >>>> >>> And this sums up the issue, we do not have enough devs reviewing patches. >>> It takes time and with only a couple of people reviewing it is getting >>> harder. >>> >>> OpenOCD is not like other software projects, we have a hardware >>> element to make sure we minimise regressions. >>> So review generally takes longer. >> >> Maybe Laurent's idea is good, to categorize patches into different >> types and have fast track for some simpler or isolated patches. >> >> Quote what Laurent suggested: >> "The project is big enough to have different review process >> regarding which part of the structure your patch is associated. >> Example : SWD patch -> openocd core strucutre -> >> high critical review process >> Example : specific flash programming patch -> low critical review >> process" >> >> For example, Salvador Arroyo submitted many MIPS M4K and >> PIC32MX patches. I think many of them are not affecting other >> parts of Openocd. But due to the low users of Openocd for those >> parts, I think they are not really reviewed. On the other hand, >> many of them are probably safe to be merged. >> >> > > Yes, right ! When something new is coming as new target support, new flash > algo ... the patch should be merged on the fly. Because the publisher is > certainly the only user of this new feature. > Since the new feature is merged quickly some other users will use it and > maybe will found issues ... > Also, this will make the publisher HAPPY, and he will continue to come with > new patches ... > > For Peter, how do you test a new feature/patch when you did not have the > hardware to ! So the maintener should understand the impact of the patch and > then if it do not touch the main core of the project it should merge it. The > test of it will come by other user, and not by maintener. > > Regards, > Laurent > http://www.amontec.com
------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
