>>> I think that the process discussion is interesting and very >>> important, everyone in a project must agree on process, otherwise >>> it's not really possible to cooperate. Let's continue that >>> discussion! >> Let's not waste time on such endless discussions that lead nowhere. >> No everyone must agree - majority has to, but not everyone. > Everyone who wants to cooperate needs to agree, or cooperation isn't > really possible. I hope that makes sense? You seem to disagree with > the intent of the review process and I think that warrants discussion > since review is supposed to be a big part of contributions. Yes you're right, but this is not realist ! The actual REVIEW PROCESS is too strict for the major part of users. It is not the good way to respect the effort done by patch publishers.
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 ... The main problem regarding actual patches are that all patches need the same review process. And this review process is too strict for 95% of the patches. 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 Actually a large number of patches, as new devices flash algo, could be merged directly, almost without testing the code. The advantage will be to respect all users publishing low critical patch -> and again this is the major part of the patches today. But having a lot of pending patch (95% are good low critical patches ready to be merged) waiting for review process , is just a lot of 'publishers' and 'publisher works' lost and a project close to be dead. We all want to see openocd growing, but the first step is to respect the patch publishers merging their low critical patches quickly, and creating time base releases. Regards, Laurent http://www.amontec.com > >> We can argue about how it's done for Ubuntu, Eclipse, GCC, Linux, >> whatever-project-fits-your-line > I don't know why you bring up other projects. What matters is how > this project works. > > >> You have better idea - just give it - > Hm, it's not my idea? The idea that we want review to lead to an > always releaseable master branch has been communicated very clearly, > several times, by several people, from around when we started using > gerrit. > > >> Criticizing everything without providing an alternative is "nonsense". > I'm afraid I don't understand this sentence. Maybe you can explain? > > If you refer to my criticism of the suggested release process then I > hope that I was already pretty clear about what I consider the > alternative to be in the first two emails. I can repeat myself, but > I'm not sure if that makes any sense.. > > > //Peter > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
