> From: Kari Argillander <kari.argillander@xxxxxxxxx> > Sent: Wednesday, August 25, 2021 10:28 PM > To: Konstantin Komarov <almaz.alexandrovich@xxxxxxxxxxxxxxxxxxxx>; ntfs3@xxxxxxxxxxxxxxx > Cc: linux-kernel@xxxxxxxxxxxxxxx; Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> > 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
