Freddie Chopin wrote: > > The role doesn't make any sense to me since everything that has > > been reviewed by the community is release-ready, and everything > > that has not is not. Super easy. > > It's not true. Patches that were reviewed and merged to 0.6.0 caused a > serious regression - how's that "release-ready"?
Unless active and consistent effort is made to avoid any regressions releases can and will have regressions. If regressions in master are unacceptable then the review process must become much more strict, AKA slower, AKA people will whine about no progress and that the project is dead. Take your pick. > If you think the process is wrong, start another thread and give > ideas, maybe step up to do the release. I already gave the only two ideas that I think a project can choose between; feature based and time based. I personally prefer feature based, it makes more sense to me (bug fixes count as features too) but in projects with small number of active developers the features tend to develop rather slowly, and the community is of course always quite eager to whine about lack of progress and how developers aren't delivering what is needed quickly enough - so time based is a good way to make people feel warm and fuzzy, because even though nobody has had time to do any actual work at least a number is increasing. > 1. release has to be tested more than a random snapshot Why should there be inconsistent levels of testing for different commits? That makes no sense at all to me. > 2. release is an opportunity to "flush" the review queue in gerrit - > by motivating the reviewers and authors This assumes that the project as a whole has some kind of power to push contributors into crunch mode whenever the project sees fit, and I can't even explain how utterly absurd I find that idea. Contributors contribute as they can. > 3. stable release is good for normal users, that don't want to deal > with random snapshots or with a "release" that's just a masked > random snapshot You are arguing that in fact you consider the review process to *not* result in releaseable master. I suggest to continue discussing that in this thread - I think it's very important! > with no guarantee The OpenOCD license is quite explicit: the software has NO guarantee. Anyone can offer guarantees as a service, but if someone expects any open source project to give any kind of guarantees they are either illiterate or plain stupid. Of course all projects try best effort to fix problems, and have an interest in fixing problems, but that's something entirely different. > Random-snapshot-release is sth that is nonsense for me - it's > better to do nothing than tag sth completely random as a stable > release. Time based release is just that, time based. Whatever is in master at the time is released. Control of what gets released in time based releases is thus control of what gets into master. That is, the review process. Does it make sense that strict review leads to consistently high quality time based releases? //Peter ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
