Feature added by: Michal Vyskocil (mvyskocil) Feature #309578, revision 1 Title: Better maintenance of src.rpm changes Requested by: Michal Vyskocil (mvyskocil) Partner organization: openSUSE.org Description: During a SUSE development, we are often using upstream source rpms. The most notable example is jpackage.org - a source of almost every of our Java package. But importing of jpackage.org src.rpm we create a fork of this package and it is not possible to maintain our and future upstream changes. Everything needs to be done manually, which is horribly slow and also error prone apporach. There is a better solution based on patch queues - SUSE changes are considered as a set of patches on top of the upstream sources. This method has many advantages - like sharing of our changes with upstream is piece of cake, updating to the new upstream version is simple - just pop all patches and try to recreate them to newest version. upg is the tool try to smoothly intergrate three different systems into one - osc, git and stg to make this concept easy to use. It manages patches using stg, it is well integrated into BuildService using osc and comes with a few interesting concepts, which will make work with patches more reasonable: * scratches - patches created by simple script - they are never "popped", simply recreated again, so they never failed * heuristics - sometimes patches fails only because PatchXY: number is changed in new upstream version, so upg would be able to fix that * changes - it's a pain for each versioning system, but upg deal with it and try to have them in a good state What is done: upg already exists in very raw version with a basic concept implemented, tested and working (netbeans 6.8 update has been done using this tool). What needs to be done: A public release, implemented configuration system, more heuristics and add more tests than now - yes and also some documentation will be necessary Business case (Partner benefit): openSUSE.org: Why do we want this? Well the most probable user is me - I'll use it for a big automation of my work with a jpackage.org. But this tool can also change a concept of rpm packaging as it is done today. Nowadays we maintain a lot of packages in different code streams and projects, because every one have their own processes, needs and requirements. Using this approach we might be able to reuse an effort of some other projects and be up-to-date with them. Also will be able to share our improvements more easily. The second big use case of this system is an ability of maintain our own forks (or branches) of packages improved for specific purposes. -- openSUSE Feature: https://features.opensuse.org/309578