[opensuse-packaging] uncertainties about patch packaging

older
[opensuse-packaging] [help]how to...

Adam Spiers

6 May 2013 6 May '13

09:21

Hi all, there are some minor issues with: https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines Firstly, it does not document the exact format I should use in the .changes entry. The "Patch life cycle" section says: Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. For example: * Add package-awesomeness.patch: Makes package awesome ... but an example is not sufficient to document a format. It's not clear whether documenting movement through the patch cycle in the .changes file is supposed to be machine-parseable, or just readable by humans. Either way, the requirements for conformity need to be more explicit. It's also unclear how I should add a line # PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#123456 when there is no bnc entry. If it's OK to omit the bnc# field, the page should say that. Or if it's not, the page should explicitly say that a bugzilla entry should be filed if one doesn't already exist. Finally, the page is entitled 'guidelines', but if non-conformance is grounds for rejecting a submitreq, I think 'guidelines' is too weak and it really should be labelled as a 'policy'. Thanks! Adam -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Show replies by date

Jan Engelhardt

6 May 6 May

09:46

On Monday 2013-05-06 11:21, Adam Spiers wrote:

...

Firstly, it does not document the exact format I should use in the .changes entry. The "Patch life cycle" section says:

Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. For example:

* Add package-awesomeness.patch: Makes package awesome

... but an example is not sufficient to document a format. It's not clear whether documenting movement through the patch cycle in the .changes file is supposed to be machine-parseable, or just readable by humans.

Just humanly parsable. Machines can simply scan through the OBS log and detect addition/deletion of the file and its status by way of looking at the Type 2 metadata.

...

It's also unclear how I should add a line

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#123456

when there is no bnc entry.

There is not much else besides leaving out the bnc# you could do. (You can edit the page.)

...

If it's OK to omit the bnc# field, the page should say that. Or if it's not, the page should explicitly say that a bugzilla entry should be filed if one doesn't already exist.

Finally, the page is entitled 'guidelines', but if non-conformance is grounds for rejecting a submitreq, I think 'guidelines' is too weak and it really should be labelled as a 'policy'.

A guideline for package maintainers, who choose to make a policy out of it for other submitters :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers

10:44

Jan Engelhardt (jengelh@inai.de) wrote:

...

On Monday 2013-05-06 11:21, Adam Spiers wrote:

...
Firstly, it does not document the exact format I should use in the .changes entry. The "Patch life cycle" section says:

Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. For example:

* Add package-awesomeness.patch: Makes package awesome

... but an example is not sufficient to document a format. It's not clear whether documenting movement through the patch cycle in the .changes file is supposed to be machine-parseable, or just readable by humans.

Just humanly parsable. Machines can simply scan through the OBS log and detect addition/deletion of the file and its status by way of looking at the Type 2 metadata.

OK, I tweaked the page for that.

...

...
It's also unclear how I should add a line

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#123456

when there is no bnc entry.

There is not much else besides leaving out the bnc# you could do.

Like I said, the alternative is to explicitly require a bugzilla entry should be filed if one doesn't already exist. So you are saying that it is better to leave out the bnc# ? Or are there some circumstances in which it is better to file a bnc?

...

(You can edit the page.)

Not until I know what the correct policy is :)

...

...
Finally, the page is entitled 'guidelines', but if non-conformance is grounds for rejecting a submitreq, I think 'guidelines' is too weak and it really should be labelled as a 'policy'.

A guideline for package maintainers, who choose to make a policy out of it for other submitters :)

In that case the page should say something like: This page gives guidelines for managing the life cycle of patches to packages. Each project/package maintainer is free to adopt their own policy regarding how strictly they require submissions to adhere to these guidelines, so non-conforming submitrequests will be tolerated to different degrees based on the context. Is that OK? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dominique Leuenberger a.k.a. Dimstar

10:30

Quoting Adam Spiers :

...

...
...
It's also unclear how I should add a line

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#123456

when there is no bnc entry.

There is not much else besides leaving out the bnc# you could do.

Like I said, the alternative is to explicitly require a bugzilla entry should be filed if one doesn't already exist. So you are saying that it is better to leave out the bnc# ? Or are there some circumstances in which it is better to file a bnc?

Preferably there is a bnc (or an upstream bug tracker reference). There are cases where this does not make sense (e.g. when you backport a git commited fix to a package, and that did not have a bug report assigned; creating one for the sake of the ID is useless). There is an exception to this statement: in case of maintenance updates for released products, a BNC# entry is absolutely mandatory (less in the patch tag than in .changes file). so I would say: always add an entry if it makes sense.. for good reasons, you're allowed to omit it.

...

This page gives guidelines for managing the life cycle of patches to packages. Each project/package maintainer is free to adopt their own policy regarding how strictly they require submissions to adhere to these guidelines, so non-conforming submitrequests will be tolerated to different degrees based on the context.

Not entirely: Factory uses this guideline. Strictly; so if your package goes to a devel project where it's not enforced, the package will not manage to enter Factory. Of course, if the package is not destined for Factory, none of the guidelines really apply... ever... Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers

11:16

Dominique Leuenberger a.k.a. Dimstar (dimstar@opensuse.org) wrote:

...

Quoting Adam Spiers :

...
...
...
It's also unclear how I should add a line

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#123456

when there is no bnc entry.

There is not much else besides leaving out the bnc# you could do.

Like I said, the alternative is to explicitly require a bugzilla entry should be filed if one doesn't already exist. So you are saying that it is better to leave out the bnc# ? Or are there some circumstances in which it is better to file a bnc?

Preferably there is a bnc (or an upstream bug tracker reference). There are cases where this does not make sense (e.g. when you backport a git commited fix to a package, and that did not have a bug report assigned; creating one for the sake of the ID is useless).

The case I encountered is where there was only a patch and a bug filed in another distribution (Arch), not upstream.

...

There is an exception to this statement: in case of maintenance updates for released products, a BNC# entry is absolutely mandatory (less in the patch tag than in .changes file).

so I would say: always add an entry if it makes sense.. for good reasons, you're allowed to omit it.

...
This page gives guidelines for managing the life cycle of patches to packages. Each project/package maintainer is free to adopt their own policy regarding how strictly they require submissions to adhere to these guidelines, so non-conforming submitrequests will be tolerated to different degrees based on the context.

Not entirely: Factory uses this guideline. Strictly; so if your package goes to a devel project where it's not enforced, the package will not manage to enter Factory. Of course, if the package is not destined for Factory, none of the guidelines really apply... ever...

Thanks, this is all very useful information. But it also confirms that a) there is essential information missing from the wiki page, and b) I am not yet knowledgeable enough in this area to fix that. So I would much prefer if you could correct the wiki page rather than posting the information here, where it will rapidly get forgotten about / buried in the list archives ... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dominique Leuenberger a.k.a. Dimstar

10:48

Quoting Adam Spiers :

...

...
Preferably there is a bnc (or an upstream bug tracker reference). There are cases where this does not make sense (e.g. when you backport a git commited fix to a package, and that did not have a bug report assigned; creating one for the sake of the ID is useless).

The case I encountered is where there was only a patch and a bug filed in another distribution (Arch), not upstream.

An interesting case and unfortunately something I see a lot with other dists: they often do not care to forward patches to upstream. If the bug is real, and upstream is alive and kicking, I would recommend to file a bug in the upstream tracker of the respective project and make sure they are aware of this.. this is a simple responsibility I derive from GPL :) (ok, the GPL asks us to distribute the sources of the modification.. I favor that such modifications flow back into the upstream code base whenever they make sense).

...

Thanks, this is all very useful information. But it also confirms that a) there is essential information missing from the wiki page, and b) I am not yet knowledgeable enough in this area to fix that. So I would much prefer if you could correct the wiki page rather than posting the information here, where it will rapidly get forgotten about / buried in the list archives ...

I generally have a huge pain writing wiki pages that make sense to others than myself :( As can be seen in the paragraphs cited by you :) Any volunteers to help out here? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt

15:53

On Monday 2013-05-06 12:48, Dominique Leuenberger a.k.a. Dimstar wrote:

...

...
Thanks, this is all very useful information. But it also confirms that a) there is essential information missing from the wiki page, and b) I am not yet knowledgeable enough in this area to fix that. So I would much prefer if you could correct the wiki page rather than posting the information here, where it will rapidly get forgotten about / buried in the list archives ...

I generally have a huge pain writing wiki pages that make sense to others than myself :( As can be seen in the paragraphs cited by you :) Any volunteers to help out here?

Oh, if you write some starting text, I feel the urge to correct and expand on it! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Adam Spiers

16:08

Dominique Leuenberger a.k.a. Dimstar (dimstar@opensuse.org) wrote:

...

Quoting Adam Spiers :

...
...
Preferably there is a bnc (or an upstream bug tracker reference). There are cases where this does not make sense (e.g. when you backport a git commited fix to a package, and that did not have a bug report assigned; creating one for the sake of the ID is useless).

The case I encountered is where there was only a patch and a bug filed in another distribution (Arch), not upstream.

An interesting case and unfortunately something I see a lot with other dists: they often do not care to forward patches to upstream. If the bug is real, and upstream is alive and kicking, I would recommend to file a bug in the upstream tracker of the respective project and make sure they are aware of this.. this is a simple responsibility I derive from GPL :) (ok, the GPL asks us to distribute the sources of the modification.. I favor that such modifications flow back into the upstream code base whenever they make sense).

Yeah, I absolutely agree about adhering to the spirit of the GPL, not just the letter. In my case, IIRC the bug was already fixed upstream in git, but only filed downstream in Arch.

...

...
Thanks, this is all very useful information. But it also confirms that a) there is essential information missing from the wiki page, and b) I am not yet knowledgeable enough in this area to fix that. So I would much prefer if you could correct the wiki page rather than posting the information here, where it will rapidly get forgotten about / buried in the list archives ...

I generally have a huge pain writing wiki pages that make sense to others than myself :( As can be seen in the paragraphs cited by you :)

:) I think you are too hard on yourself. The existing paragraphs are perfectly understandable; they just had a few small holes due to missing information IMHO. As a native English speaker I am always happy to tweak wording where I see the opportunity to help clarify things. But I struggle to create new material in an area where I am not an expert :) Thanks! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jan Engelhardt

15:49

On Monday 2013-05-06 12:44, Adam Spiers wrote:

...

...
...
It's also unclear how I should add a line

# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch bnc#123456

when there is no bnc entry.

There is not much else besides leaving out the bnc# you could do.

Like I said, the alternative is to explicitly require a bugzilla entry should be filed if one doesn't already exist. So you are saying that it is better to leave out the bnc# ? Or are there some circumstances in which it is better to file a bnc?

Patches come and go like socks. Nobody really wants a bugzilla entry for each and every one. Especially since Firefox is so slow on Atom-class..

...

...
A guideline for package maintainers, who choose to make a policy out of it for other submitters :)

In that case the page should say something like:

This page gives guidelines for managing the life cycle of patches to packages. Each project/package maintainer is free to adopt their own policy regarding how strictly they require submissions to adhere to these guidelines, so non-conforming submitrequests will be tolerated to different degrees based on the context.

Is that OK?

Yes, that essentially reflects what is being practiced. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org