Hi Matthias, >> the previous patch is submitted by zijun , as he is not working on this >> project, I take over his job, so can we assume abandon the previous patch, >> using my new patch ? thank you. >> regards. > > Your patch is clearly based on zijun's one, it even has the same subject. A > change of authorship shouldn't result in resetting the version number, it's > still the same patch/series. You can always add a 'Co-developed-by:' tag to > indicate that someone else contributed to a patch, or use a 'From:' tag if > you only made minor changes on top of someone else's work. I really don’t care much since that is for them and their company policy to figure out. > Not sure how to proceed best with the version number, especially since there > are already 3 versions of the 'new' patch. Either option can create confusion, > I guess you can continue with the new scheme, it seems the patch is almost > ready to land anyway. It is a total mess already for a dead simple patch like this. And they keep messing it up differently every time. I provided a btusb_generate_qca_nvm_name() in one of my replies, where the variant variable was declared without NULL assignment and the ram_version was converted from little endian in place. That was 28th of September and 4 patches later the patch is still not ready to be merged. The maintainer hands you the recipe and you still screw up the cake multiple times; I am just done with this. The next version would be a v16 btw. So seriously, how can we have 15 revisions so far and still not have this in a mergable state? Regards Marcel
