On Thu, 2018-07-26 at 07:30 +0200, Nathan Cutler wrote: > > S-1 is arguably the more important of the two, since it will always > > have > > a larger installed base. Changes to master are often motivated by > > a > > desire to get something into S-1. > > Another idea: > > Features could be developed on, and initially merged into, the > earliest > release they are targeting. Features that are targeting Luminous > would > be developed, tested, and initially released on Luminous. > > The developer of the feature would be responsible for forward- > porting > the feature to more recent branches (mimic and master in the above > example). I think this may make sense on very specific occasions; e.g., when the code has substantially changed in master, such that fixing it in master first would be significantly tricky when backporting. As a general rule though, I think this will generate quite a bit of confusion. This could be addressed by tagging the `cherry-pick -x` with the release from which it was forward-ported, but it seems to me (maybe I'm just being dense though) that it would sort of break the quasi- sequential flow of git, with a bit of indirection introduced -- i.e., some cherry-picks will be backports, and others forward-ports; unless we stick with one and that's the process. -Joao -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
