[opensuse-packaging] Packaging Guideline enforcement
Dear Factory contributors and packagers, As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be. Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS). A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... And the Factory Review team also prefers to see complying submissions to having to reject SRs... reject is not fun for anybody! Looking forward to many more SRs to accept! Dominique / DimStar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 29/08/12 08:42, Dominique Leuenberger a.k.a DimStar wrote:
Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be.
Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches
Sad to hear this non-sensical, redundant rules are trying to be enforced without any discussion. This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history. Increasingly frustrated, Cristian. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Cristian Rodríguez <crrodriguez@opensuse.org>:
Sad to hear this non-sensical, redundant rules are trying to be enforced without any discussion.
This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history.
OBS history is a nice 'gadget', but mostly useless once it 'leaves' OBS (published repo, users install). Heck, it's even useless when SR'ing a package to any other project. the 'Update' changes are not a new request (and packages have been constantly rejected for this reason throughout the last 6 years I participate); with VERY few exceptions (some automagically updated packages, like the timezone database). Dominqiue -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/08/12 11:55, Dominique Leuenberger a.k.a DimStar escribió:
OBS history is a nice 'gadget', but mostly useless once it 'leaves' OBS (published repo, users install).
And who cares when it leaves the OBS ? I dont think that regular users care about what patches the package has.
the 'Update' changes are not a new request (and packages have been constantly rejected for this reason throughout the last 6 years I participate); with VERY few exceptions (some automagically updated packages, like the timezone database).
Yeah, Argumentum ad antiquitatem. :-) In short, unless evidence is presented, I do not believe that this will do a damn thing to improve the quality of the distribution or ease packaging in anyway. It will however cause a collosal waste of time. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 29 Aug 2012 17:52, Cristian Rodríguez <crrodriguez@...> wrote:
On 29/08/12 08:42, Dominique Leuenberger a.k.a DimStar wrote:
Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be.
Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches
Sad to hear this non-sensical, redundant rules are trying to be enforced without any discussion.
This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history.
Increasingly frustrated, Cristian.
Think of the following: A package does an upstream update (say to 2.4.5). Now the package.chances gets some new lines: ===== 2012-08-28 update to version 2.4.5 * this obsoletes OSS patch1 and patch3 * this obsoletes SLE patch4 * generic (non-distro) patches [2,5,7] are obsolete * gcc 4.5 and clang 3.1 are now fully supported. * NEW patch8 b/c of off-by-one error in main.c ===== Ask yourself: is this info in: * NEWS (from upstream) - NO * Changelog (also upstream) - NO * package.spec - Not reliable and not visible from outside And best of all you can get this info via rpm on a compiled package. Those comments in the spec-file? NO chance. Yes, care and nurturing of the .changes file is work. But it is not for naught. I'm not trying to open the door by running headfirst in it. I agree that info that is in NEWS and Changelog should at most be referenced, not repeated. -- Yamaban.
Am 29.08.2012 18:30, schrieb Yamaban:
On Wed, 29 Aug 2012 17:52, Cristian Rodríguez <crrodriguez@...> wrote:
On 29/08/12 08:42, Dominique Leuenberger a.k.a DimStar wrote:
Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be.
Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches
Sad to hear this non-sensical, redundant rules are trying to be enforced without any discussion.
This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history.
Increasingly frustrated, Cristian.
Think of the following:
A package does an upstream update (say to 2.4.5).
Now the package.chances gets some new lines: ===== 2012-08-28 update to version 2.4.5 * this obsoletes OSS patch1 and patch3 * this obsoletes SLE patch4 * generic (non-distro) patches [2,5,7] are obsolete * gcc 4.5 and clang 3.1 are now fully supported. * NEW patch8 b/c of off-by-one error in main.c =====
Ask yourself: is this info in: * NEWS (from upstream) - NO * Changelog (also upstream) - NO * package.spec - Not reliable and not visible from outside
And best of all you can get this info via rpm on a compiled package. Those comments in the spec-file? NO chance.
Yes, care and nurturing of the .changes file is work. But it is not for naught.
I'm not trying to open the door by running headfirst in it.
I agree that info that is in NEWS and Changelog should at most be referenced, not repeated.
Right. I agree to the above examples. But there have been examples where there are no changes to applied patches besides probably rebasing and the rest is probably covered in NEWS or CHANGELOG anyway and still packages were rejected. So there are cornercases where the guidelines are a bit strict. And just one addition IMHO: I _really_ want to see the package changelog before I install or update a package. This is still not possible w/o downloading and using rpm manually. Another thing I learned during the past years. The changes entries are not usable in every case. In far too many cases they reference bugs which are not accessible publically because the have SLE background. just my 2 cents, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/08/12 12:37, Wolfgang Rosenauer escribió:
And just one addition IMHO: I _really_ want to see the package changelog before I install or update a package. This is still not possible w/o downloading and using rpm manually.
AFAIK work was done to allow zypper to display the changelog , dunno if it the implementation is ready though. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/29/2012 06:37 PM, Wolfgang Rosenauer wrote:
[...] Right. I agree to the above examples. But there have been examples where there are no changes to applied patches besides probably rebasing and the rest is probably covered in NEWS or CHANGELOG anyway and still packages were rejected. So there are cornercases where the guidelines are a bit strict.
Please bring up those specific cases and let's discuss them. The review team can make errors as well and learn ;) Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/29/2012 06:30 PM, Yamaban wrote:
On Wed, 29 Aug 2012 17:52, Cristian Rodríguez <crrodriguez@...> wrote:
Now the package.chances gets some new lines: ===== 2012-08-28 update to version 2.4.5 * this obsoletes OSS patch1 and patch3 * this obsoletes SLE patch4 * generic (non-distro) patches [2,5,7] are obsolete * gcc 4.5 and clang 3.1 are now fully supported. * NEW patch8 b/c of off-by-one error in main.c =====
Ask yourself: is this info in: * NEWS (from upstream) - NO * Changelog (also upstream) - NO * package.spec - Not reliable and not visible from outside
Or ask: this is Joe TheEndUser, just a normal average enduser, really cares or knows about the OSS patch1 and patch3 or SLE patch4 These should be in the SR request or better in the checkin phase where it makes sense to the maintainer/reviewer to have such info at hand I hope Andreas Jaeger is following this thread as this is exactly what I mean with the decision process I asked couple of days ago. First someone comes and says hey this is the decision and then people start discussing the cons and pros of the decision, much like Stuttgart 21 if you know what I mean. Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia środa, 29 sierpnia 2012 11:52:08 Cristian Rodríguez pisze:
This is what I call "packaging bureaucracy", Source code changes are mentioned in the NEWS, Changelog, URL, etc of the package and patches are mentioned in the spec file, with their addition time available in the OBS history.
And what does knowing the addition time give you? Nothing. See e.g. the pathetic story of Bug 546028. TL;DR: a harmful patch with a vague non-reproducible description of a bug, the author unknown and unavailable for comment. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ideally I must agree with Cristian here. On 29 August 2012 13:42, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be.
Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches
First, the .changes entry (rpm changelog) surves two purposes:
And each purpose has a different audience. It only makes sense to split them.
- News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS).
A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed
And not extra information that the user doesn't care about but distracts him from what he really cares. OTOH sure, the OBS interface is not the best to check the history. And nobody is telling what patches are added/removed in the commit messages neither. Anyway I don't think it's too much work. The only stupid thing that really slows me is manually changing the line length when copying the NEWS file to the .changes file. There is any automated help for this? Could the line length restriction be removed?
Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will.
Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed)
More important than the .changes content IMHO is the "# PATCH-*" line. It forces people to report bugs upstream, and the reference to the bug report is priceless. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Cristian Morales Vega <reddwarf@opensuse.org> [2012-08-29 18:50]:
First, the .changes entry (rpm changelog) surves two purposes:
And each purpose has a different audience. It only makes sense to split them.
I agree, both should be kept in the metadata since it would be very useful to be able to display the major (enduser-relevant) changes via zypper/YaST before installing a new version of a package.
Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed)
More important than the .changes content IMHO is the "# PATCH-*" line. It forces people to report bugs upstream, and the reference to the bug report is priceless.
Making patch tags mandatory would be again very useful since they are easily machine-parseable and could be read and displayed in OBS in order to get a quick overview on the purpose and status of all patches of a particular package. Right now I'm using my own script to generate a HTML patch report for all of my packages. There are way too many packages which have obscure foo.dif patches without any explanation whatsoever neither inline, in the spec or changelog. This makes packages practically only maintainable by the person who created them. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 2012-08-29 at 19:41 +0200, Guido Berhoerster wrote:
Making patch tags mandatory would be again very useful since they are easily machine-parseable and could be read and displayed in OBS in order to get a quick overview on the purpose and status of all patches of a particular package. Right now I'm using my own script to generate a HTML patch report for all of my packages. There are way too many packages which have obscure foo.dif patches without any explanation whatsoever neither inline, in the spec or changelog. This makes packages practically only maintainable by the person who created them.
I do agree as well on the PATCH- Tag line (the 'forces patchers to report them upstream' is a very good reason), but also know that there is a lot of resistance against this one (there were a lot of discussions around them). But, actually, it IS already specified as mandatory on the Packaging Guide Lines, so the review team might actually be instructed to take this one serious as well.. The goal of all those attempts is, as you correctly state yourself: have the packages easy (well, easier) transferable and any other willing contributor be able to step up without a too high learning curve (see for example Xorg packages (Stefan, no intention to question your work! It IS great): since it was split in smaller chunks of '1-tarball = 1 package' I have seen several more contributors to those packages; A package that was just scary to be touched before, except the maintainer. Somehow I hope that this also helps Stefan to focus more on 'interesting' parts than running after package updates (which are often for X.* packages after all). SO, yes, for '*old*' packagers, this might be a burden which does impose change for all of us, but ALWAYS think about new contributors. Anything undocumented is likely something 'new contributors' have no chance of picking up in reasonable time, and as a consequence they will not pick it up. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/08/12 13:52, Dimstar / Dominique Leuenberger escribió:
On Wed, 2012-08-29 at 19:41 +0200, Guido Berhoerster wrote:
Making patch tags mandatory would be again very useful since they are easily machine-parseable and could be read and displayed in OBS in order to get a quick overview on the purpose and status of all patches of a particular package. Right now I'm using my own script to generate a HTML patch report for all of my packages. There are way too many packages which have obscure foo.dif patches without any explanation whatsoever neither inline, in the spec or changelog. This makes packages practically only maintainable by the person who created them.
Or someone that can actually read code ? doh !
I do agree as well on the PATCH- Tag line (the 'forces patchers to report them upstream' is a very good reason), but also know that there is a lot of resistance against this one (there were a lot of discussions around them).
There is resistance, because it is non-sense, for that we already have: - Version control systems - Inline patch headers - Bugzilla or other trackers Sending patches to upstream is a fine idea in theory, but unless you have the time and patience to register in a dozen of trackers, mailing lists and to provide a patch that will work on at least Linux, Windows, BSD, MAC OS, different kernel or library versions this only results in a burden that I personally do not want or care. I want openSUSE be better and working, that 's all I care about. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia środa, 29 sierpnia 2012 14:43:14 Cristian Rodríguez pisze:
Sending patches to upstream is a fine idea in theory, but unless you have the time and patience to register in a dozen of trackers, mailing lists and to provide a patch that will work on at least Linux, Windows, BSD, MAC OS, different kernel or library versions this only results in a burden that I personally do not want or care. I want openSUSE be better and working, that 's all I care about.
The openSUSE project cares about upstream. It is official. You are not going to make the distro better by detaching from the principles of the project. It may work that way for some time but ultimately it will backfire. IMHO, Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/08/12 14:54, Křištof Želechovski escribió:
Dnia środa, 29 sierpnia 2012 14:43:14 Cristian Rodríguez pisze:
Sending patches to upstream is a fine idea in theory, but unless you have the time and patience to register in a dozen of trackers, mailing lists and to provide a patch that will work on at least Linux, Windows, BSD, MAC OS, different kernel or library versions this only results in a burden that I personally do not want or care. I want openSUSE be better and working, that 's all I care about.
The openSUSE project cares about upstream. It is official. You are not going to make the distro better by detaching from the principles of the project. It may work that way for some time but ultimately it will backfire.
Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't) This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 2012-08-29 at 15:01 -0400, Cristian Rodríguez wrote:
Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't)
This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-)
Having patches in openSUSE is nothing bad / wrong (hint: Factory has > 10'000 at the moment!) but, as you state yourself: we do not have an army of coders: Who does take care of those 10'000 patches? Patches add an additional complexity to a package; besides the 'casual' contributor that is perfectly able to upgrade a package with a new tarball from upstream (with whom we try to have good relationships, as a project!), having all those patches requires every packager to be a crack in coding. Needless to say: excluding the casual contributors is WRONG! It makes our 'army' even smaller. We can't afford that. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/08/12 15:06, Dimstar / Dominique Leuenberger escribió:
On Wed, 2012-08-29 at 15:01 -0400, Cristian Rodríguez wrote:
Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't)
This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-)
Having patches in openSUSE is nothing bad / wrong (hint: Factory has > 10'000 at the moment!) but, as you state yourself: we do not have an army of coders: Who does take care of those 10'000 patches?
I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people. I hope we are not measuring complexity or anything important by the number of patches are we ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 2012-08-29 at 15:14 -0400, Cristian Rodríguez wrote:
I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people.
I hope we are not measuring complexity or anything important by the number of patches are we ?
Of course it's not a 'measurement', it's more of an indication that we have 10'000 files which need maintainership by openSUSE. Actually, I found that talking to upstream gives you a LOT! Even patches that we carried for > 4 years in packages are just merged in upstream git bases after a few mails; the best? I (or anybody else touching this package) will NEVER ever have to rebase the patch again, having the optional chance for an error (yes, quilt is cool... but not magic). The openSUSE Project wants to be a good downstream and have relations with our upstreams (as much as we want to maintain a healthy with 'our downstreams', like SLEx for example). Passing patches around IS one of the strength of open source.. why should we kick it with feet and not care? Because it costs us 'five minutes now and saves us 30 in two years' ? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia środa, 29 sierpnia 2012 15:14:19 Cristian Rodríguez pisze:
I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people.
There is no harm in asking but other people are in flux; they come and go, and leave something behind that, once useful, slowly transform into a mess. No offense intended, those are the laws of physics. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Aug 29, 2012 at 03:14:19PM -0400, Cristian Rodríguez wrote:
El 29/08/12 15:06, Dimstar / Dominique Leuenberger escribió:
On Wed, 2012-08-29 at 15:01 -0400, Cristian Rodríguez wrote:
Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't)
This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-)
Having patches in openSUSE is nothing bad / wrong (hint: Factory has > 10'000 at the moment!) but, as you state yourself: we do not have an army of coders: Who does take care of those 10'000 patches?
I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people.
I hope we are not measuring complexity or anything important by the number of patches are we ?
Are you actually sending your own patches upstream? The O_CLOEXEC ones at least are quite intrusive. Just wondering. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El mié 29 ago 2012 16:23:50 CLT, Marcus Meissner escribió:
On Wed, Aug 29, 2012 at 03:14:19PM -0400, Cristian Rodríguez wrote:
El 29/08/12 15:06, Dimstar / Dominique Leuenberger escribió:
On Wed, 2012-08-29 at 15:01 -0400, Cristian Rodríguez wrote:
Have I said that I want the project to "detach" from upstream ? no, what I said that forcing this rule in unpractical unless you have infinite time or a horde of developers (hint.we don't)
This BTW works perfectly fine on linux-only projects...maybe I should just devote my time to such projects only.. ;-)
Having patches in openSUSE is nothing bad / wrong (hint: Factory has > 10'000 at the moment!) but, as you state yourself: we do not have an army of coders: Who does take care of those 10'000 patches?
I do care and will fix those I introduce that causes bugs or regressions, I believe it is fair to ask the same for other people.
I hope we are not measuring complexity or anything important by the number of patches are we ?
Are you actually sending your own patches upstream? The O_CLOEXEC ones at least are quite intrusive.
Just wondering.
Ciao, Marcus
To linux-only projects, directly, however to multi-os projects most are not, I dont have time to write the ugly and likely moire buggy wrappers that some projects use, in which O_CLOEXEC is tested at compile time and at runtime. If you think there is a bug let me to know I will fix them. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 29 August 2012 22:55, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El mié 29 ago 2012 16:23:50 CLT, Marcus Meissner escribió:
Are you actually sending your own patches upstream? The O_CLOEXEC ones at least are quite intrusive.
Just wondering.
Ciao, Marcus
To linux-only projects, directly, however to multi-os projects most are not, I dont have time to write the ugly and likely moire buggy wrappers that some projects use, in which O_CLOEXEC is tested at compile time and at runtime.
If you think there is a bug let me to know I will fix them.
Just to be sure. You didn't send them to libpcap and/or sox, true? Otherwise, do you have any link to a bugtracker so I can see upstream's feedback? Both are outdated in Factory and the patch doesn't apply cleanly any more to the latest releases (which are 3 and 7 months old). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/29/2012 08:43 PM, Cristian Rodríguez wrote:
[...] Sending patches to upstream is a fine idea in theory, but unless you have the time and patience to register in a dozen of trackers, mailing lists and to provide a patch that will work on at least Linux, Windows, BSD, MAC OS, different kernel or library versions this only results in a burden that I personally do not want or care. I want openSUSE be better and working, that 's all I care about.
Sending patches upstream is really important - I believe it lowers the packagers work in the long run if patches are upstream. Looking at glibc and what hazzle it was for me to update to 2.15 and now after upstreaming a lot of patches, the update to 2.16 was rather smooth on the packaging side. Upstreaming a patch is work but it also means that an additional review happens. Remember the Debian openssl patch that introduced a serious problem? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Aug 29, 2012 at 05:50:12PM +0100, Cristian Morales Vega wrote:
On 29 August 2012 13:42, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed)
More important than the .changes content IMHO is the "# PATCH-*" line. It forces people to report bugs upstream, and the reference to the bug report is priceless.
I don't see how you can *force* people to do something with this. It just means that the work done in the devel packages will stay there and not go into Factory. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 12:05:43PM +0200, Michael Schroeder wrote:
On Wed, Aug 29, 2012 at 05:50:12PM +0100, Cristian Morales Vega wrote:
On 29 August 2012 13:42, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed)
More important than the .changes content IMHO is the "# PATCH-*" line. It forces people to report bugs upstream, and the reference to the bug report is priceless.
I don't see how you can *force* people to do something with this. It just means that the work done in the devel packages will stay there and not go into Factory.
Right. I will not resubmit packages declined for missing patch tag. Petr
Quoting pgajdos@suse.cz:
On Thu, Aug 30, 2012 at 12:05:43PM +0200, Michael Schroeder wrote:
I don't see how you can *force* people to do something with this. It just means that the work done in the devel packages will stay there and not go into Factory.
Right. I will not resubmit packages declined for missing patch tag.
That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach? More correct would actually be that YOU as prj devel reviewer decline it BEFORE submitting to Factory.. openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult.. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach?
More correct would actually be that YOU as prj devel reviewer decline it BEFORE submitting to Factory..
openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult.. let us start from saying I find the rules a on changes a little bit annoying, as they tend to duplicate what is already available and easy to be found by any curious user but that is just a simple annoyance for me...
quite few people react against this enforcement as it seems imposed in a very unilateral way, rather than discussed, and I agree with them... I am not an adept of democracy or mobocracy but I hate dictates in equal measure... We shall have a mature discussion on the process before trying to dictate a solution... The main problem we have with packaging is getting things accepted in devel projects and then pushed to factory... Why is that... if it is because of missing changes or tags for patches let us do become pedantic about the form of .spec files... but I am afraid that other are the reasons that the distro tends to be in a state with out of date packages... imagine keeping up to date the changes in all the texlive packages... Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Alin M Elena <alinm.elena@gmail.com> [2012-08-30 12:57]:
That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach?
More correct would actually be that YOU as prj devel reviewer decline it BEFORE submitting to Factory..
openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult.. let us start from saying I find the rules a on changes a little bit annoying, as they tend to duplicate what is already available and easy to be found by any curious user but that is just a simple annoyance for me...
quite few people react against this enforcement as it seems imposed in a very unilateral way, rather than discussed, and I agree with them...
I am not an adept of democracy or mobocracy but I hate dictates in equal measure...
We shall have a mature discussion on the process before trying to dictate a solution... The main problem we have with packaging is getting things accepted in devel projects and then pushed to factory... Why is that... if it is because of missing changes or tags for patches let us do become pedantic about the form of .spec files... but I am afraid that other are the reasons that the distro tends to be in a state with out of date packages...
In a several cases I'd like to have updated outdated packages but the number of non-upstreamed patches without any description would have meant the I'd possibly spend hours getting familiar with the code base and patches before I could rebase them. The "packaging bureaucracy" is a non-argument, the actual form of patch metatdata (whether inline or tags) is not that important either but adding a one-line description about the purpose of a patch and sending it upstream is not that much work. Not doing it hurts the project more than in the long run than the short term gain of saving a few minutes of a contributor. And that's also the reason why this is a policy for other distributions e.g. Debian [1] or Fedora [2]. 1. http://dep.debian.net/deps/dep3/ 2. http://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_a... -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia czwartek, 30 sierpnia 2012 13:57:55 Guido Berhoerster pisze:
In a several cases I'd like to have updated outdated packages but the number of non-upstreamed patches without any description would have meant the I'd possibly spend hours getting familiar with the code base and patches before I could rebase them.
It would be better if the patch description were in the patch itself, e.g. as a comment added to the file being patched. BTW, I am currently struggling with man-db-2.4.3-firefox.dif. I am not sure it important/necessary and I am sure it is not the right way to wait for Firefox. IMHO, Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 7:27 AM, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult..
Now now... is this mini-flamewar really necessary? A patch tag isn't "extremely difficult", especially since I've been asked to produce them in the past, and it takes the whole 5 minutes each one in this thread has wasted discussing it. Although I agree reporting things upstream is good, the guidelines do not force you to. I quote: """ If there are related bugs in Novell or other bugzillas, please add them, it will help us to get more accurate information. If there are two or more available then it's preferable to list both (or more). """ And I've seen patch tags without bug numbers accepted. So... if adding a comment line summarizing why you need the patch is "extremely difficult", someone's being picky. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Claudio Freire <klaussfreire@gmail.com>:
On Thu, Aug 30, 2012 at 7:27 AM, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult..
Now now... is this mini-flamewar really necessary?
A patch tag isn't "extremely difficult", especially since I've been asked to produce them in the past, and it takes the whole 5 minutes each one in this thread has wasted discussing it.
Now you take me out of context :) I don't consider ADDING the line a difficulty (at all!), but actually a help for new contributors, when they look in a package and want to do work (like a simple update). Not having the package properly documented is the 'extremely difficult' burden. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 8:53 AM, Dominique Leuenberger a.k.a DimStar <DimStar@opensuse.org> wrote:
openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult..
Now now... is this mini-flamewar really necessary?
A patch tag isn't "extremely difficult", especially since I've been asked to produce them in the past, and it takes the whole 5 minutes each one in this thread has wasted discussing it.
Now you take me out of context :) I don't consider ADDING the line a difficulty (at all!), but actually a help for new contributors, when they look in a package and want to do work (like a simple update).
Not having the package properly documented is the 'extremely difficult' burden.
Lol, of course, you being the OP and all ;-) But the entire thread is saying the opposite! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Claudio Freire (klaussfreire@gmail.com) [20120830 13:34]:
And I've seen patch tags without bug numbers accepted.
At least for those someone fluent in python should write a test for rpmlint. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Philipp Thomas <pth@suse.de>:
* Claudio Freire (klaussfreire@gmail.com) [20120830 13:34]:
And I've seen patch tags without bug numbers accepted.
At least for those someone fluent in python should write a test for rpmlint.
As currently the Patch tag line is a 'encouragement' but not strictly enforced by all devel projects (and Factory for the matter), rpmlint will bite back badly here or you'll just end up with accepted warnings. Also, rpmlint can't really see if the patch is NEW (and as such should fall under the new guideline of patching, which is nor enforced yet), or not. Raising warnings (or even errors) on all 'wrongly annotated' patches will give you a warning on > 11'000 patches currently (of which only a small fraction has a tag line at all!) Also, the patch tagging / annotation has seen a lot of discussion in earlier threads. I know of currently three ways that are actively being used (with their pros and cons): - No tagging at all - 1 - Line tagging in the .spec file, next to the Patch<n>: entry - Full annotation in the .patch / .diff file. Projects that use the 1-line tagging do not exclude to have full annotation in the .patch file neither of course (often the case with patches extracted from a VCS / git). I personally prefer the 1-line tags (on any update of a package, I usually skim through the .spec anyway), but am fine with full descriptive .patch files (seen some 'rebase' work loosing the info though: so more care needs to be taken there). Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia piątek, 31 sierpnia 2012 13:55:06 Dominique Leuenberger a.k.a DimStar pisze:
Also, the patch tagging / annotation has seen a lot of discussion in earlier threads. I know of currently three ways that are actively being used (with their pros and cons): - No tagging at all - 1 - Line tagging in the .spec file, next to the Patch<n>: entry
That should be encouraged by the Web editor before it is imposed as a requirement.
- Full annotation in the .patch / .diff file.
I do not know how to do it with Kompare but you can make a source file comment instead. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
2012/9/1 Křištof Želechovski <yecril71pl@gmail.com>:
Dnia piątek, 31 sierpnia 2012 13:55:06 Dominique Leuenberger a.k.a DimStar pisze:
Also, the patch tagging / annotation has seen a lot of discussion in earlier threads. I know of currently three ways that are actively being used (with their pros and cons): - No tagging at all - 1 - Line tagging in the .spec file, next to the Patch<n>: entry
That should be encouraged by the Web editor before it is imposed as a requirement.
The web editor is a pile of junk and should become un-available; It's not the first time I see people using the web editor to make packages, and this raises one question... Do the vast majority of those people actually test the packages ? :) I've actually found packagers with no openSUSE system installed maintaining packages on OBS...
- Full annotation in the .patch / .diff file.
I do not know how to do it with Kompare but you can make a source file comment instead.
Packaging has nothing to do with KDE specific software; Not everyone uses KDE... in most cases patches should be properly formed through git or svndiff... the sad truth is that no one gives a damn... Comenting the patches on the spec is actually nice and should be how it should work for everyone else; I wonder if professionals do question the rules or if they just follow them (imagine that your software is actually under quality management process that demands absurd things). So all this communism stuff, is really not wanted by many of us. Packaging is about DISCIPLINE, if people can't obbey to it we have chaos, anarchy and turmoil... We have our release team pounded with extra work, we break our workflow and everyone suffers from it.
From my perspective openSUSE should demand superior quality packaging from everyone, specially from the 'professionals' and not support the easy way out. But let me guess... we don't give a damn about quality ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia sobota, 1 września 2012 17:06:55 Nelson Marques pisze:
2012/9/1 Křištof Želechovski <yecril71pl@gmail.com>:
Dnia piątek, 31 sierpnia 2012 13:55:06 Dominique Leuenberger a.k.a DimStar> pisze:
Also, the patch tagging / annotation has seen a lot of discussion in earlier threads. I know of currently three ways that are actively being used (with their pros and cons): - No tagging at all - 1 - Line tagging in the .spec file, next to the Patch<n>: entry
That should be encouraged by the Web editor before it is imposed as a requirement.
The web editor is a pile of junk and should become un-available; It's not the first time I see people using the web editor to make packages, and this raises one question... Do the vast majority of those people actually test the packages ? :)
Speaking for myself, each time I repackage something it because the openSUSE package is missing some stuff I need. I do not do it just for the fun of it.
I've actually found packagers with no openSUSE system installed maintaining packages on OBS...
- Full annotation in the .patch / .diff file.
I do not know how to do it with Kompare but you can make a source file comment instead.
Packaging has nothing to do with KDE specific software; Not everyone uses KDE... in most cases patches should be properly formed through git or svndiff... the sad truth is that no one gives a damn...
I use KDE, so KDE-specific software is what I use. Please explain your thoughts on the wiki. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Claudio Freire <klaussfreire@gmail.com>:
And I've seen patch tags without bug numbers accepted.
This can be well accepted, in those situations: - The patch came from an upstream VCS; not all commits are done based on bugs; but this should be mentioned in the comment, something along the lines 'taken from upstream git' - The patch adjusts 'default settings': would be nice to have a feature / bug for tracking, but in reality they are often not arriving like this (think adding default RSS feeds to a news reader) - Upstream is dead; Note: up to now, patch tagging is not enforced in Factory (by the factory review team). There are various devel projects which do require it though. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 12:27:21PM +0200, Dominique Leuenberger a.k.a DimStar wrote:
That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach?
I think I document changes just enough (see my today submissions in regard to libpng14->libpng15 change for example, plotutils, nvidia-texture-tools, tuxpaint, tvtime). But really don't know why I should document oneliner buffer-overflow.patch speaking for itself on 10(dec) places in strictly given way. And I am proud I have freedom to choose level of documentation. Of course I have _tried_ to upstream it.
openSUSE is collaborativ work. There is REALLY no reason to make work for potential new contributors extremely difficult..
I hope you want to aply this rule only for newly created patches, not existing ones. Petr
Quoting pgajdos@suse.cz:
I hope you want to aply this rule only for newly created patches, not existing ones.
Yes, of course! I'd not ask anybody to go and find ANY rational behind the 11'000 patches in openSUSE Factory. Please don't waste your time on trying to figure out what some of the patches do. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 30/08/12 06:27, Dominique Leuenberger a.k.a DimStar escribió:
Quoting pgajdos@suse.cz:
On Thu, Aug 30, 2012 at 12:05:43PM +0200, Michael Schroeder wrote:
I don't see how you can *force* people to do something with this. It just means that the work done in the devel packages will stay there and not go into Factory.
Right. I will not resubmit packages declined for missing patch tag.
That's one approach... it will mean that your packages will fade out and be deleted frmo Factory due to no longer building... is THAT in line with what you want to reach?
Yeah, that 's one approach, insane rules have to: - Be resisted and challenged or - You spend your time in something else in the first place Im considering option 2 , because option 1 seems like talking to the brick wall. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 30 Aug 2012 12:37:20 -0400 Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
Im considering option 2 , because option 1 seems like talking to the brick wall.
(Can't resist :) Deja vu. Do you recall systemd and some other discussions? It is just that you are now in opposition. The idea to use some description, useful for everybody, but also to those that don't speak C, C++, Java, Python etc, is not bad idea. It will allow to have first level packagers (like first level support) , that work per script (written instructions), not understanding the code too much, and then when problems can't be solved without looking at the code, issue is escalated to you and people like you. Wouldn't that make your life more interesting? More coding, more real debugging, instead of boring repetitive tasks. Or, I don't get what you like? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 30/08/12 06:23, pgajdos@suse.cz wrote:
Right. I will not resubmit packages declined for missing patch tag.
Me neither, In fact I am considering not submitting anything at all anymore. It is very sad that politics and bureaucracy have taken over. This new policies are absolutely ridiculous and want nothing to do with it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sun, 2012-10-28 at 14:01 -0300, Cristian Rodríguez wrote:
On 30/08/12 06:23, pgajdos@suse.cz wrote:
Right. I will not resubmit packages declined for missing patch tag.
Me neither, In fact I am considering not submitting anything at all anymore.
It is very sad that politics and bureaucracy have taken over.
This new policies are absolutely ridiculous and want nothing to do with it.
Free software should not be confused with Anarchy... it's not that our packaging guidelines are really tough... and sorry to say: 'packaging is a job to be taken serious' - which comes with maintainership. It's not the thing to be done 'next to the distribution'.. it is actually the task that forms and shapes the distribution (of course, together with the tarballs, which are even more important) And just on the topic: the patch tag has, so far, NEVER been a reason for a reject in Factory (can be handled different in different devel projects... some are a bit stricter on that). And just once more, 'slowly' for everybody to read: the documentation of patches is useful for a few aspects: - Lifecycle of a patch gives clear indication for other packagers when a patch was added and removed.. so it's always clear they are conscious about them.. I've seen a lot of patches 'dropped' (by just putting a comment sign) and nobody knew why or what.. until a bug came in and then oh wonder: that patch was just commented because it did not apply.. and nobody new... great 'team work' (which, by the way, could be seen as a different word for 'community') I for myself prefer having packagers submitting their stuff that take it serious, that are aware of what they are doing and that do not just consider this a playground. Otherwise, try to submit any 'hack patches' to any serious upstream project... best, make a 200 line patch for the kernel without any 'documentation' of why for what it is... I bet it won't be applied (git format-patch does produce some documentation based on your commit log.. that does not count here... I'd really challenge you to just send a "git diff" over). Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El dom 28 oct 2012 14:24:00 CLST, Dimstar / Dominique Leuenberger escribió:
Free software should not be confused with Anarchy... it's not that our packaging guidelines are really tough... and sorry to say: 'packaging is a job to be taken serious' - which comes with maintainership.
HUh ? I have been doing this for the past 5 years, no need to tell me anything like that.
- Lifecycle of a patch gives clear indication for other packagers when a patch was added and removed..
That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks. It is so absurd that complyng with this rules takes more time than actually fixing a problem. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sun, 2012-10-28 at 14:38 -0300, Cristian Rodríguez wrote:
That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks.
I know you know better than that Christian.. BUT: OBS is not really a VCS... you know, I know.. everybody knows.. let's stop claiming the opposite.
It is so absurd that complyng with this rules takes more time than actually fixing a problem.
Packaging is a task of it's own... and, considering that I can update an entire gnome stack in < 2 days (which is ~ 200 packages!) I don't think those 'rules' are that difficult to honor... in fact, they just ask you to write down what you do... I know, documentation is NOT exactly what devs like.. but without it, we're just lost. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Sonntag, 28. Oktober 2012, 18:41:37 schrieb Dimstar / Dominique Leuenberger:
On Sun, 2012-10-28 at 14:38 -0300, Cristian Rodríguez wrote:
That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks.
I know you know better than that Christian.. BUT: OBS is not really a VCS... you know, I know.. everybody knows.. let's stop claiming the opposite.
It is a VCS, but it is not suitable for application development just for packaging ;) -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 10/28/2012 06:41 PM, Dimstar / Dominique Leuenberger wrote:
On Sun, 2012-10-28 at 14:38 -0300, Cristian Rodríguez wrote:
That information should be retrived from a different source, just like upstream changelogs. either from the SCM history, rpm metadata or something automated and yet to be developed, where the OBS knows a new patch has been added and stores such information for everybody to see, without bothering packages with meaningless tasks.
The OBS knows but your other fellow packagers have no clue what that patch is for if there is no patch tag.
I know you know better than that Christian.. BUT: OBS is not really a VCS... you know, I know.. everybody knows.. let's stop claiming the opposite.
It is so absurd that complyng with this rules takes more time than actually fixing a problem.
Packaging is a task of it's own... and, considering that I can update an entire gnome stack in < 2 days (which is ~ 200 packages!) I don't think those 'rules' are that difficult to honor... in fact, they just ask you to write down what you do... I know, documentation is NOT exactly what devs like.. but without it, we're just lost.
I would actually advocate that even in devel projects of packages that are part of factory. if the submitted package has patches and the patches are not neither tagged in the spec, nor have a header that briefly describes the purpose of the patch should be declined until they meet the patching guidelines. Because if I as a contributor would like to update the package either to a newer version or fixing some broken build; if there are no patch tags in the spec or no header in the patch, I am spending time to figure out what does that patch do and in newer versions why the patch fails. In my opinion following patch guidelines is not bureaucracy nor absurd but courtesy towards other contributors. Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia niedziela, 28 października 2012 18:24:00 Dimstar / Dominique Leuenberger pisze:
consider this a playground. Otherwise, try to submit any 'hack patches' to any serious upstream project... best, make a 200 line patch for the kernel without any 'documentation' of why for what it is... I bet it
Patches should be extensively commented in the code that constitutes the patch. It is better for the maintainer than a patch tag or a changes entry. The only advantage of using the patch tag is that it can be processed by tools without knowledge discovery in running text. Of course, this also implies that the code itself should be explained in comments, which is not the case more often than not. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia niedziela, 28 października 2012 14:01:04 Cristian Rodríguez pisze:
On 30/08/12 06:23, pgajdos@suse.cz wrote:
Right. I will not resubmit packages declined for missing patch tag.
Me neither, In fact I am considering not submitting anything at all anymore.
Submitting packages that get rejected does have sense, in that the mainainers know that the problem has been fixed and can apply the required procedures themselves. This is what happened to the Polish translation of the openSUSE license agreement: accepted with a problem, the workaround rejected but adapted by the maintainer without any further contribution on my part. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 2012-08-29 14:42, Dominique Leuenberger a.k.a DimStar wrote:
Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle
Most important IMHO is a patch description, which more often than not is lacking. PATCH-*-* tells you something, but not much more than where it goes, maybe a bnc number. Picking out a completely random example, OFED:Factory/librdmacm has a librdmacm-need_pthread.patch that simply adds -lpthread to the linker line. *Why* was this patch made? PATCH-FIX-UPSTREAM, yeah well, _obviously_ it fixes something, or the patch would not be there. What's missing is what error it actually attempts to fix. This helps checking in the future whether a patch is still needed, for example. Patches should be required to carry a description, akin to the what (many, but not all of,) kernel-source/patches.*.tar.bz2#*/* do: # btrfs-8084-do-not-update-atime-for-RO-snapshots.patch From: David Sterba <dsterba@suse.cz> Date: Fri, 1 Jun 2012 12:41:10 +0200 Patch-mainline: never References: FATE#306586 Subject: [PATCH] btrfs: do not update atime for RO snapshots "if a snapshot was created with -r and thus is read only, accessing files in it will update the atime. I would expect that atime is not updated on ro snapshots." This is a workaround, does not break kabi. Upcoming upstream patches extend file operations with filesystem-specific ->update_time where this check belongs. kernel-source also provides a counter-example right next to it: # btrfs-use-correct-device-for-maps.patch From: David Sterba <dsterba@suse.cz> Date: Mon, 02 Jan 2012 13:40:28 +0100 Subject: [PATCH] btrfs: use correct device for maps Reference: bnc#672923 bnc#769545 Patch-mainline: no Signed-off-by: David Sterba <dsterba@suse.cz> --- Index: linux-3.1-openSUSE-12.1/fs/proc/task_mmu.c =================================================================== --- linux-3.1-openSUSE-12.1.orig/fs/proc/task_mmu.c +++ linux-3.1-openSUSE-12.1/fs/proc/task_mmu.c [...] Again, what is the problem that makes the patch necessary? *That* are the things and info patches should convey. PATCH-*-* is mostly a copy of info found in Patch-mainline:/Upstream:, Reference:-like lines already. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 12:27 AM, Jan Engelhardt wrote:
Patches should be required to carry a description, akin to the what (many, but not all of,) kernel-source/patches.*.tar.bz2#*/* do:
ACK. That also holds for grub2 for some time. And it should be the case for all project with more than one simple patch. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQP88EAAoJEL0lsQQGtHBJdcQP/jv35/vwvbEY5q/6NETrij6m Vy+P3OXdjtXt6SvpYww3hr3S+fq3H/bRBj7CbQynL6IEUkv79hYQq3yHjy991reI 20lX1i8ZeRpLVv06/fREW4Lay0ZuB5m6UKyV0cRVrPrPw4OXN6weyfF2KwxnA9Un gR80iGQ6urKWgRKKPdAR5QakFA19p6W05RH955lr/lKHVwQOrt3pFUaz2YqdvJ1N 0h+1pk3W010tE5NSW43N+Nbyha1XQT2ED5CZKUFvwN5IKRxJW1NjstKVvN1qKUzH Z9IZJ1hJNqe3LOpGqrKSRhwMle3XTLb2BIgsYvL2mtr+x9VCd3+BqZueP6XOhqC4 s0Y+fNomQoYr7FtxolrKSqKHhmK56OdOvo2B30M82Y37iJyX/flaPV3NevIJKv37 QRNbZOZHiMk/yHicYe7vN5G4J+V9sbZwS/WEVA4bjU5ZrvLChlSKsRYZMsM9vP9B jhhqHrSQD0iiAiXbfJ8oslmPUJ7kvBPRdBHx4Ic+HP9zOtkws9I/gh9ZQBI9QjSw 6q9szJhDYeeffsUChFRmM+992EBvfQw0iJRxoMEswVx4IFVy+opOY01SEDThdNZH LFvFvxzxMdSaERv7cgVa6leFRk4Fe4VNwhA+uTpiarhW4NUlSBf70+L0bLzJXs+u +naq9Vs9SR0dRpzDGplP =Q0IZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2012-08-30 22:37, Jiri Slaby wrote:
On 08/30/2012 12:27 AM, Jan Engelhardt wrote:
Patches should be required to carry a description, akin to the what (many, but not all of,) kernel-source/patches.*.tar.bz2#*/* do:
ACK. That also holds for grub2 for some time. And it should be the case for all project with more than one simple patch.
I now edited the wiki, because it just completely hurts to see evermore info added to .spec files where they are totally out of place. (And longer than 80 chars, to boot.) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting pgajdos@suse.cz:
On Wed, Aug 29, 2012 at 02:42:51PM +0200, Dominique Leuenberger a.k.a DimStar wrote:
- .Changes entries
Can I do small statistics here?
Please do rpm -q --changelog man-pages
Do you like changelog entries before update to 3.34 or after update to 3.33?
Honestly? BOTH are nonsense. Try to settle somewhere in between. My initial mail said about .changes: ************************************ A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. "some buzz" does not mean every single line from a ChangeLog needs to be copied.. Very often, the 'right' balance for an update can be found in an Announcement (where upstream usually also tries to explain to their users why they believe it's worthy to update). For your example of man-pages a .changes like this for 3.41 might have been more suitable: + Update to version 3.41: - A new get_robust_list(2) page documents the get_robust_list() and set_robust_list() system calls. - Three new pages ? mallinfo(3), malloc_info(3), and malloc_stats(3) ? document various interfaces used to monitor the state of the malloc implementation. - The madvise(2) page adds documentation of the MADV_DONTDUMP and MADV_DODUMP operations Dominique (I did not look at any specifics for spec changes that would require documentation.. but I trust that was outside of your question anyway). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 02:06:25PM +0200, Dominique Leuenberger a.k.a DimStar wrote:
+ Update to version 3.41: - A new get_robust_list(2) page documents the get_robust_list() and set_robust_list() system calls. - Three new pages ? mallinfo(3), malloc_info(3), and malloc_stats(3) ? document various interfaces used to monitor the state of the malloc implementation. - The madvise(2) page adds documentation of the MADV_DONTDUMP and MADV_DODUMP operations
Ok, I will use head -n 15 for it :-]. Petr
Quoting pgajdos@suse.cz:
On Thu, Aug 30, 2012 at 02:06:25PM +0200, Dominique Leuenberger a.k.a Ok, I will use head -n 15 for it :-].
that's one option.. or really just reading the release announcements might do an even better trick: http://linux-man-pages.blogspot.nl/2012/05/man-pages-341-is-released.html (btw: sometimes not just copy-pasting that stuff but actually reading and understanding it, can give you as a packager also hints about new / obsoleted optional BuildRequires. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 02:19:38PM +0200, Dominique Leuenberger a.k.a DimStar wrote:
that's one option.. or really just reading the release announcements might do an even better trick: http://linux-man-pages.blogspot.nl/2012/05/man-pages-341-is-released.html
(btw: sometimes not just copy-pasting that stuff but actually reading and understanding it, can give you as a packager also hints about new / obsoleted optional BuildRequires.
Wow, good shot. Hats off, Petr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 01:57 PM, pgajdos@suse.cz wrote:
On Wed, Aug 29, 2012 at 02:42:51PM +0200, Dominique Leuenberger a.k.a DimStar wrote:
- .Changes entries
Can I do small statistics here?
Please do rpm -q --changelog man-pages
Do you like changelog entries before update to 3.34 or after update to 3.33?
For me: before. 1) who reads changelogs before update? Or whenever? 2) mostly I have no clue what everything changed in a particular version except some main points. 3) sometimes the changes are so intrusive, that it would be enough for a phd thesis. 4) many projects have ChangeLog file which is often packaged. Instead, I would prefer rpm changelog generated from osc log, where some minimal info would be required (and bug numbers requisite). And also the rpm proper should contain an osc rev. Similarly to kernel RPMs. (But we generate the log from git and have rev of git commit.) regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQP88UAAoJEL0lsQQGtHBJs9UQALNF44S5zSVKhNilWSBF+6ma F/8b06sm+GB+TWhqBoj6qHJQxBMeEEylWlbRqj34Y+5ISv0OooGqgQjKUIFbIraL cT7BNPRdViS3F+UHgZinNA+r8L0NIOt2cmyCciUX2sUuOMlJfG/TGn0YEGwjnypC OmhEoYEpqt3dSaK82cT1qImmG4VtUtf8dAg+Mu2uDr0U6Rc5L9aDWu/cymgu4m1G scK5K/19LmK2rVBnMEvGF186t6WMfQtfwz0jypvDD3DC5qFk/n5vIhuLlVknahqx mQfQWpo66rVRtsaZMaOD4Jv4Qn3r7K0EjGHySB/MQzcVx8nU0ZaG+0ZicXsMO9C9 LHPAQFQz4nfKxf7a4v9GicA80FJ1t5kHq1sv/V0W98KsC0w8CxrmQ4cTE3jRVbAr lxnWTkCrZroSjJlMzRjoZ4ipJafkMaK8z5nCHkcsLeCFkbXCs9mb9fXDn8Pk1dL2 C1vRYQYMWU+ntezut3YNQy6jJ0V9pvXQK8mUvB+Wb7doeyrWSWfxFoJrvkMNVSuE NqP6b/lNC3QFAWyjmWa9SdJh+qooJX4b+5CJT+3Is9uFZrcN2d0TiPjFoMh5Kpo2 /+jjeYCimfTwbHLBlhEtbVjgehzpo6f9BT4w9EQ9rXCLf5JFBMa5VVNGv/71Kx5j mv3eZP2AMcM4Mei+aBiB =+KHF -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 10:37:40PM +0200, Jiri Slaby wrote:
Instead, I would prefer rpm changelog generated from osc log, where some minimal info would be required (and bug numbers requisite).
Oh god, that's like saying you want to generate the NEWS file from the git commit log.
And also the rpm proper should contain an osc rev.
It has the 'srcmd5', a rev doesn't exist for linked packages. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 11:43 AM, Michael Schroeder wrote:
On Thu, Aug 30, 2012 at 10:37:40PM +0200, Jiri Slaby wrote:
Instead, I would prefer rpm changelog generated from osc log, where some minimal info would be required (and bug numbers requisite).
Oh god, that's like saying you want to generate the NEWS file from the git commit log.
I meant nothing less than: rpm -q --changelog kernel-desktop That kind of thing only makes sense. This is actually a changelog. The only valid thing in RPM changelog is information about * version update * patch removal/addition * spec file change * maybe some info of other changes Other packagers' written stories about added/removed features are useless for the reasons mentioned earlier. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQLC8AAoJEL0lsQQGtHBJ8uMP/0e0tbW9ZjORZTM+ACh91n+6 cabS1wj5uJ9ZSISOUjI2sv8AfbPk7DgbJ0mt/HRBlHaMthBtQPray+ybilqR2qGI yBthkqNry27uskZD1ZP9kfDdRuMY65YW75b6zNDWmIKSYqoGtjhukuCKGXsFnWMc JRt2KfZfs1z6CeKcxRaGygRpzOQNTF6JMxPEVf61/5s6XLU70UfAtR7KI0sAo+cK inq6/zJDKWepNF+ds3R4mrIxJAMnyaI/aEe9UMQzt3eJPXZMdeHaRXkHZwzPQRA1 vlDWUQVGcOoabXMgNNSmUs+kCRDWddRQFxpaMvZRvqsF7ctxY1CsLYzEZnlr+lmT z4HQXE2NJVCYUDD8uVuFzeHtO+l9UjRTehZljK8W06uRRz0jvbmCaWf7LT0FxkBK 6FoFqpUcXho3CbsBZ96NsJylrceK1BpqqxZE7Xi6Z+E531xAvDP5obHxtg13mB6/ DRl8HYoPkZHT8DqZG8pFiJ8kyOrZi9B2sUHFGKSxZ2aXHwHFr/pE8770tL8nDGtG QxNY3BhjNC/C16tlC2AHE4YxzPv2YgAVYBbVy7hoYlDM9lFE5nl456ZmKhg4srX+ nJ37n0bLhZPtlJzQ9mZaYCGYahqUoSjTdLaZvrCFr7bUIDzFtHLI+O5hUqKgY7IL nDixySK8ndp8rHAjkgla =UmQV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 9:40 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Oh god, that's like saying you want to generate the NEWS file from the git commit log.
I meant nothing less than: rpm -q --changelog kernel-desktop
That kind of thing only makes sense. This is actually a changelog.
That's not really true. That only makes sense when the git/svn/vcs log indeed contains descriptive entries. OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline, for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good. On the other hand, OBS vcs changelogs also contain SR descriptions when SRs are accepted. That would in fact make for a good changelog. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 04:09 PM, Claudio Freire wrote:
On Fri, Aug 31, 2012 at 9:40 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Oh god, that's like saying you want to generate the NEWS file from the git commit log.
I meant nothing less than: rpm -q --changelog kernel-desktop
That kind of thing only makes sense. This is actually a changelog.
That's not really true.
That only makes sense when the git/svn/vcs log indeed contains descriptive entries.
OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline,
Well, if somebody commits via web-ui, I doubt they change the .changes file. The discipline is needed in both separate-.changes and osc-log cases at the very same level.
for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good.
Mistakes happen, even in the kernel log where we cannot undo them. This is the case in any vcs maintained project. And we live with that, your argument looks to be odd in this case.
On the other hand, OBS vcs changelogs also contain SR descriptions when SRs are accepted. That would in fact make for a good changelog.
Yes, one more supporting argument. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQMdyAAoJEL0lsQQGtHBJ+LUP/3sjhOa9w2oWNi+SM/hhYl5K RhEbFLFc98w/48iRGrn2NohkFzmvk9zqFZmc6SbWsTlh8DF9sdqOgdyNTWPAqHHI 025h7jdZ0MpvBNG5ftn+Bg2vbNkxsljU2YNJP8YtAVlrpgP+/gjISYKu4IL7XWM+ +7ilYBV7VnDrlJsKU3gSD1llXaKeQwmYgxEyDp3XWQmpPdDxJjyAZ+E9JsDO9o2/ gMis3xtFitZKC1HnltZNAq5foVK0UR1P9mPd03GsSkZY5t52JrTJ9MIz5iqhNcyk kP6JyBMPFlhY8qzhJwtxSKrvBcDwMWVooxFL9Y/2zsHKInWydo9cItuWncAFV8Lr mclK+jFMgcXPlK9rSrPK7jshva1ssewX8ZATUS+jGkes/TQt806HcWuq80tfYczw 5aL5RwOamnpmlAtjnFmHUVueZyuslFcasaKr0O8BE2YpprZ2CNjD225ZR39CxzXO N4myI2KJ8uo7PpbpWuIaqXRtj4mmq5sBxXIm8QhpmO3BoXA6LuzJHkAyu8gYKuvS e+MSwMf5WV3m80fqAzTR/pJNJsgb+eJSBUbRq0y8kBoMB1ZeAFUGavxZAJ7fXFDV diIKVZbAKr/bP/3Fw0kS+vmqMCom1nSsNDiFf59IgNf7RkqUrEOH48DEMLUhLGmd JobZhxLUCKVeZMmuMIzL =I2hs -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 11:17 AM, Jiri Slaby <jslaby@suse.cz> wrote:
OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline,
Well, if somebody commits via web-ui, I doubt they change the .changes file. The discipline is needed in both separate-.changes and osc-log cases at the very same level.
There is a very neat button when editing .changes files in the web-ui, that says "add changelog template". It makes editing .changes with web-ui as easy as "osc vc". I use it when I'm "osc"ing in debian, since debian's osc doesn't support the "vc" thing. It beats "echo date -U blabla" >> blah.changes every time ;-)
for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good.
Mistakes happen, even in the kernel log where we cannot undo them. This is the case in any vcs maintained project. And we live with that, your argument looks to be odd in this case.
Interesting. And how do you handle that? How do you fix the changelog in those cases? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 04:27 PM, Claudio Freire wrote:
It beats "echo date -U blabla" >> blah.changes every time ;-)
Terrible 8-).
How do you fix the changelog in those cases?
No way. It's set in stone. We just have to live with that... regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQMpWAAoJEL0lsQQGtHBJZ/sQAKr9IX3Pl6qGxWLzPokQYs/l FDUun0ScQGWT/g48wQZKwtE90bcaiFh2hqk1Qp85Uhut562T8YhDfLb+WMGkdyvh pZuJ90OTMJgvIXUhc8BT2+Y8CKVfIvjbVIMJklWwWYbroUtzwajMDEAntWtkdF20 6S9ss/u/gF7zn9cXVDsTN1qh8bZrbmvYN4No4SYiIJNspbZRXqmLl37cIL++8YZ6 JzVw+7oRCtO8zZpS4aiCZ0KNOj6wfpgZObaiZVTEu21QEuSpUJIclTU2xBrBb8TW srbytoO4+vAI+PRy+3MnrvAtLpIC7QvIAlBB1MIkebTWJYePiu7Kswhtk+GttuLS XLmPagxIRKw0dmIX6e5b7DlSm99vlJEEro0vLkPyRSIpYfafik+0mPbE+Dph62+6 s6pv7xrX4N/EokB+j1I4imc6EvNSefZvlqe7DX3APTsgmrbNhIUYbtyR6BVNbfCh 2ooViCtPKH/jQz0CYJYVlKzgV6v2y4YV5lBzFmG+8o3wY/5q2TnNnzGYdjSTDz/U zcRBPXFmA7S8K11xWX4BT/SMimyafftC4pr6XvssycjNOQyD9UOy1fnkJXLkYgoY cs1m+zAgWdMEbxxsWEgT/ZAwS9INka7VuzEQ579yLSiZ5JgkFFB27PoqU11Lt9Gi 6yyDK1lQ5C40Sjns15HU =EX3I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 11:29 AM, Jiri Slaby <jslaby@suse.cz> wrote:
How do you fix the changelog in those cases?
No way. It's set in stone. We just have to live with that...
Well, maybe that works for kernel developers (ie: seasoned developers), but I don't see *all* OBS users exhibiting that amount of discipline. We could, however, do the SR comment --> .changes entry thing as an option for "request accept". On Fri, Aug 31, 2012 at 11:35 AM, Jiri Slaby <jslaby@suse.cz> wrote:
But the changelog's purpuse is to tell the user why he should install/update a package.
I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?
I do. I read them usually *after* I install updates, only because I have no easy way to read them before. Debian lets you read the changelog *before*, and almost everybody I know that uses debian reads it. Everybody I know that uses debian is tech savvy, so it's a biased sample, but it's still an important sample if you ask me. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 04:40 PM, Claudio Freire wrote:
On Fri, Aug 31, 2012 at 11:29 AM, Jiri Slaby <jslaby@suse.cz> wrote:
How do you fix the changelog in those cases?
No way. It's set in stone. We just have to live with that...
Well, maybe that works for kernel developers (ie: seasoned developers), but I don't see *all* OBS users exhibiting that amount of discipline.
We would need to teach them in any case. Either for editing .changes files or for writing osc log texts.
I do. I read them usually *after* I install updates, only because I have no easy way to read them before.
Debian lets you read the changelog *before*, and almost everybody I know that uses debian reads it.
You all do not run unstable, right? And you do not maintain multiple servers with distinct OSs, do you? And no, I'm a debian user, run debian on several servers and definitely do not have time to read changelogs, no.
Everybody I know that uses debian is tech savvy, so it's a biased sample, but it's still an important sample if you ask me.
Ok, let me ask again. What actually it gives you? Note that I'm not against *removing* changelogs. I only think that maintaining .changes files is tedious and does not really work. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQP9JAAoJEL0lsQQGtHBJWjkQALDLs0FLEjSuKb8yl2qlC/to kXlvjT1cPJVIivMsm05DDdEl0h2JnMYpQN2gR7Do82yOwiI3/9MjJYdJCmqSLkHc k3hUt943P6lYsqH8YUpheyMy2w42cWZC8KwV4FXQOqvkmeN6R0tVkkROKgGd0yK+ jyS+O5oCLeDEYrmC1MFwdowEsjuJzVqkg/XJi3wemU4l9DGAndENOCWbNlzVffYF jYrPKenWBk1hRiMLQyDTCFrn8K6D3wdFys3GUtTeF30deUwsHSbhfAscTOAy9VC4 F2WZUUJbb/g9fWI8qFDMWbO/tPvMpyiVgHKrsoxwFJQ0TtuOi0L+Xzo/iFE3a98Q Hnl8mfv4Eigvl/fGo57QP0ETjqGJp1wbm4acVKR07TEcGNh140gccdu0Pme8QrPf gTuabIMP0Gd3wg11TaHfRHRtdG2dA72Mr9WPPjHOmyy9vG+YG0dI60JtROtIO0hg updAQBrnGxrEOTQiByXlbRK24IHmBLMOwO+W4tnjBIY9yqXHOTQ7fRViHjVA6LOG hM5Uzcw5PW+ycNy99VcPf0UTGeiCtweI8PZ2gZaBRy4CUkHI3Ql73pNUf/5ZXtS9 MlNqyp+SI0LqwQ+cydPTv0e36UvoROvdxA7M4XZ3x96g0k4MgaKo7gvmZbdH2567 30d2wRKmnNjXpagqw6YG =kcgI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 3:15 PM, Jiri Slaby <jslaby@suse.cz> wrote:
I do. I read them usually *after* I install updates, only because I have no easy way to read them before.
Debian lets you read the changelog *before*, and almost everybody I know that uses debian reads it.
You all do not run unstable, right? And you do not maintain multiple servers with distinct OSs, do you?
I have debian unstable on my own work computer (and, granted, I rarely read changelogs in debian unstable). I have a few servers with debian stable, and I do read changelogs there. There's also some RHEL and CentOS - whenever possible, I don't manage them, but those that do do read changelogs (the hard way, because those have the same problem as openSUSE). I have openSUSE at home, and I read changelogs there. I have a few community repos on, and I do read changelogs when they have updates. Released versions of openSUSE tend to receive updates through patches, which already provides a description of the changes, and it even classifies them as recommended, security and whatnot. That's very useful, and is absent on community repos (which usually don't generate patches). There, the only thing left are the changelogs. Especially for mesa, which is quite critical. I have to go to OBS and check the changelog there so that I may know what changed before installing.
And no, I'm a debian user, run debian on several servers and definitely do not have time to read changelogs, no.
So you install updates blindly? I'm glad you trust debian that much. It's not our case, and it's not the case of many people I know. So the use case exists and isn't trivial, nor a niche.
Everybody I know that uses debian is tech savvy, so it's a biased sample, but it's still an important sample if you ask me.
Ok, let me ask again. What actually it gives you?
Note that I'm not against *removing* changelogs. I only think that maintaining .changes files is tedious and does not really work.
It lets me gauge whether an update is necessary, worth the risk, or not. Updating stuff is always a risk. Minimal on stable repos, considerable on community repos. Having the changelog available lets you decide better. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday 2012-08-31 16:17, Jiri Slaby wrote:
On the other hand, OBS vcs changelogs also contain SR descriptions when SRs are accepted. That would in fact make for a good changelog.
Yes, one more supporting argument.
I'll fear the day every package has something like * Wed Apr 15 2009 coolo@suse.de - checkin Because hey, that's _so_ useful. (SCNR. ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am Freitag, 31. August 2012, 11:09:56 schrieb Claudio Freire:
On Fri, Aug 31, 2012 at 9:40 AM, Jiri Slaby <jslaby@suse.cz> wrote:
Oh god, that's like saying you want to generate the NEWS file from the git commit log.
I meant nothing less than: rpm -q --changelog kernel-desktop
That kind of thing only makes sense. This is actually a changelog.
That's not really true.
That only makes sense when the git/svn/vcs log indeed contains descriptive entries.
And entries would need to be classified. Some of the entries would be just for co-developers and some others for users. Not everything from the vcs source log should be shown to the user, he should get a descriptive changelog ...
OBS-web recently took out the text box that allowed you to comment on web-based edits, so you have lots of empty comments when changes are made through the web-ui. That kills your idea pretty much, but even if that text box was reinstated (which I'd recommend), it still has many drawbacks. For one, it depends on user discipline, for two, once you make a mistake on the VCS log, you can't undo it. Mistakes happen, so that's not really good.
On the other hand, OBS vcs changelogs also contain SR descriptions when SRs are accepted. That would in fact make for a good changelog.
-- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 02:40:29PM +0200, Jiri Slaby wrote:
I meant nothing less than: rpm -q --changelog kernel-desktop
That kind of thing only makes sense. This is actually a changelog.
That makes sense if the target audience are developers. But the changelog's purpuse is to tell the user why he should install/update a package. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 04:27 PM, Michael Schroeder wrote:
On Fri, Aug 31, 2012 at 02:40:29PM +0200, Jiri Slaby wrote:
I meant nothing less than: rpm -q --changelog kernel-desktop
That kind of thing only makes sense. This is actually a changelog.
That makes sense if the target audience are developers.
Why do you think so? (see below)
But the changelog's purpuse is to tell the user why he should install/update a package.
I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why? Yes, they may care in case they monitor if some their issue was resolved, but that info is available elsewhere. regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQMugAAoJEL0lsQQGtHBJDnYP/jRCwMIi/SRMnzTXtQfWlFAc D7Og9q2TCUnWxQbVFkdTkuslVZjwGcYYzQz3epM7payqD1YpLHPb8w0V312tLurJ Gq0YGnUtqfL4dkU+SRMjwckcVbJsssig5RzPDXH+w+y9+O3QcGfctMrjTOun8mFl 6aJCR9dsdtzvjWSfix7PMd9WgHy9LTSDAsN3hEwv+j1vyJUrkAFuAhko7ko0wZno 0xoe+tTLTzhaZbiNJ9uT08C7xGwBcpmLU3S0V/Dx9e8dyR12jM+0ZUI/lTvIkuNW aoqUl0Hcy7Qyibc8Q4zBMBzDu8VqHnlezzyaiI+wj2Cof4HZiWosO+Xf4fCRPLf1 ul2YfM7wQHtoHMgH9OSRiTCDVwIEwJ/R6XVxCtWw+slotuKIvEXxRswN8tDC0w0s XPk0qjw4d0Z3en0VchAyHehL+6p9R+osHHqFMInHjZa2XTupVxlJ4jk8gJPP/mqq TvlqsXYw9DkSubGaz6NfrCuMlrRSvYCD/8NG3Xa1AF7l31xmlJ7GQkv5bRuRMfr1 b10pd+is+yf88CCA4JiW+t5dLWUgqLIqVufHYTooL08za3CAuL1xAwO5zqVSmbRb Qq61YUdlXGDeQKGeT39CH+qVRlcIroJp6omYvHdfLhhBsFU0DpinSXlwNbUXHAhR uXcgMcv1UVDka8EK0XN6 =OM6J -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 04:35:12PM +0200, Jiri Slaby wrote:
I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?
If they wouldn't care, how do you explain the requests to make yast show the changelog of packages? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2012 05:03 PM, Michael Schroeder wrote:
On Fri, Aug 31, 2012 at 04:35:12PM +0200, Jiri Slaby wrote:
I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?
If they wouldn't care, how do you explain the requests to make yast show the changelog of packages?
That unfortunately still does not answer the second part of my question. If I demanded yast to show packagers for non-installed packages, would you tend to implement that immediately? I don't think so. Hence I asked *why* they need that and if it won't be enough what I suggested? regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQP3YAAoJEL0lsQQGtHBJtggP/iUMzNb9W/exGtnIwyAY3nZE JBotDYT5K7qhzIpTk6TUXe4w7zBDdpqUEGKLflKge3Ounngxz69vjG/L4ywp/gXH Bda5775P3T+8HZulN93a08BML6tgYiGvvKkrVK6tQSz2UCTq8IrgsNObatFmx5hU fFBCQoWY6VpqOhBrdMlx/BhtpYs0eg2PXN8sNQ5KN8dj6PXP53M6Tl9XMM4bdtzH knTwuRqGoMPTYPdk8uc7bv859hFe54La2Nr+TNe0XipiPP7sJOC4vOtdsETb/kAT dKZJzlTCmubzrkEEd/3tuGyLxFXQtsDVC16WWDOf/wNh7HhBq15iGY3sOZvbe7G/ hvINAu05PqO+81Yz9uOZOAvXzkqLy6jl6oQCRT+6xrthrUjTqESGrXHp+teJIGkO yf5SzibYaJ9SGS3iHBTmyPzz8gtSDmkfW1BMZmaq6Jz/MrK1Qyb1efy7XwB/Fa7C I8OSzN0gi1aq1uqv6hNJG3Xl6tjgESD3FmWqj0CJ34WPujFkZgS3HtjCHSUYDsE5 /eMmviJLp10ecovgYU43ErVFYMPT3IT6u1xvAZ5YAOL/XCs60Cvmh1+nflTDaAT2 CTTxGfR5JqpqNkzdyx1x+FfWV+xGP8VusZCJf7wBK9EFaXvoHvzu8DhNJDIujBNQ OcfKLhAsmsYvph4MGm6c =R1y9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 31, 2012 at 08:09:29PM +0200, Jiri Slaby wrote:
On 08/31/2012 05:03 PM, Michael Schroeder wrote:
If they wouldn't care, how do you explain the requests to make yast show the changelog of packages?
That unfortunately still does not answer the second part of my question. If I demanded yast to show packagers for non-installed packages, would you tend to implement that immediately?
Actually yes, that's exacty what I was talking about. We have a couple of requests and bugs open about yast not showing the changelog for not installed packages. (We actually already store the rpm header offset in the solv file, so that YaST just needs to download the package header with a range request instead of the full rpm, but we're lacking a bit of spare time to implement it.) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jiri Slaby <jslaby@suse.cz> writes:
Michael Schroeder <mls@suse.de> writes:
But the changelog's purpuse is to tell the user why he should install/update a package.
install: no, that's in the description (and in /usr/share/doc/packages/*/NEWS or /usr/share/doc/packages/*/README) update: yes, you will mention applied (security) patches, etc.
I still do not think users read that at all. I, as a user, carelessly install updates and I really don't care what has changed (I would die if I did every distro upgrade/factory rebuild). Do they really care and why?
No, I completely agree with you. rpm changelogs are a source of info for all of us who are involved in packaging. Tracking general changes in the rpm changelog is a mis-conception.
Yes, they may care in case they monitor if some their issue was resolved, but that info is available elsewhere.
I'm not that sure, or I do not understand what you actually mean. I think referencing bug numbers is something for the rpm changelog. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Sep 06, 2012 at 10:21:02AM +0200, Karl Eichwalder wrote:
Jiri Slaby <jslaby@suse.cz> writes:
Michael Schroeder <mls@suse.de> writes:
But the changelog's purpuse is to tell the user why he should install/update a package.
install: no, that's in the description (and in /usr/share/doc/packages/*/NEWS or /usr/share/doc/packages/*/README)
Oh, is that so? And how do you access that information if the package is not installed? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 6 Sep 2012 11:12, Michael Schroeder <mls@...> wrote:
On Thu, Sep 06, 2012 at 10:21:02AM +0200, Karl Eichwalder wrote:
Jiri Slaby <jslaby@suse.cz> writes:
Michael Schroeder <mls@suse.de> writes:
But the changelog's purpose is to tell the user why he should install/update a package.
install: no, that's in the description (and in /usr/share/doc/packages/*/NEWS or /usr/share/doc/packages/*/README)
Oh, is that so? And how do you access that information if the package is not installed?
Now THAT is a failure of the used packaging tools (RPM), not that DEB is better, but this is a general failure of all those tools. These tools where simply NOT made with regards to such information requests. Do not blame the packagers for the tools they are forced (by management) to use. I'm open for the introduction of better tools. But this henpecking on failures of the tools? -- helpful it is _NOT_. -- Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder <mls@suse.de> writes:
On Thu, Sep 06, 2012 at 10:21:02AM +0200, Karl Eichwalder wrote:
Jiri Slaby <jslaby@suse.cz> writes:
Michael Schroeder <mls@suse.de> writes:
But the changelog's purpuse is to tell the user why he should install/update a package.
install: no, that's in the description (and in /usr/share/doc/packages/*/NEWS or /usr/share/doc/packages/*/README)
Oh, is that so? And how do you access that information if the package is not installed?
I read the description. Or I download and extract NEWS or README files (from a tar or rpm) or just install the package... I do not expect that an arbitrary changelog lists this info properly; if it would do it, it would be to large. That's also why we packagers were encouraged in the past to simply add a reference to a NEWS or CHANGES file, which is available on the Web. Of course, I would not mind if yast or zypper would be able to display NEWS or CHANGES info properly; but I think it's a bad idea to . expect all the packager to prepare this info nicely (every packager has his own style and language skills, etc.; for example, I saw it more then once that if you update from 1.1 to 1.5, only NEWS stuff from 1.4 to 1.5 were add to the changes entries and thus 1.2 and 1.3 changes got lost...), and . clutter rpm changelogs with it. I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:
I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder <mls@suse.de> writes:
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?
No, just copy it to a repo meta file. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Thu, 6 Sep 2012, Karl Eichwalder wrote:
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?
No, just copy it to a repo meta file.
That needs conventions. .changes is a convention. A random file whose name contains at least one capital (I have seen NEWS, README, README.md, CHANGES, ChangeLog, Readme and ReadMe in this thread alone) is not a convention, sorry. How anyone could seriously suggest that an interested person should go hunting for random files in /usr/share/doc/packages/$name/SoMeWhErE instead of using _one well defined way_ is beyond me. If it's in .changes or somewhere else doesn't matter that much, but it must be in _one defined place_ for all packages. Currently that one defined place is the rpm changelog, generated from the .changes file. Note that the current policy is nothing new. This whole bruhaha thread is coming about five years late. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Matz <matz@suse.de> writes:
That needs conventions. .changes is a convention. A random file whose name contains at least one capital (I have seen NEWS, README, README.md, CHANGES, ChangeLog, Readme and ReadMe in this thread alone) is not a convention, sorry.
Sure, that's why I said the packager should check it (and, ça va sans dire, convert it to the well-defined NEWS format--see one of these GNU packages). You are confusing the well defined file formats and their meaning, if you mix all this stuff :)
Currently that one defined place is the rpm changelog, generated from the .changes file. Note that the current policy is nothing new. This whole bruhaha thread is coming about five years late.
1/ It's never too late. 2/ Now it is an openSUSE issue. But what's probably more important: the policey is 5 years old but still does not fly. Time for something new :) BTW, .changes files themselves are somehow defined, but their definition is not that strict. I'm not sure whether that's a good thing or not. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 6 Sep 2012, Michael Schroeder wrote:
On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:
I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?
The package description should contain enough information to tell whether the package is worth installing. The changelog is also not available without downloading the package (at least I hope so ...) Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Sep 06, 2012 at 01:42:25PM +0200, Richard Guenther wrote:
On Thu, 6 Sep 2012, Michael Schroeder wrote:
On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:
I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?
The package description should contain enough information to tell whether the package is worth installing. The changelog is also not available without downloading the package (at least I hope so ...)
Wrong, the changelog is in the repodata. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 6 Sep 2012, Michael Schroeder wrote:
On Thu, Sep 06, 2012 at 01:42:25PM +0200, Richard Guenther wrote:
On Thu, 6 Sep 2012, Michael Schroeder wrote:
On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:
I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?
The package description should contain enough information to tell whether the package is worth installing. The changelog is also not available without downloading the package (at least I hope so ...)
Wrong, the changelog is in the repodata.
I hope you are wrong ;) (yes, there is a reference to it) Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Sep 06, 2012 at 03:50:45PM +0200, Richard Guenther wrote:
On Thu, 6 Sep 2012, Michael Schroeder wrote:
On Thu, Sep 06, 2012 at 01:42:25PM +0200, Richard Guenther wrote:
On Thu, 6 Sep 2012, Michael Schroeder wrote:
On Thu, Sep 06, 2012 at 12:33:10PM +0200, Karl Eichwalder wrote:
I'd rather ask the packagers to check whether a good NEWS or CHANGES file exists. If not, he is encouraged to create one. Than yast or zypper should learn to display it.
Uh, you expect yast/zypper to donwload the full rpm, unpack it and display the NEWS or CHANGES file?
The package description should contain enough information to tell whether the package is worth installing. The changelog is also not available without downloading the package (at least I hope so ...)
Wrong, the changelog is in the repodata.
I hope you are wrong ;) (yes, there is a reference to it)
In 'other.xml', to be exact. libzypp doesn't fetch it, though. M. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 8/31/2012 8:40 AM, Jiri Slaby wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/31/2012 11:43 AM, Michael Schroeder wrote:
On Thu, Aug 30, 2012 at 10:37:40PM +0200, Jiri Slaby wrote:
Instead, I would prefer rpm changelog generated from osc log, where some minimal info would be required (and bug numbers requisite).
Oh god, that's like saying you want to generate the NEWS file from the git commit log.
I meant nothing less than: rpm -q --changelog kernel-desktop
That kind of thing only makes sense. This is actually a changelog. The only valid thing in RPM changelog is information about * version update * patch removal/addition * spec file change * maybe some info of other changes
Other packagers' written stories about added/removed features are useless for the reasons mentioned earlier.
I agree that rpm changelog should only be _required_ to talk about the packaging of the software, not the software itself except those changes added by the package, ie patches and whatever the patches do. It's even a messy distraction to see stuff in rpm changelog that is about the software itself. When you say "version x.y.z", that along with the already required link to upstream source, covers all changes in the software. And if it _doesn't_, it's unreasonable to ask a packager to audit the code and supply info that upstream didn't. It's also unreasonable to ask why update if you don't have a good changelog from upstream. So either way it's basically just clutter when stuff from the packages changelog is present in the rpm changelog, and an unnecessary burden in many cases, and likely to simply be wrong or incomplete in many others if you make it a requirement. rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream. At least these days that would be the most sane for me. Maybe the changelog feature was originally added to rpm to hold essentially the softwares changelog, but I don't think that's the best use for the feature, especially not now when packagers are distinct from authors. -- bkw
regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQQLC8AAoJEL0lsQQGtHBJ8uMP/0e0tbW9ZjORZTM+ACh91n+6 cabS1wj5uJ9ZSISOUjI2sv8AfbPk7DgbJ0mt/HRBlHaMthBtQPray+ybilqR2qGI yBthkqNry27uskZD1ZP9kfDdRuMY65YW75b6zNDWmIKSYqoGtjhukuCKGXsFnWMc JRt2KfZfs1z6CeKcxRaGygRpzOQNTF6JMxPEVf61/5s6XLU70UfAtR7KI0sAo+cK inq6/zJDKWepNF+ds3R4mrIxJAMnyaI/aEe9UMQzt3eJPXZMdeHaRXkHZwzPQRA1 vlDWUQVGcOoabXMgNNSmUs+kCRDWddRQFxpaMvZRvqsF7ctxY1CsLYzEZnlr+lmT z4HQXE2NJVCYUDD8uVuFzeHtO+l9UjRTehZljK8W06uRRz0jvbmCaWf7LT0FxkBK 6FoFqpUcXho3CbsBZ96NsJylrceK1BpqqxZE7Xi6Z+E531xAvDP5obHxtg13mB6/ DRl8HYoPkZHT8DqZG8pFiJ8kyOrZi9B2sUHFGKSxZ2aXHwHFr/pE8770tL8nDGtG QxNY3BhjNC/C16tlC2AHE4YxzPv2YgAVYBbVy7hoYlDM9lFE5nl456ZmKhg4srX+ nJ37n0bLhZPtlJzQ9mZaYCGYahqUoSjTdLaZvrCFr7bUIDzFtHLI+O5hUqKgY7IL nDixySK8ndp8rHAjkgla =UmQV -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sat, Sep 1, 2012 at 4:34 AM, Brian K. White <brian@aljex.com> wrote:
rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream.
At least these days that would be the most sane for me. Maybe the changelog feature was originally added to rpm to hold essentially the softwares changelog, but I don't think that's the best use for the feature, especially not now when packagers are distinct from authors.
In the context of all those requests to make yast show the changelog, "changelog" means software changes too, probably foremost, not only packaging changes. If you propose to make rpm changelog only about packaging, then those requests are also requesting for a way to fetch upstream changelogs or read the in-rpm "CHANGELOG"/"NEWS" file. I'm pretty sure reading the changelog on the specfile is far easier to implement. Practicality would then *suggest* to make rpm changelogs a little bit about the software too. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sat, 1 Sep 2012 18:49:59 -0300 Claudio Freire <klaussfreire@gmail.com> wrote:
Practicality would then *suggest* to make rpm changelogs a little bit about the software too.
That is what is proposed by Dominique in the original post, but what Brian and few other are asking is to keep change log as a technical information. There is a lot of places where other info can be obtained and polluting log with it will not help packagers to find what has to be done for new version of software. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sat, Sep 01, 2012 at 03:34:36AM -0400, Brian K. White wrote:
rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream.
That's because you're a developer/packager, if you'd be a user who doesn't know about packaging you would demand some info about the functional changes (plus the security changes). Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Michael Schroeder wrote:
On Sat, Sep 01, 2012 at 03:34:36AM -0400, Brian K. White wrote:
rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream.
That's because you're a developer/packager, if you'd be a user who doesn't know about packaging you would demand some info about the functional changes (plus the security changes).
For user visible docu we have the patch descriptions. Since those descriptions are compiled from the changelog entries I agree that the changelog should contain at least some notes about important function changes or new features. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2012-09-06 09:37, Ludwig Nussel wrote:
Michael Schroeder wrote:
[...] if you'd be a user who doesn't know about packaging you would demand some info about the functional changes (plus the security changes).
For user visible docu we have the patch descriptions. Since those descriptions are compiled from the changelog entries I agree that the changelog should contain at least some notes about important function changes or new features.
Indeed. In fact, for packages like aaa_base/sysconfig which don't really have a homepage or a NEWS file, the rpm changelog is all there is. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
"Brian K. White" <brian@aljex.com> writes:
I agree that rpm changelog should only be _required_ to talk about the packaging of the software, not the software itself except those changes added by the package, ie patches and whatever the patches do. It's even a messy distraction to see stuff in rpm changelog that is about the software itself.
+1 [...]
rpm changelog should have basic version and upstream source info, spec changes, which includes any noteworthy integration info, compiler options, enabled/disabled features, and only those software changes and bug fixes supplied by that package on top of upstream.
At least these days that would be the most sane for me. Maybe the changelog feature was originally added to rpm to hold essentially the softwares changelog, but I don't think that's the best use for the feature, especially not now when packagers are distinct from authors.
I do not even think that the rpm changelog feature was initially meant to list any software changes, but just the packaging changes. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
El 29/08/12 08:42, Dominique Leuenberger a.k.a DimStar escribió:
Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .
There are any other awful things in this document, where I do start... "All new patches should end with the extension '.patch'." @_@ what the.. file -i *.diff text/x-diff; charset=us-ascii file -i *.patch text/x-diff; charset=us-ascii What about compressed patches ? do you have a reason why we should care about this ? as long as file mime-type is text/x-diff and the patch applies, compiles and runs correctly ? "The preferred patchlevel is -p1 as it makes importing using tools like quilt more straightforward." Really ? according to whom ? been using quilt for years with -p0 with no problems at all... the only thing that will do is adding more characters and flags to the already ugly spec files... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Aug 30, 2012 at 4:38 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
"The preferred patchlevel is -p1 as it makes importing using tools like quilt more straightforward."
Really ? according to whom ? been using quilt for years with -p0 with no problems at all... the only thing that will do is adding more characters and flags to the already ugly spec files...
Regardless of that, I find -p1 patches easier to generate when working with tarballs. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/30/2012 09:43 PM, Claudio Freire wrote:
On Thu, Aug 30, 2012 at 4:38 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
"The preferred patchlevel is -p1 as it makes importing using tools like quilt more straightforward."
Really ? according to whom ? been using quilt for years with -p0 with no problems at all... the only thing that will do is adding more characters and flags to the already ugly spec files...
Regardless of that, I find -p1 patches easier to generate when working with tarballs.
According to <http://en.opensuse.org/openSUSE:Fixing_bugs> *Create final patch* quilt refresh -p0 package-version-brief-description.patch So this document prefers -p0 Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 30 August 2012 20:38, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
"The preferred patchlevel is -p1 as it makes importing using tools like quilt more straightforward."
Really ? according to whom ? been using quilt for years with -p0 with no
According to Jengelh -> http://old-en.opensuse.org/index.php?title=Packaging%2FPatches&diff=119213&oldid=119212 And it's the problem with the "the guidelines say so" argument. It's a wiki, anybody can change it without any previous discussion. Last time I read them it didn't say the -p1 was preferred and I don't remember a single line discussing it in this mailing list. -- 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 (DimStar@openSUSE.org) [20120829 14:42]:
A simple "Update to version x.y.z" is, as before, not accepted.
What is when there is *no* nor no usable info in the package about the changes? Perfect example are some of the packages that comprise OFED (publicly accessible in OFED:Factory). It's nearly impossible to get useful info on the changes and I will not try to scan a ChangeLog with the detailed changes and try to condense them into something usefull.
Most prominent is likely the mentioning of the patches life cycle,
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia piątek, 31 sierpnia 2012 13:31:45 Philipp Thomas pisze:
* Dominique Leuenberger a.k.a DimStar (DimStar@openSUSE.org) [20120829 14:42]:
A simple "Update to version x.y.z" is, as before, not accepted.
What is when there is *no* nor no usable info in the package about the changes? Perfect example are some of the packages that comprise OFED (publicly accessible in OFED:Factory). It's nearly impossible to get useful info on the changes and I will not try to scan a ChangeLog with the detailed changes and try to condense them into something usefull.
Most prominent is likely the mentioning of the patches life cycle,
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.
That would require patching Kompare so that it allows adding that sort of annotation to a patch. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/01/2012 12:44 PM, Křištof Želechovski wrote:
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.
That would require patching Kompare so that it allows adding that sort of annotation to a patch.
No it would not. It should already handle patch-like patches, i.e. with header, right? regards, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQQi10AAoJEL0lsQQGtHBJTIUQALDCMOqtoP8YKhc0Nxz2JKz5 N0IuFy6gkpQ6Rh3ygc/cLAjqDA5mVmUEj4aDatV7Hb43YwwEKdwGXZrFa70MHRxc 7BJJFCUJwg+hRAftCKQzFDDsKI/X0VO5VwOx+4HjC1mgTmoUIUXYkFt081TLmoC7 noCevrmhF2VTgIBwPuXRmz/jeaw7tnMRs08y4opbejhGP6OkH9PxWhCqDhEhXmEj ar5WWnfJ8YVHTOabEdhHqJw0jPj/N11eVWsb7oEu5BqXvvt6AljQJrSsL+yAKncQ 6WJzYv6BNoghM3lDz0QK/8BmpTBz8u0YbruvZpGeqJg8V9LSm/xdCsrKohl+81/R 86wzbB6bwy8s0N4tRDK5ihidIPl2ERgN4TZtlvEoeyY+z+cVMhdF28WcHaIbJT4o tLPdKi4nMiNLL6u+wdrczL74QbBjCAu1WEdDnqnnblbUI7TikrwZVPbHrzkMWTU7 jUEIDI3vDq+mn1n805pCIEAvn4STWys9eWLiKldiquLDbdfBHNdH9I5JiNZ38RF7 t8qfs1+neBHOj9SomXZABAeUGMh0QCDIkkwmuR+HbZsAQoi6S3ECb5CXzQ7Y6rZN Roxf6/1btUOsgdeJ5FKed7kuldUOyljtUetor/yTp60YFay5iBGCovBcun2NoEha LlbiPo1AGguHWrAQM4+k =+rmk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia sobota, 1 września 2012 17:44:52 Jiri Slaby pisze:
On 09/01/2012 12:44 PM, Křištof Želechovski wrote:
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.
That would require patching Kompare so that it allows adding that sort of annotation to a patch.
No it would not. It should already handle patch-like patches, i.e. with header, right?
The problem is Kompare cannot *produce* patches with headers. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Sunday 2012-09-02 13:37, Křištof Želechovski wrote:
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.
That would require patching Kompare so that it allows adding that sort of annotation to a patch.
No it would not. It should already handle patch-like patches, i.e. with header, right?
The problem is Kompare cannot *produce* patches with headers.
Producing patchces is inherently a user task, as Kompare cannot know what the patch is for. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Dnia wtorek, 11 września 2012 03:29:36 Jan Engelhardt pisze:
On Sunday 2012-09-02 13:37, Křištof Želechovski wrote:
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.
That would require patching Kompare so that it allows adding that sort of annotation to a patch.
No it would not. It should already handle patch-like patches, i.e. with header, right?
The problem is Kompare cannot *produce* patches with headers.
Producing patchces is inherently a user task, as Kompare cannot know what the patch is for.
I think this problem is soluble, in that it should be possible to tell Kompare what the patch is for. Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Freitag, 31. August 2012 schrieb Philipp Thomas:
The most usefull requirement would IMO be that patches were annotated as is required for our kernels, i.e. a From line, date and and brief summary plus the name and address of the person that added the patch.
Well, it depends ;-) I usually use a one-line patch description in the spec (no, not in the "official" patch tagline format) that gives a short summary about what the patch does and its upstream status (for example "sent upstream $date", "taken from upstream svn/git/bzr $revision","openSUSE only"). This one-line description is usually enough, at least for small patches. The big advantage of using such a one-line description is that it is inside the spec file and gives a very quick (and still useful) overview about all patches in a package. If you have (only) verbose descriptions in the patch file, you'll have to open all patches to get an overview about what the patches do. You'll of course get more details, but it's harder to get an overview about all patches in the package. I'd propose: - have one-line patch tags in the spec next to the Patch: line (even if the patch contains a more verbose description) - add a more verbose description to long and/or difficult to understand patches (benchmark: will you understand the patch if you read it a year later? If not, add a verbose description ;-) Regards, Christian Boltz -- Planung ist der Ersatz des Zufalls durch den Irrtum. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (29)
-
Adrian Schröter -
Alin M Elena -
Andreas Jaeger -
Brian K. White -
Christian Boltz -
Claudio Freire -
Cristian Morales Vega -
Cristian Rodríguez -
Dimstar / Dominique Leuenberger -
Dominique Leuenberger -
Dominique Leuenberger a.k.a DimStar
-
Guido Berhoerster -
Jan Engelhardt -
Jiri Slaby -
Karl Eichwalder -
Krzysztof Żelechowski -
Křištof Želechovski -
Ludwig Nussel -
Marcus Meissner -
Michael Matz -
Michael Schroeder -
Nelson Marques -
pgajdos＠suse.cz -
Philipp Thomas -
Rajko -
Richard Guenther -
Togan Muftuoglu -
Wolfgang Rosenauer -
Yamaban