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?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
git-flow extension for developers
Re: git-flow extension for developers
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.
-
- Posts: 35
- Joined: Sat Oct 26, 2019 8:38 pm
Re: git-flow extension for developers
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?
Re: git-flow extension for developers
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.
- 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.
-
- Posts: 35
- Joined: Sat Oct 26, 2019 8:38 pm
Re: git-flow extension for developers
It seems that Micropython uses Low-Frequency Integration
https://martinfowler.com/articles/branc ... -frequency
But too low and slow.![Sad :(](./images/smilies/icon_e_sad.gif)
https://martinfowler.com/articles/branc ... -frequency
But too low and slow.
![Sad :(](./images/smilies/icon_e_sad.gif)
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: git-flow extension for developers
Are you aware of any problematic merge conflicts on the project?ihornehrutsa wrote: ↑Sat Dec 05, 2020 7:13 pmIt seems that Micropython uses Low-Frequency Integration
https://martinfowler.com/articles/branc ... -frequency
But too low and slow.![]()
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
-
- Posts: 35
- Joined: Sat Oct 26, 2019 8:38 pm
Re: git-flow extension for developers
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.
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.
Re: git-flow extension for developers
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.
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.
-
- Posts: 35
- Joined: Sat Oct 26, 2019 8:38 pm
Re: git-flow extension for developers
This pull request https://github.com/micropython/micropython/pull/6276 does not seem as High-Frequency Integration.
But anyway I vote to approve it.
But anyway I vote to approve it.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: git-flow extension for developers
I was responding to
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.
From reading the article, the consequence of "too low" is that difficult merge conflicts arise taking excessive time to resolve.But too low and slow.
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
Index to my micropython libraries.
Index to my micropython libraries.
-
- Posts: 35
- Joined: Sat Oct 26, 2019 8:38 pm
Re: git-flow extension for developers
ESP32 has such a problem. ESP-IDF has version 4.2 now and MicroPython stucks in may(v4.0.1) and march(v3.3)pythoncoder wrote: ↑Mon Dec 07, 2020 5:46 pmMy question is whether, in the case of MicroPython, "too low" constitutes a real, practical, observable problem or is a theoretical statement.