On Sat, Jan 20, 2018 at 08:53:17AM +0100, Igor Gnatenko wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Sat, 2018-01-20 at 00:51 +0000, Tim Landscheidt wrote: > > Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > > > > […] > > > > I was not fully aware of this and I've personally hit this difficulty > > > > not on my proposal of the remove hicolor icon caches but on proposing, > > > > for example, OpenIPMI or readline changes. > > > > Most of my changes were by those packages maintainers simple discarded > > > > (readline 100% and in case OpenIPMI ~50%). > > > > I'm not trying to blame anyone here but all this only *result* of some > > > > assumptions that master branch must be fully compatible with more than > > > > one distribution or more than one distribution versions. > > > Well, I think because this is simply easy. If we separate changelog to > > > other > > > file / make it auto-generated, then it should be easier for people to > > > maintain > > > f26/f27/master branches separately. Right now, cherry-picking is never > > > cleanly > > > applies due to changelog. Well, we need to do something with Release field > > > as > > > well, I don't know why it is still not auto-generated... > > > […] > > > > GNU had the same problem in various projects and came up > > with a Git merge driver for changelogs > > (http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-chan > > gelog.c). > > Now that is a text parsing orgy in C, probably provably cor- > > rect, but it suggests that a simpler solution for RPM spec > > files should be very feasible. > > OMG! > > Would you be interested to write such driver for RPM specs? The gnulib changlog driver is already packaged as git-merge-changelog, if that helps in any way. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
