Hi simon,

I think what you are talking about is gerrit code review. I know Libreoffice use it and for them I think you need to have 3 reviewers before the code is committed as well the code gets compiled and built as well to ensure it works.

https://gerrit-review.googlesource.com/Documentation/intro-how-gerrit-works.html

I am not sure if jenkins has a flow like what you are describing, but at least you have more control over the quality of whats committed.

On 2018-03-06 00:25, Simon Lees wrote:
On 06/03/18 03:56, Stefan Schmidt wrote:
Hello.

I snipped away a lot of text here to make it easier to follow. If you feel I quoted out of context let me know.

On 03/05/2018 12:57 PM, Carsten Haitzler (The Rasterman) wrote:
1. Code reverting.

I take API breaks seriously. An API break shouldn't happen. It should get caught as soon as possible if it does before anything is built on top and that may mean reverting work that created a break ASAP if that is the most efficient path. More generically here is the order of bad things for git master:

#1. Builds break.
#2. Building against X breaks (e.g. building terminology or e against efl). #3. The app or lib just crashes or doesn't work in regular usage leaving people
with an unusable environment
#4. API/ABI breaks (code, data files, theme etc. - we only do these with a lot
of careful thought, discussion and weighing up of the pros and cons).
#5. A new design or idea/direction that then will be built on top of and if
#this design/idea has big issues.

git master should be "usable day to day" for developers and "advanced users". It will get bugs and issues but they should be resolved ASAP and avoided as
much as possible.

But at least in my reality this is just not happening. A lot of things stay broken until I poke people to fix them, bisect them or push to
get a release out.

Right now there is at least the osx build broken for a while and edje_cc does run when build on a aarch64 system. These are simply not the development systems we use. One could say that everything not x86_64 and Linux will stay undetected. Once detected such things are often to hard to revert by the pure amount of commits that hit master in between.

People who do the work get to call the shots. It is of course affected by history of contribution, knowledge of the project and what it interacts with etc. etc. ... I do not think having some committee of project managers is going to make anything better. I think if anything it just makes things worse by adding overhead. If we made everything code-reviewed ala phab, I think it'd be far worse. development would dwindle and die. I absolutely know that I'd personally just stop if I had to put every commit I do through review. Review is a tool for developers who are not trusted yet or who need to learn or who are not involved deeply enough to be held responsible for their work. Then I
believe the cost is justified.

If you see that the majority of breaks actual comes from developers with commit access this is partly amusing and partly sad.

I my opinion we should actually be happy if we could slow down the amount of commits. Way to often I see rushed in commits which get followed up by n more commits to fix things that could have been spotted during QA and review before letting it in master.

I realize this is something fundamentally disagree on. You want all commits in master as soon as possible so other can actually use it. I only want a stable and tested subset of changes being put in master after the code maybe has gone through some iterations.

The world is not going to stop spinning just because a commit gets into master a day later.

The way we use CI is a toothless tiger. Whatever it detects (and it does not detect as much as it should, actually) nobody cares if I not personally come after the person. Given the little impact it can have this way my interest does dwindle and die to push it forward. I am fighting this area alone and no interest has been shown from others (which is fair enough), which basically means it will drop dead if I stop looking after it. Maybe someone would pick it up again, but future telling is not my string side.


Which does summarize my stand point as:
1) ALL commits should go through review and automated QA
2) New things can easily be tested by using branches, no need to have it in master for this. 3) Slow down of commits  by taking your time and addressing found issues in new iterations instead of fix up later on in master.
4) QA, test cases, etc should be the objective of all devs.

So yeah, very far a way from what you think as the best workflow. Well, we agree that QA, test cases and review is needed but not at what
point in the workflow. :-)

regards
Stefan Schmidt


Morning all,

Maybe a half way point here is if every commit (or maybe group of
commits) had to go through a simple review where jenkins or some other
bot checks that the commits still compile etc. Once the automated review
has finished anyone with commit access (including the author) could
accept the review and commit the code. This way people will be notified
about really dumb mistakes but if Jenkins is broken for other reasons
people will still be able to commit etc. Down the track maybe there are
more automated tests that can be added. This way people are only being
held up for a little while.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to