On Mon, 2016-06-06 at 19:05 +0200, Milan Crha wrote: > Right, it's unrealistic in some cases to land all of that at one > time. > Side branches is a nice idea, but it won't work, because you do not > have any influence on the other project maintainers usually, thus > even > a bugzilla requests can lurk there for a long time. Having a side > branch only means that the maintainers whom do not follow particular > mailing list will notice only later, rather than sooner.
Hi, If you have a patch that e.g. adapts another module to your API change, but the relevant maintainers are not responsive on Bugzilla, you should feel free to just push ahead with your changes. If you're not comfortable pushing to other modules, you can contact the release team and we'll push your work for you. We understand this happens sometimes; everyone's busy, but nobody wants your work to get blocked in such cases. (I remember recently we had this issue with e-d-s and california, although california is neither in jhbuild nor continuous, so we're not going to nag you if it breaks.) I agree with you that when landing a big API change, if you don't want to use side branches, then a revert is less preferable to tagging in Continuous and branching in jhbuild. (In such cases, it'd be great if you could handle that before pushing the API change, though. :) Michael _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
