OK. What's explained in this e-mail is the process we'll follow from now on.
Firstly, there are 2 clear goals with all this: 1) Make pi healthier and other developer's life easier. 2) Learn from our mistakes, learn to be correct and improve the tools if they can help us make less mistakes. With this considered, there are 3 kind of build failures that are considered basic or *unacceptable*: 1) Full builds (install.source) and incremental builds (smartbuild, update.database) fail in Oracle or in PostgreSQL. 2) Junit tests fail. 3) The database is not consistent. If a developer breaks a build twice in the last 30 days, push access will be removed for 2 weeks. And he'll ask a friend to push for him. This friend will be responsible of the sanity of the entire push. There is one salvation clause for the developer, 24h to react and make the build stable again. Note that making the build stable again doesn't necessarily mean fixing the bad changeset. Feel free to backout your faulty changeset. Whatever to make the build stable in less than 24h. If the issue is solved in less than 24h no actions are taken. Finally, the developer who fixes a broken build should reply to the e-mail sent by Hudson to this mailing list, explaining why the build failed and how it was fixed. This way we'll be able to see the reason behind it and figure out a way to make it easier for everyone, if it applies (like with synchronize terminology). Any comments are welcome. Juan Pablo On 18:11 Tue 15 Sep , Ismael Ciordia, Openbravo wrote: > Juanpa, > > I propose to be pragmatic. It is up to RM team (who suffers the problem) to > decide if a build failure is due to a lazy practice or not. There are clear > cases of lazy practice: code does not compile, syschronize > terminology/translation is not executed, pl/sql code is not oracle/postgres > compatible, etc.). In your example below RM -that needs to know what is the > root cause of the problem- will not count it as a wrong commit. > > The result I expect from my proposal to penalize developers is: > -reduce the downtime due to wrong commits: developers will solve these > issues asap (or they will be penalized) > -reduce the number of wrong commits: developers will be specially careful > after they commit a wrong changset (or they will be penalized) so discipline > will be gradually and smoothly put in practice by our team > > But if you find this policy difficult to apply let's forget it, it is not > worth the discussion here > > Ismael > > > -----Mensaje original----- > De: Juan Pablo Aroztegi [mailto:[email protected]] > Enviado el: martes, 15 de septiembre de 2009 15:53 > Para: [email protected] > Asunto: Re: > [Openbravo-development][DB-Consistency-Check]-ERP-pi-pgsql-full > [Still > Failing!] > > > Hi Isma, > > > -the incentive for developers to make it right is write access to pi: RM > > will remove write access privileges in pi repository for two weeks to a > > developer who: > > -commits a change that breaks nightly build and does not fix it within > the > > next 48 hours > > -commits two changes that break nightly build within two consecutive > > weeks, no matter how fast it is fixed later > I agree with the 48h limit to fix the situation. But instead I would > reduce it to 24h. If you push a commit that breaks something, you can > always backout the commit, study it with calm, fix it and push it again. > > However I'm not convinced with the other measure of counting 2 build fails > to penalize someone. I mean, do we consider *any* failed build? > Example: > > * I commit something that passes all the possible tests in my computer. > * I push it and it fails on a build machine because it's 64bit, and my > machine was 32bit. > > Counting which failure are "punishable" and which is counter-productive > and too time consuming. > > What do you think? > > > Juan Pablo > > > ---------------------------------------------------------------------------- > -- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Openbravo-development mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openbravo-development > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Openbravo-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbravo-development
