[opensuse-kde] Proposed changes to KDE patch policy
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 -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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
On Wed, 20 Mar 2013 10:18, Luca Beltrame
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 [snip]
Let's play devils advocate and exaggerate: - No "not annotated" patch will survive the next commit (at least outside devel:KDE) That would cast out any prior (old) not annotated patches. Hmmm. That does not sound so bad. Just which of the existing patches are really NEEDED now? What in openSUSE is not "clean" enough to "just" take Upstream tar-balls, pack them and a "minimal" spec file into obs and be done? Do "we" to do much patches in QT / X11 / basesys that we need them, or are the error that the patches should correct still the in upstream? I ask these questions, be because they will be asked, if not now then later. Better to have answers ready then. And no, I do not have the answers, but I would like to have... - Yamaban. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 20 marzo 2013 10:57:17, Yamaban ha scritto:
- No "not annotated" patch will survive the next commit (at least outside devel:KDE)
Hrvoje already volounteered to reannotate the patches in case this policy is put forward.
Hmmm. That does not sound so bad. Just which of the existing patches are really NEEDED now?
That's the point of the review. I'm supposed to send another mail about it, I hope to do so by this evening. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
participants (3)
-
Luca Beltrame
-
todd rme
-
Yamaban