git-flow extension for developers

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
stijn
Posts: 588
Joined: Thu Apr 24, 2014 9:13 am

Re: git-flow extension for developers

Post by stijn » Fri Nov 27, 2020 9:36 am

I think you should take a step back and read some tutorial(s) about how PR workflows work. It would answer most of your questions.
I think it is better to have a branch for the new feature, for example
github.com/micropython/micropython/tree/feature/esp32_pwm_handle_multiple_timers
No it's not: that repository doesn't belong to you so why would you be allowed to create branches in repositories of arbitrary people?

ihornehrutsa
Posts: 22
Joined: Sat Oct 26, 2019 8:38 pm

Re: git-flow extension for developers

Post by ihornehrutsa » Fri Nov 27, 2020 10:05 am

stijn wrote:
Fri Nov 27, 2020 9:36 am
I think you should take a step back and read some tutorial(s) about how PR workflows work. It would answer most of your questions.
Let's be more concretely.
I can't find that case in tutorials about PR.
We have the frozen(no longer supported by the author) PR.
It has a bug.
We have the new inherited PR with fixes.
What is the canonically correct way of approving PR's in this case?

stijn
Posts: 588
Joined: Thu Apr 24, 2014 9:13 am

Re: git-flow extension for developers

Post by stijn » Fri Nov 27, 2020 11:01 am

Just like another PR; practically something like:
- create branch in your fork containing the commit(s) of the original PRs (with fetchpr then rebase on latest master or just new branch + cherry-picking original commits). At first you leave the original commit intact to not loose the author information (I'm not a lawyer so no idea if it's allowed to just take the code alone, but even if it were it's more decent to give credit to the original writer)
- add a commit which fixes the bug
- create new PR, in which you refer to the original one explaining the case

Then upon reviewing it can be decided to squash your commit(s) with the original one(s), or to leave them separate.

ihornehrutsa
Posts: 22
Joined: Sat Oct 26, 2019 8:38 pm

Re: git-flow extension for developers

Post by ihornehrutsa » Sat Dec 05, 2020 7:13 pm

It seems that Micropython uses Low-Frequency Integration
https://martinfowler.com/articles/branc ... -frequency

But too low and slow. :(

User avatar
pythoncoder
Posts: 5071
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: git-flow extension for developers

Post by pythoncoder » Mon Dec 07, 2020 8:59 am

ihornehrutsa wrote:
Sat Dec 05, 2020 7:13 pm
It seems that Micropython uses Low-Frequency Integration
https://martinfowler.com/articles/branc ... -frequency

But too low and slow. :(
Are you aware of any problematic merge conflicts on the project?
Peter Hinch

ihornehrutsa
Posts: 22
Joined: Sat Oct 26, 2019 8:38 pm

Re: git-flow extension for developers

Post by ihornehrutsa » Mon Dec 07, 2020 9:44 am

Peter, I don't quite understand your question.
Do you mean that there are BIG merge problems in MicroPython?
I don't know about problems, but High-Frequency Integration gives advantages over the Low-Frequency Integration.
See the article.

stijn
Posts: 588
Joined: Thu Apr 24, 2014 9:13 am

Re: git-flow extension for developers

Post by stijn » Mon Dec 07, 2020 10:54 am

I think what pythoncoder means is that merge conflicts (be it literal or semantic) are a sign of low-frequency integration. So since you think MicroPython uses low-frequency, the question is: are there merge conflicts indicating that?

Now merge conflicts alone aren't what defines low-frequency. Still, I'm not sure the conclusion to draw from the article is that MicroPython would be considered low-frequency integration. The frequency isn't expressed in 'number of commits merged per week' or so, i.e. what you call 'too slow' is 'clock time' and that is irrelevant here.

By example: a project can have 1 commit per month and still be high frequency: if there are only 12 commits per year, then what makes a project low-frequency is if those 12 commits are all merged into the mainline once on december 31. However if the commits are merged when they are ready, then it's high-frequency. At least that is how I understand it, please correct me if I'm wrong.

Looking at the MicroPython commit history, it doesn't exactly look like commits are held back until a bunch of features are ready and then merged. Instead it consists of many small commit with incremental changes.

ihornehrutsa
Posts: 22
Joined: Sat Oct 26, 2019 8:38 pm

Re: git-flow extension for developers

Post by ihornehrutsa » Mon Dec 07, 2020 12:26 pm

This pull request https://github.com/micropython/micropython/pull/6276 does not seem as High-Frequency Integration.
But anyway I vote to approve it.

User avatar
pythoncoder
Posts: 5071
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: git-flow extension for developers

Post by pythoncoder » Mon Dec 07, 2020 5:46 pm

I was responding to
But too low and slow.
From reading the article, the consequence of "too low" is that difficult merge conflicts arise taking excessive time to resolve.

I follow the activity on GitHub and I think I'd be aware when this occurred. I can't recall an actual incidence. I think this is because of the way the project is structured, run and managed.

My question is whether, in the case of MicroPython, "too low" constitutes a real, practical, observable problem or is a theoretical statement.
Peter Hinch

ihornehrutsa
Posts: 22
Joined: Sat Oct 26, 2019 8:38 pm

Re: git-flow extension for developers

Post by ihornehrutsa » Mon Dec 07, 2020 8:50 pm

pythoncoder wrote:
Mon Dec 07, 2020 5:46 pm
My question is whether, in the case of MicroPython, "too low" constitutes a real, practical, observable problem or is a theoretical statement.
ESP32 has such a problem. ESP-IDF has version 4.2 now and MicroPython stucks in may(v4.0.1) and march(v3.3)

Post Reply