In my opinion the perfect solution would be using Gerrit for E4 as the indirect continuous integration server. It would be some kind of wrapper for the raw Hudson - we commit changes to Gerrit -> it triggers the build -> when changes are valid ones will be automatically pushed to master. If not we get some mail with cause of the build break (I suggest breaking the build when at least one unit test fails - it improves the source quality a lot).
Daniel From: Dirk Fauth <[email protected]> To: E4 Project developer mailing list <[email protected]>, Date: 11/22/2013 11:33 AM Subject: Re: [e4-dev] Mandatory Gerrit usage for the e4 project? Sent by: [email protected] I'm not yet very familiar with Gerrit. I was just forced to use it to review a contribution for Nebula. Although I still need to learn more on it, I like it. :) About using it as a committer to review your own changes, well I'm not sure if using Gerrit alone will improve that. If I want to commit and need to go over Gerrit, I will simply say, "yup it's ok, I just implemented it". I don't think you will review your code better the second time looking at it. BUT If there are test cases involved, it definitely would be useful, as AFAIK Gerrit will execute the test cases prior pushing to the repo. Is that correct? Because then if perfectly makes sense to use Gerrit in first place as a help for committest to not push code that breaks anything. Of course that only works if there are useful test cases with a high coverage. For example, yesterday I pushed an enhancement for NatTable. Just a little thing that improves the groupBy feature. Somebody else told me right after that, that it breaks backwards compatibility. I didn't notice it locally. I would have noticed it by looking into the code in Gerrit. And unfortunately for that case there was no test case. So it would have happened anyway. But with the matching test cases Gerrit would have been a great help. So IMHO it is not only about Gerrit but also about test coverage in combination with Gerrit. On Fri, Nov 22, 2013 at 11:19 AM, Wim Jongman <[email protected]> wrote: > you have to wait for somebody to review your changes. A committer does not have to wait for others to review their code. You can review your own code. > +1 to make it a judgment call for the individual committer (people over process) The people over process argument is often used to prevent changes (i'm not saying that you use it in this context btw ;) > It's just crazy to be forced to go via Gerrit if one wants to e.g. quickly fix a typo or a simple warning in the code These kind of changes are often needed because people do not take the time to review their commits. Gerrit will help us with this. Cheers, Wim Meskimen's law "there is never time to do it right but there is always time to do it over" On Fri, Nov 22, 2013 at 9:45 AM, Jonas Helming < [email protected]> wrote: +1 to leave it up to the committer... Am 22.11.2013 09:39, schrieb Daniel Megert: +1 to leave it up to the committer. It's just crazy to be forced to go via Gerrit if one wants to e.g. quickly fix a typo or a simple warning in the code. Dani From: Markus Alexander Kuppe <[email protected]> To: E4 Project developer mailing list <[email protected]> Date: 22.11.2013 09:35 Subject: Re: [e4-dev] Mandatory Gerrit usage for the e4 project? Sent by: [email protected] On 11/22/2013 09:28 AM, Daniel Rolka wrote: > Sometimes Gerrit unnecessary slows down the development - you have to > wait for somebody to review your changes. It is especially painful when > you handle several things simultaneously. So I'm not sure if we should > make it the mandatory step after becoming the committer. Every committer > can take the code and adjust it when they think sth can be > refactored/implement in better way. Hovever I think, introducing some > changes that can break sth/block sb or you are not sure if it is correct > we should commit changes via Gerrit to get feedback, > > +1 for preparing the Hudson build for E4 +1 to make it a judgment call for the individual committer (people over process). M. _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
