Re: [e4-dev] Mandatory Gerrit usage for the e4 project?

[Daniel Rolka <Daniel.Rolka@xxxxxxxxxx>]

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 <dirk.fauth@xxxxxxxxx>
To:	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date:	11/22/2013 11:33 AM
Subject:	Re: [e4-dev] Mandatory Gerrit usage for the e4 project?
Sent by:	e4-dev-bounces@xxxxxxxxxxx

---

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 <wim.jongman@xxxxxxxxx>
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 <jonas.helming@xxxxxxxxxxxxxx>
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 <e4-dev_eclipse.org@xxxxxxxxxxx>
To:        E4
Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date:        22.11.2013
09:35 
Subject:        Re:
[e4-dev] Mandatory Gerrit usage for the e4 project?
Sent by:        e4-dev-bounces@xxxxxxxxxxx

---

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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev




_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev