On Wed, Mar 20, 2013 at 10:18 AM, Luca Beltrame
Hello everyone,
as it was discussed as yesterday's meeting, the patch policy for KDE packages has been quite inconsistent. Some patches are annotated, others aren't and recently, with the giflib patches, it was clearly shown that it needed an adjustment.
The general agreement for yesterday's meetings was:
- We will have to review our current patches - Obsolete patches can be removed, others can be upstreamed: the goal is to keep patches only for upstream fixes (e.g. in the next release) or for openSUSE specific bits - We need to set a patch policy and stick to it
With regards to the last point, the proposal made was to enforce annotated patches[1]. If this comes into effect, patches without annotation will not be accepted for submit requests, likewise when forwarding packages and changes from KDF to Factory.
At the same time, we're thinking of having a repository to hold these patches so that we can keep history, and make adjustments as necessary. The objective is to have an open and peer-reviewed process that ensure that all the code changes made to the KDE packages are tracked properly (the ultimate goal would be to have this in OBS, see the meeting minutes).
I'll send a separate mail on patch review later.
Comments?
[1] http://en.opensuse.org/openSUSE:KDE_Patch_Annotation_Policy
1. I think we need to make clear which annotations are required and which are not. For example, patch-upstream should always be there, no exceptions 2. I think there should be an annotation that says which KDE SC or package release number the patch was added, and another for when it was most recently rebased 3. I think there should be an annotation that explicitly says whether it is an upstream bug, upstream feature, openSUSE-specific bug, openSUSE-specific feature, or buildsystem-fix. Bugs must have bug numbers associated with them if the software has a bugzilla or equivalent system, and if there isn't a bugzilla or equivalent but there is a public mailing list it should have a link to a mailing list email I have had an idea that I have been thinking about but am not entirely settled on. As most people probably know, rpm has a system where you can specify build-time variables, and OBS allows you to set these on a per-project basis. I was thinking that it might be a good idea to put all bugs in one of 5 categories: upstream bug, upstream feature, openSUSE-specific bug, openSUSE-specific feature, or buildsystem-fix. Each of these categories would have an if-test around them. The variables for these if-test would default to 0, but repos like KDF and KRX would override them with 1 so that all patches are built. This would allow people, however, to build pristine versions of KDE packages from the same spec file. However, I am not sure this is worth the extra trouble. You don't see people trying to build pristine versions of KDE much in OBS, but I am not sure whether that is a lack of interest or due to the difficult involved in doing so. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org