> Problem here is that the api-discussion (PJU,DME,developer) changed into > a discussion if the change itself is correct. > > As this discussion is done via mail no uptodate info was present in the > issue. Could we do these discussions in this mailing list or in the issue itself? It would tremendously increase the visibility.
> About the 24h i don't think this is achievable always, Just list of > steps involved: > > - it fails > - someone need to notice, if not obvious i need to analyze > - report the issue > - reassign to developer > - developer needs to notice this > - explain, reassign to PJU > - PJU needs to notice and decide > - <optionally> sounds rounds forth-back here > - some solution needs to be done (accept,reject, etc) In some cases 24h will not be achievable, but for example I see possible actions we can take with these kind of broken APIs. That is, does the API show a warning every time a view is modified? If yes, we can document this and let developers know about this, so that they can do all the hard job in advanced. This won't be true for all the cases of course. In general I would say: * Can developer's guess that their commit will break the API? In what percent of the cases can we be trained for this? * In case of doubt, developers can always use "try" first. * There will always be a minimal downtime of "int". If we estimate that the discussion is going to take a lot of time (4 days = alot), I would prefer to back out these changesets and to come back when the definitive solution when it's ready. Juan Pablo ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Openbravo-builds mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbravo-builds
