Freddie Chopin wrote: > >> Isn't their commit/review/merge policy good enough? > > > > I have no idea about their policies and processes. Again, what does > > that have to do with the version numbers? > > Just read your previous posts... Hint - you said that time-based release > requires no testing or process or RCs, as what is in the repo (after > review) is release-quality.
Version numbers are one discussion, development process is another. Since you're talking about process here; I hope that it is clear for everyone who contributes to OpenOCD that the purpose of review is to ensure that master can be released at any time. I think this has been communicated on many occasions already, and it's generally known that review is good for finding problems. > BTW - OpenOCD uses x.y.z numbers and I see no reason to change that, > as that gives nothing. For time based releases, version numbers have no meaning, at least if the number is based on the release date then it carries some kind of meaning. I certainly consider time based releases which use the respective release date as version number is one way to give meaning to what ismeaningless. Laurent described yet another version number structure. You asked about concrete suggestions for version numbers, I made one suggestion, and Laurent made another. Now you say that changing the version number structure gives nothing (in your opinion). I hope you see how that is confusing. > > 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. > 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
