Contributors mailing list archives
Re: Confusion about branch 9.0 in githubby
Tecnativa. S. L., Pedro M. Baeza
Guewen, about that, I know your preference of splitting too much the commits. I give you my opinion about that: I think you should document this with code comments, not with commits, because the end result is the code. If you download on the AppStore a module, you don't have this commit history to see what you want to reflect.
Anyway, Eric's method can be extended saying: you can review starting from this commit to acommodate to your commit approach.
About the Stephane's sentence about having all present modules in the 9.0 branch, that's not really true, because we only have what was already present in the moment of the migration, but not later. I have already merged about 10 new modules in the repositories since the migration. A merge strategy also doesn't serve if the repository is not totally clean (without nothing done) in the experiences I have tried, so that was why I ended up with the procedure I have put.
2015-11-13 13:23 GMT+01:00 Guewen Baconnier <firstname.lastname@example.org>:
You consider that a migration is a 2 commits work which is silly if the addon is a bit elaborated.
A unique commit for a migration seems utterly wrong to me in many situations.
I will never ever migrate 'connector' or 'magentoerpconnect' in one commit. Even smaller addons I wouldn't, when you work on a migration, you often have to make choices, for instance when you fix a bug or when you have to change a feature, this is in the commits that it should be documented and you shouldn't mix them all.We **must not** break good commits practice just because some users are confused because they don't read a readme file.On Fri, Nov 13, 2015 at 11:53 AM, Daniel Reis <email@example.com> wrote:Guewen, there is a solution for the review diff: Ask the author to do the migration work in a single commit, and then review only that commit instead of the full diff. Personally, there are times where I want to review untouched parts of the code, so if a also have the full module diff I would find that useful. In a nutshell: - For authors, the work to port from 8.0 to 9.0 is about the same in each solution (see Pedro's link). - For reviewers, focusing in the migration changeset commit solves the review effort issue. - For "end users" it is clear about what modules are available. /DR