Ntfs3 git repo in github should not back merge

Ntfs3 git repo in github should not back merge

[Kari Argillander]

Hello Konstantin.

I notice that you have made back-merge in ntfs3 git repo in github.
This should not be done without good reason and there is none in this
case. If there is reason you should also write good merge commit for it.
As you are just coming to maintener I will write little info about how
this stuff works. I'm not maintainer, but I have study about how kernel
is maintained.

Here is link which you can read about back-merges. If you have any
questions you can always ask.

01.org/linuxgraphics/gfx-docs/drm/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees

You could also go check some other trees how they do it. Usually there
is next/master/main/for-next which will be repo which will contain stuff
for next-merge window. This is usually based on rc1, rc2, rc3 depending
when you put first patches to next merge window. As you based your
branch top of the rc5.

https://git.kernel.org/?s=idle

Because your master branch is  for next you could have rebased your
branch top of the rc7 if you want to but that is kinda pointless. You
could always fix little mistakes in next branch with rebase, but you
should propably info this action to ntfs3 mailing list.

The idea is that this repo has very clean history always when it get
merged to Linus tree. Also developers who work with ntfs3 can see
everything in one eye.

Example take a look Ext4 dev (for-next) branch
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=dev
You see that this is based on rc2. Theodore will create pull-request
based on this when he creates pull-request. Very clean history and no
back-merges.

If you wonder how should you do development then if you can't back
merge. You should do develompent in linux-next branch. This way you
always know if others break something reletad to ntfs3. Then you check
who was it and send email about it and you solve it together. It can be
tricky some times who will take which patches but help is given if you
ask.

There is lot of small info what I did not include here and hopefully
everything is correct. Hopefully you will also in near future respond
patches which are sent to you. There is already quite lot. If you need
any help how to maintainer should handle those I can assisntant you best
I can. There will be example little bit work howto make all fixes tags
right because you will have to rebase your current commits as they do
not have example reviewed-tags.

I also CC linux-next maintainer as he knows this stuff and can say if I
say something wrong. And I feel like new maintainer can have little help
from gurus.

Kari Argillander

RE: Ntfs3 git repo in github should not back merge

[Konstantin Komarov]

> From: Kari Argillander <kari.argillander@gmail.com>
> Sent: Wednesday, August 25, 2021 10:28 PM
> To: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>; ntfs3@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org; Stephen Rothwell <sfr@canb.auug.org.au>
> Subject: Ntfs3 git repo in github should not back merge
> 
> Hello Konstantin.
> 
> I notice that you have made back-merge in ntfs3 git repo in github.
> This should not be done without good reason and there is none in this
> case. If there is reason you should also write good merge commit for it.
> As you are just coming to maintener I will write little info about how
> this stuff works. I'm not maintainer, but I have study about how kernel
> is maintained.
> 
> Here is link which you can read about back-merges. If you have any
> questions you can always ask.
> 
> 01.org/linuxgraphics/gfx-docs/drm/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees
> 

Hi Kari!
Thanks a lot for this piece of information. It is really important to know.
Apologies for messing the back-merge up, we'll study the provided documentation
and will follow it in future (and won't be back merging again).
There is really a LOT of information to handle there.

> You could also go check some other trees how they do it. Usually there
> is next/master/main/for-next which will be repo which will contain stuff
> for next-merge window. This is usually based on rc1, rc2, rc3 depending
> when you put first patches to next merge window. As you based your
> branch top of the rc5.
> 
> https://git.kernel.org/?s=idle
> 
> Because your master branch is  for next you could have rebased your
> branch top of the rc7 if you want to but that is kinda pointless. You
> could always fix little mistakes in next branch with rebase, but you
> should propably info this action to ntfs3 mailing list.
> 
> The idea is that this repo has very clean history always when it get
> merged to Linus tree. Also developers who work with ntfs3 can see
> everything in one eye.
> 
> Example take a look Ext4 dev (for-next) branch
> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=dev
> You see that this is based on rc2. Theodore will create pull-request
> based on this when he creates pull-request. Very clean history and no
> back-merges.
> 
> If you wonder how should you do development then if you can't back
> merge. You should do develompent in linux-next branch. This way you
> always know if others break something reletad to ntfs3. Then you check
> who was it and send email about it and you solve it together. It can be
> tricky some times who will take which patches but help is given if you
> ask.
> 
This last paragraph actually is not very clear. Can you please refer couple of
examples of such activity?

> There is lot of small info what I did not include here and hopefully
> everything is correct. Hopefully you will also in near future respond
> patches which are sent to you. There is already quite lot. If you need
> any help how to maintainer should handle those I can assisntant you best
> I can. There will be example little bit work howto make all fixes tags
> right because you will have to rebase your current commits as they do
> not have example reviewed-tags.
> 
We've just applied several patches proposed for past ~month. Please have a look
on them - we tried to stick to the patch acception guidelines. Hopefully, they
are good from this point of view.

> I also CC linux-next maintainer as he knows this stuff and can say if I
> say something wrong. And I feel like new maintainer can have little help
> from gurus.
> 
> Kari Argillander

Thanks a lot once again, Kari! Really great help here.

Best regards,
Konstantin

Re: Ntfs3 git repo in github should not back merge

[Kari Argillander]

On Fri, Aug 27, 2021 at 06:27:47PM +0000, Konstantin Komarov wrote:
> > From: Kari Argillander <kari.argillander@gmail.com>
> > Sent: Wednesday, August 25, 2021 10:28 PM
> > To: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>; ntfs3@lists.linux.dev
> > Cc: linux-kernel@vger.kernel.org; Stephen Rothwell <sfr@canb.auug.org.au>
> > Subject: Ntfs3 git repo in github should not back merge
> > 
> > Hello Konstantin.
> > 
> > I notice that you have made back-merge in ntfs3 git repo in github.
> > This should not be done without good reason and there is none in this
> > case. If there is reason you should also write good merge commit for it.
> > As you are just coming to maintener I will write little info about how
> > this stuff works. I'm not maintainer, but I have study about how kernel
> > is maintained.
> > 
> > Here is link which you can read about back-merges. If you have any
> > questions you can always ask.
> > 
> > 01.org/linuxgraphics/gfx-docs/drm/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees
> > 
> 
> Hi Kari!
> Thanks a lot for this piece of information. It is really important to know.
> Apologies for messing the back-merge up, we'll study the provided documentation
> and will follow it in future (and won't be back merging again).
> There is really a LOT of information to handle there.

I think we should fix this before sending pr to Linus. I think he will
not be happy to see it. You are allowed to force push in situations like
this.

> > You could also go check some other trees how they do it. Usually there
> > is next/master/main/for-next which will be repo which will contain stuff
> > for next-merge window. This is usually based on rc1, rc2, rc3 depending
> > when you put first patches to next merge window. As you based your
> > branch top of the rc5.
> > 
> > https://git.kernel.org/?s=idle
> > 
> > Because your master branch is  for next you could have rebased your
> > branch top of the rc7 if you want to but that is kinda pointless. You
> > could always fix little mistakes in next branch with rebase, but you
> > should propably info this action to ntfs3 mailing list.
> > 
> > The idea is that this repo has very clean history always when it get
> > merged to Linus tree. Also developers who work with ntfs3 can see
> > everything in one eye.
> > 
> > Example take a look Ext4 dev (for-next) branch
> > https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=dev
> > You see that this is based on rc2. Theodore will create pull-request
> > based on this when he creates pull-request. Very clean history and no
> > back-merges.
> > 
> > If you wonder how should you do development then if you can't back
> > merge. You should do develompent in linux-next branch. This way you
> > always know if others break something reletad to ntfs3. Then you check
> > who was it and send email about it and you solve it together. It can be
> > tricky some times who will take which patches but help is given if you
> > ask.
> > 
> This last paragraph actually is not very clear. Can you please refer couple of
> examples of such activity?

Good that you ask.

Example if you now we are trying to get ntfs3 in to 5.15. Linux-next is
kinda snapshot what 5.15 will look like. It is not absolute truth but
close. Our master branch will included linux-next every day and so are
everyone else trees. If you develop something new you should do this in
linux-next so you will notice right away if something breaks. It is good
happit to rebase current work top that if not everyday at least once a
week.

When something breaks you will know that something needs to be resolved
before you make pr. Or at least you need to info Linus that this kind of
situation will happend with tree X. If build breaks you will probably
get email from Stephen about it. But there is situations which can break
ntfs3 without breaking the build.

One another thing with linux-next is that if you use it you will help
others. If something breaks you can info other maintainer that something
is wrong. Same thing will happend other way around. 

Little off topic but, I will in near future make CI system which will
test ntfs3 in linux-next everytime new linux-next tag comes up. 

So using linux-next is not absolute necessary, but will benefit
everyone. There will also be times when someone send you patch and that
patch will only apply example to last stable Linux version. Then you ask
to rebase top of the linux-next or ntfs3/master. This is also reason why
development should be done in linux-next.

> 
> > There is lot of small info what I did not include here and hopefully
> > everything is correct. Hopefully you will also in near future respond
> > patches which are sent to you. There is already quite lot. If you need
> > any help how to maintainer should handle those I can assisntant you best
> > I can. There will be example little bit work howto make all fixes tags
> > right because you will have to rebase your current commits as they do
> > not have example reviewed-tags.
> > 
> We've just applied several patches proposed for past ~month. Please have a look
> on them - we tried to stick to the patch acception guidelines. Hopefully, they
> are good from this point of view.

They are ok :) Only wrong thing which I found was that with one patch
you first apply v1 and then v2. v1 was not needed. These where patches

v1:
 be87e821fdb5 ("fs/ntfs3: Fix one none utf8 char in source file")
v2:
 24516d481dfc ("fs/ntfs3: Restyle comment block in ni_parse_reparse()")

But this mistake where ok and did not do any harm.

I notice that you also made devel branch to github. I can help you with
these things that you first made changes to devel and then send email to
ntfs3 list or directly to me and I can check that it is ok and then you
push it to master. This way no messing up "public" branch. Just for
starter so that we get these things going.

I also advice you to not only applying patches, but also replying emails
to thouse which you did not apply. Usually people will resend in week or
two if nobody haven't respond.

> > I also CC linux-next maintainer as he knows this stuff and can say if I
> > say something wrong. And I feel like new maintainer can have little help
> > from gurus.
> > 
> > Kari Argillander
> 
> Thanks a lot once again, Kari! Really great help here.

Happy to help.

> Best regards,
> Konstantin

Re: Ntfs3 git repo in github should not back merge

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]

Hi Konstantin,

On Wed, 25 Aug 2021 22:27:46 +0300 Kari Argillander <kari.argillander@gmail.com> wrote:
>
> I notice that you have made back-merge in ntfs3 git repo in github.
> This should not be done without good reason and there is none in this
> case. If there is reason you should also write good merge commit for it.

This is correct, but in this case with an initial submission, Linus is
likely to be a bit easier on you.  Just explain that you realise that
you probably should not have done the back merge.  Also, if you are
going to merge another branch you should not use the github web
interface to do it.  It does not allow you to produce a useful commit
message for the merge commit.  Linus has expressed this recently about
another tree that is maintained on github (unfortunately in a private
message, so it is not archived anywhere).

> Here is link which you can read about back-merges. If you have any
> questions you can always ask.
> 
> 01.org/linuxgraphics/gfx-docs/drm/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees

Also available in the kernel tree at Documentation/maintainer/...

> You could also go check some other trees how they do it. Usually there
> is next/master/main/for-next which will be repo which will contain stuff
> for next-merge window. This is usually based on rc1, rc2, rc3 depending
> when you put first patches to next merge window. As you based your
> branch top of the rc5.

Again with an initial submission this should not be a problem.  And, in
any case, varies among maintainer quite a bit.  But -rc1/2 is usually a
good place to start your next round of development.

> Because your master branch is  for next you could have rebased your
> branch top of the rc7 if you want to but that is kinda pointless. You
> could always fix little mistakes in next branch with rebase, but you
> should propably info this action to ntfs3 mailing list.

Do *not* rebase a published branch except in exceptional circumstances.
All branches included in linux-next should be considered published.

> The idea is that this repo has very clean history always when it get
> merged to Linus tree. Also developers who work with ntfs3 can see
> everything in one eye.
> 
> Example take a look Ext4 dev (for-next) branch
> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=dev
> You see that this is based on rc2. Theodore will create pull-request
> based on this when he creates pull-request. Very clean history and no
> back-merges.

Also no rebasing (that I can remember).

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Ntfs3 git repo in github should not back merge

[Kari Argillander]

On Mon, Aug 30, 2021 at 08:23:08AM +1000, Stephen Rothwell wrote:
> Hi Konstantin,
> 
> On Wed, 25 Aug 2021 22:27:46 +0300 Kari Argillander <kari.argillander@gmail.com> wrote:
> >
> > I notice that you have made back-merge in ntfs3 git repo in github.
> > This should not be done without good reason and there is none in this
> > case. If there is reason you should also write good merge commit for it.
> 
> This is correct, but in this case with an initial submission, Linus is
> likely to be a bit easier on you.  Just explain that you realise that
> you probably should not have done the back merge.  Also, if you are
> going to merge another branch you should not use the github web
> interface to do it.  It does not allow you to produce a useful commit
> message for the merge commit.  Linus has expressed this recently about
> another tree that is maintained on github (unfortunately in a private
> message, so it is not archived anywhere).
> 
> > Here is link which you can read about back-merges. If you have any
> > questions you can always ask.
> > 
> > 01.org/linuxgraphics/gfx-docs/drm/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees
> 
> Also available in the kernel tree at Documentation/maintainer/...
> 
> > You could also go check some other trees how they do it. Usually there
> > is next/master/main/for-next which will be repo which will contain stuff
> > for next-merge window. This is usually based on rc1, rc2, rc3 depending
> > when you put first patches to next merge window. As you based your
> > branch top of the rc5.
> 
> Again with an initial submission this should not be a problem.  And, in
> any case, varies among maintainer quite a bit.  But -rc1/2 is usually a
> good place to start your next round of development.
> 
> > Because your master branch is  for next you could have rebased your
> > branch top of the rc7 if you want to but that is kinda pointless. You
> > could always fix little mistakes in next branch with rebase, but you
> > should propably info this action to ntfs3 mailing list.
> 
> Do *not* rebase a published branch except in exceptional circumstances.
> All branches included in linux-next should be considered published.

I have a guestion also then. Right now situation is that there is
examaple missing Reviewed-by tags from commits. What should we do about
thouse? Or what to do if someone forget signed-off?

You also said earlier that rebasing is ok in this message:
https://lore.kernel.org/ntfs3/20210816063225.22d992ff@canb.auug.org.au/

I understand that rebasing should be avoided at almoust all cost, but
what are the screw ups that has to be fixed with it?

Thank you for answering and clarifying things.

> 
> > The idea is that this repo has very clean history always when it get
> > merged to Linus tree. Also developers who work with ntfs3 can see
> > everything in one eye.
> > 
> > Example take a look Ext4 dev (for-next) branch
> > https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/log/?h=dev
> > You see that this is based on rc2. Theodore will create pull-request
> > based on this when he creates pull-request. Very clean history and no
> > back-merges.
> 
> Also no rebasing (that I can remember).
> 
> -- 
> Cheers,
> Stephen Rothwell