RE: Ntfs3 git repo in github should not back merge

[Konstantin Komarov <almaz.alexandrovich@paragon-software.com>]

> 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