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.

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
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