linux-kernel - RE: Ntfs3 git repo in github should not back merge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Aug 2021 18:27:47 +0000
From:   Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
To:     Kari Argillander <kari.argillander@...il.com>,
        "ntfs3@...ts.linux.dev" <ntfs3@...ts.linux.dev>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Stephen Rothwell" <sfr@...b.auug.org.au>
Subject: RE: Ntfs3 git repo in github should not back merge

> From: Kari Argillander <kari.argillander@...il.com>
> Sent: Wednesday, August 25, 2021 10:28 PM
> To: Konstantin Komarov <almaz.alexandrovich@...agon-software.com>; ntfs3@...ts.linux.dev
> Cc: linux-kernel@...r.kernel.org; Stephen Rothwell <sfr@...b.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