On 6 March 2018 at 10:07, William L. Thomson Jr. <wlt...@obsidian-studios.com> wrote: > On Tue, 6 Mar 2018 10:55:36 +1030 > Simon Lees <sfl...@suse.de> 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 > > Why not just have the bot sign off and commit itself? If it passes > automated review. The human aspect could slow others work flow down. > > I would think every commit was verified against CI to build now. If > that is not the case. That should be a minimum criteria. Do not break > CI builds, and if you do, fix it immediately, or revert commit.
Hello, As an efl application developer (and not an efl library developer) here's what I think. Review/Commit process: Anything that will go into master should a least go through all supported platforms builds (operating system and architectures) *before* it gets merged. So you get angry at jenkins instead of your friend that just reverted your commit. Like others said that should be the minimum if the infrastructure is available. Then, it would be great if there was a tool to detect an api/theme break... and additions of api? I think a theme break tool is possible and should be done, not sure about the api. It would also be nice if at least one human reviewed what you want to merge. You shouldn't trust anyone even yourself. Humans always make mistakes. Like stefan said, if people wants to test it they can use the branch and it is not the end of world if it is not in master directly. Is there a reason for having your code in master instantly? You might think reviews slow down the process, but I have seen many people lose their time fixing someone else stuff. It 's difficult to say which way is the most efficient. Also I have seen people look at some code and say "wtf is this???" and then rewrite the whole thing. If everybody looked at each other stuff maybe this would not happen in the long term. If people disagree on this, you could find a balance between everything gets reviewed and everyone commits directly. Like usually a review is required unless you are sure this would not cause any problem. For example, review are needed for feature but no review needed for fix? Communication: Discussion can happen on irc/mailing list, but decisions should not. There should be only one place where decisions are made. And it should be phab. The mailing list is good for questions/discussions but it is very easy to forget a mail. A ticket has a status and it stays there until you resolve it. Decisions should have a clear status and should not be dangling like a mail thread could be. And you would also have proof there was a discussion and how a decision was made. Someone joining the project would have a hard time searching though the mailing list/irc logs to find information about a specific issue. So I think all important decisions should be in one easy searchable/referable place. (it doesn't have to be phab but it is what we have now) ------------------------------------------------------------------------------ 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
