[opensuse-factory] 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 29, 2012 at 02:42:51PM +0200, 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
Hallo, I've collected bits about changes across various pages in our wiki and put them all to one place http://en.opensuse.org/openSUSE:Howto_write_good_changes feel free to review, or extend or link. Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 29 Aug 2012 16:24:08 +0200 Michal Vyskocil <mvyskocil@suse.cz> wrote: ...
http://en.opensuse.org/openSUSE:Howto_write_good_changes
feel free to review, or extend or link.
Gladly :) Whole topic of packaging seems to need a bit organization because top level navbar is a bit unreadable and fixing it is impractical. Specialist for web design recommend not more then 7 entries in horizontal navigation and we have 16. If we count words that it is even worse. Entries should be easily separable which is asking for: * consistent naming, whenever possible single words, * consistent capitalization, * more space between entries (single dot is not enough :) * entries don't wrap in a new line I can take on this and create vertical navbar, something similar to http://en.opensuse.org/AMD but I would like opinion of packagers. Would you like something like that? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, August 29, 2012 09:53:30 Rajko wrote:
On Wed, 29 Aug 2012 16:24:08 +0200 Michal Vyskocil <mvyskocil@suse.cz> wrote:
...
http://en.opensuse.org/openSUSE:Howto_write_good_changes
feel free to review, or extend or link.
Gladly :)
Whole topic of packaging seems to need a bit organization because top level navbar is a bit unreadable and fixing it is impractical.
Specialist for web design recommend not more then 7 entries in horizontal navigation and we have 16. If we count words that it is even worse.
Entries should be easily separable which is asking for: * consistent naming, whenever possible single words, * consistent capitalization, * more space between entries (single dot is not enough :) * entries don't wrap in a new line
I can take on this and create vertical navbar, something similar to http://en.opensuse.org/AMD but I would like opinion of packagers. Would you like something like that?
Yes, please give it a try, Thanks! 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 30 Aug 2012 09:04:10 +0200 Andreas Jaeger <aj@suse.com> wrote:
I can take on this and create vertical navbar, something similar to http://en.opensuse.org/AMD but I would like opinion of packagers. Would you like something like that?
Yes, please give it a try,
It is done. It is simple solution with some limitations, because the goal was to replace existing navbar, not to explore navigation solutions. We have 2 basic solutions right now and this is third that should with time replace navbars. To have article in the right side navigation box add: * {{Packaging_docnav}} at the top, and * [[Category:Packaging documentation]] at the bottom of the article that you want to include. This will list article in: http://en.opensuse.org/Category:Packaging_documentation and it will automatically appear in navigation box: http://en.opensuse.org/Template:Packaging_docnav (docnav as in documents navigation) More details are listed in the template page. This way solves some problems with horizontal bar as it is currently implemented: * Listing can grow as much as needed. * Addition of article to the navigation box is as simple as adding template and category, which should be added to each article anyway; no more need to edit navigation bar. * When article title is changed links are automatically updated. Visitors will never see "Redirected from >" . Ideas and comments are welcome. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 03.09.2012 18:51, schrieb Rajko:
On Thu, 30 Aug 2012 09:04:10 +0200 Andreas Jaeger <aj@suse.com> wrote:
I can take on this and create vertical navbar, something similar to http://en.opensuse.org/AMD but I would like opinion of packagers. Would you like something like that? Yes, please give it a try, It is done.
It is simple solution with some limitations, because the goal was to replace existing navbar, not to explore navigation solutions. We have 2 basic solutions right now and this is third that should with time replace navbars.
To have article in the right side navigation box add: * {{Packaging_docnav}} at the top, and * [[Category:Packaging documentation]] at the bottom of the article that you want to include.
This will list article in: http://en.opensuse.org/Category:Packaging_documentation and it will automatically appear in navigation box: http://en.opensuse.org/Template:Packaging_docnav (docnav as in documents navigation)
More details are listed in the template page.
This way solves some problems with horizontal bar as it is currently implemented: * Listing can grow as much as needed. * Addition of article to the navigation box is as simple as adding template and category, which should be added to each article anyway; no more need to edit navigation bar. * When article title is changed links are automatically updated. Visitors will never see "Redirected from >" .
Ideas and comments are welcome.
make it look mor like: http://developer.github.com/ that is: group similar items together and make it look even nicer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 03 Sep 2012 20:34:40 +0200 Christoph Obexer <cobexer@gmail.com> wrote:
Ideas and comments are welcome.
make it look mor like: http://developer.github.com/ that is: group similar items together and make it look even nicer
That would be next step that was skipped this time due to underlying template coding that allows only one side box on the page, and only one category per template. There is another horizontal template called Knowledge that will be changed to vertical for the same reason this one was placed on side; one can't balance entries in all 3 groups which is producing a lot of empty space. When I take on that one I'll have to solve multiple entries in a single frame, which will allow exactly what you propose, sorting articles in groups with expandable subgroups. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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? Thanks, 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 31.08.2012 17:03, schrieb Michael Schroeder:
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?
I wrote previously in this thread that I'd like to read them before installation. As long as that is not possible the changelog is of not much use to the user IMHO. Sometimes for the packager still but my experience with trying to reconstruct changes done from other people is pretty disappointing even with our current rules. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/31/2012 01:31 PM, Philipp Thomas wrote:
* 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.
If you can't figure out what's new - why do the update? ;) Seriously, if you update and the update is a pile of many bugs, just say "Update to x.y.z, bugfix release.". In same cases it's just a version bump since all packages of a collection get updated, so say "version bump, no changes.". But if there are changes, highlight the one or two major ones. I'm sure there's an announcement out there that says something...
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 is one option, the PATCH-* description is a condensed form of that, e.g.: # PATCH-FEATURE-OPENSUSE -- use separate symbol version for Owl extensions - lnussel@suse.de I'm fine with either option - I agree it's important to document it, 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 31 Aug 2012 13:54:46 +0200, Andreas Jaeger <aj@suse.com> wrote:
In same cases it's just a version bump since all packages of a collection get updated, so say "version bump, no changes.". But if there are changes, highlight the one or two major ones. I'm sure there's an announcement out there that says something...
And that's where you're wrong! OFED consists of a large number of packages, each having it's own source code repository as you can see here: https://www.openfabrics.org/downloads/MAINTAINERS . From the updates I've done it seems that there is no real system in the versioning. Some packages had changes in the code but no changes in the version number, others have changed versions and no code changes. Some packages have at least a ChangeLog, others have no Info what-so-ever. The last update I made for sle11 sp2 had a library bump it's version number but no changes in the package name ... As you can imagine, doing updates is anything but fun as you have to do tedious detective work to try and find if changes where done and if yes, what changed.
# PATCH-FEATURE-OPENSUSE -- use separate symbol version for Owl extensions - lnussel@suse.de
You could generate the patch tag from the data in the patch but not the other way round. Our kernel maintainers have a hard requirement for commented patches, why can't we have that for the rest of the distribution? Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Aug 31, 2012 at 09:29:27PM +0200, Philipp Thomas wrote:
On Fri, 31 Aug 2012 13:54:46 +0200, Andreas Jaeger <aj@suse.com> wrote: [ 8< ]
# PATCH-FEATURE-OPENSUSE -- use separate symbol version for Owl extensions - lnussel@suse.de
You could generate the patch tag from the data in the patch but not the other way round. Our kernel maintainers have a hard requirement for commented patches, why can't we have that for the rest of the distribution?
As other teams might have found a different but also working approach. For Samba we ensure to have a header in each patch. By this header we're able to identify the author and the addressed issue. In the case of an upstream patch this is identical to the output of git show <object> and the name of the object also defines the filename. For patches we're still working on or which aren't applicable upstream we use an own self describing name but ensure to keep the same patch header. This allows people pulling the source rpm easily to identify the author and the subject of a particular patch. But these are all details other teams don't care about. As we don't care much about how the x.org or kernel developers maintain their packages. Is this the result cause we're all this ignorant? No, I believe this result is caused by different experiences and needs. And a huge, huge amount of history. Due to our experience the package change log file has to fulfill different needs: a) In the case of an update users need to see what's new and got added/ fixed. b) We reuse the same text to concatenate the update notification messages. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Friday 2012-08-31 21:58, Lars Müller wrote:
You could generate the patch tag from the data in the patch but not the other way round. Our kernel maintainers have a hard requirement for commented patches, why can't we have that for the rest of the distribution?
For Samba we ensure to have a header in each patch. By this header we're able to identify the author and the addressed issue. In the case of an upstream patch this is identical to the output of git show <object> and the name of the object also defines the filename. [...] But these are all details other teams don't care about. As we don't care much about how the x.org or kernel developers maintain their packages.
Is this the result cause we're all this ignorant?
Nope, just a "forgive them, because they don't know what they're doing." :) If nobody told them, who would? Mails like yours on samba, pth's on OFED, etc. all highlight what's wrong with standard #1. Provides excellent reading material for the wiki. It's all good. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (19)
-
Adrian Schröter -
Andreas Jaeger -
Brian K. White -
Christoph Obexer -
Claudio Freire -
Dominique Leuenberger a.k.a DimStar -
Jan Engelhardt -
Jiri Slaby -
Karl Eichwalder -
Křištof Želechovski -
Lars Müller -
Ludwig Nussel -
Michael Schroeder -
Michal Vyskocil -
pgajdos＠suse.cz -
Philipp Thomas -
Philipp Thomas -
Rajko -
Wolfgang Rosenauer