Re: SubmittingPatchs: clarify choice of base and testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> Anyway, I can see why you suggest the "base on master and merge", it has
> its benefits, but it is in apparent conflict with existing advice added
> in 76644e3268b (documentation: add tutorial for first contribution,
> 2019-05-17).

I do not mind if you help the effort by updating that document as
well to match, but I have a feeling that the first contribution,
with a follow-up to fix, is sufficiently different from a more
advanced "I need something more than and not yet in 'master' for my
new topic" use case.

> I.e. the "After Review Approval" section (of all places) discusses what
> to do in that situation. It is narrowly talking about submitting
> something on top of your own topic, but the advice should be the same in
> either case I'd think.

No, the advice should be totally different between these two cases.

The "fix or enhance what you already sent" is a continuation of the
same topic, just you, your reviewers and your maintainer were all
not competent enough to catch the shortcomings before the topic hits
'master', and it does make sense to make correction directly on top.

What I am describing here is "I am doing something new, but uses
what is not yet in 'master'.  The author of that other thing I am
depending on may or may not mean to help this new thing when they
wrote it, but the important point is that this is not a continuation
of their topic. It merely depends on them".

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux