[gentoo-dev] changelogs...

[gentoo-dev] changelogs...

[Spundun Bhatt]

As a sidenote to the currently going discussion about package
description.

When I recieve updates of ebuilds... I am usually curious whats new to
checkout (I am sure everybody is). 
I always do emerge -u --deep world -p --changelog
But more often than not... chang log says "version bump" which doesnt
tellme anything.
Is it feasible to add a url to the release note of the release (in cases
where its not an ebuild bugfix release). 
I dont know if there anything to do about it.. but I see gnome.org as
the homepage of all components so its not easy atall to find out what a
perticular component does.

Hope this Helps
Spundun


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] changelogs...

[Dylan Carlson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu May 22 2003 4:51 pm, Spundun Bhatt wrote:
> As a sidenote to the currently going discussion about package
> description.
>
> When I recieve updates of ebuilds... I am usually curious whats new to
> checkout (I am sure everybody is).
> I always do emerge -u --deep world -p --changelog
> But more often than not... chang log says "version bump" which doesnt
> tellme anything.
> Is it feasible to add a url to the release note of the release (in cases
> where its not an ebuild bugfix release).
> I dont know if there anything to do about it.. but I see gnome.org as
> the homepage of all components so its not easy atall to find out what a
> perticular component does.

I think that would be a needless expenditure of bits.   There is always 
HOMEPAGE set in the ebuild for people to query, and that's where people 
should go to get release information.  

If no information is available about the release on the HOMEPAGE, then I 
agree some notes in the ChangeLog would be appropriate.

Cheers,
Dylan Carlson

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
Key fingerprint = 3AEA DE38 FE42 15A6 C0E2 730E 3D04 BCC1 708E 165F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+zUeVPQS8wXCOFl8RAhKuAJ0eAImHazoFHbJHcOXe/z9S4jrIHgCfSyEC
jgImkiUL6eZPgtNkl5NHLEk=
=lJM9
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] changelogs...

[Spundun Bhatt]

On Thu, 2003-05-22 at 14:56, Dylan Carlson wrote:
> 
> I think that would be a needless expenditure of bits.   There is always 
> HOMEPAGE set in the ebuild for people to query, and that's where people 
> should go to get release information.  
> 
> If no information is available about the release on the HOMEPAGE, then I 
> agree some notes in the ChangeLog would be appropriate.
unfotunately this is oftem the case. Right now as I write on my machine
if I execute the following.you will see that only the vim updates have a
proper release notes right on the front page. Orbit and gnome-vfs point
directly to gnome.org where I havent been able to find any release note.
(I looked for release notes of ORBit for like more than an hour.... then
I posted the message). fileroller website hasnt even announced any such
release... only the tarballs available on on gnome (boy is gentoo
cutting edge :) ). gaim also doesnt provide any realease note on the web
site. I suppose all these packages provide release notes in the source
tarball... but thats not very convenient.. it defeats some of the
purpose of the gentoo system to download the file and expand just to
read the release note.
Spundun
-------------------------------------------------------------------------
mermaid eclass # emerge -u --deep world -p --changelog
 
These are the packages that I would merge, in order:
 
Calculating world dependencies ...done!
[ebuild    U ] gnome-base/ORBit2-2.6.2 [2.6.1]
[ebuild    U ] gnome-base/gnome-vfs-2.2.5 [2.2.4]
[ebuild    U ] app-editors/vim-core-6.2_pre4 [6.2_pre3]
[ebuild    U ] app-editors/gvim-6.2_pre4 [6.2_pre3]
[ebuild    U ] app-arch/file-roller-2.2.4 [2.2.3]
[ebuild    U ] gnome-base/gnome-applets-2.2.2 [2.2.1]
[ebuild    U ] app-editors/vim-6.2_pre4 [6.2_pre3]
[ebuild    U ] net-im/gaim-0.63 [0.62]
[ebuild    U ] x11-libs/gtkmm-2.2.2 [2.2.1]
 
*ORBit2-2.6.2
 
  22 May 2003; foser <foser@gentoo.org> ORBit2-2.6.2.ebuild :
  New version
 
*gnome-vfs-2.2.5
 
  22 May 2003; foser <foser@gentoo.org> gnome-vfs-2.2.5.ebuild :
  New version
 
*vim-core-6.2_pre4
 
  21 May 2003; Aron Griffis <agriffis@gentoo.org>
vim-core-6.2_pre4.ebuild:
  Update to 6.2d
 
*gvim-6.2_pre4
 
  21 May 2003; Aron Griffis <agriffis@gentoo.org> gvim-6.2_pre4.ebuild:
  Update to 6.2d
 
*file-roller-2.2.4
 
  22 May 2003; foser <foser@gentoo.org> file-roller-2.2.4.ebuild :
  New version
 
*vim-6.2_pre4
 
  21 May 2003; Aron Griffis <agriffis@gentoo.org> vim-6.2_pre4.ebuild:
  Update to 6.2d
 
*gaim-0.63
 
  20 May 2003; Brandon Low <lostlogic@gentoo.org> gaim-0.63.ebuild:
  Bump, unstable only
 
  29 Apr 2003; Brandon Low <lostlogic@gentoo.org> gaim-0.62.ebuild:
  Add a message about gaim-encryption not being supported by gaim
project
 
 
mermaid eclass #
-----------------------------------------------------------------------------
> 
> Cheers,
> Dylan Carlson
> 
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
> Key fingerprint = 3AEA DE38 FE42 15A6 C0E2 730E 3D04 BCC1 708E 165F
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQE+zUeVPQS8wXCOFl8RAhKuAJ0eAImHazoFHbJHcOXe/z9S4jrIHgCfSyEC
> jgImkiUL6eZPgtNkl5NHLEk=
> =lJM9
> -----END PGP SIGNATURE-----
> 
> 
> --
> gentoo-dev@gentoo.org mailing list


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] changelogs...

[Spundun Bhatt]

On Thu, 2003-05-22 at 14:58, Spundun Bhatt wrote:
<all the rant about cant find the release notes on homepage>

I just realised I proved that for many packages such release note dont
exist (or do they?) on web. So the suggestion of including aurl in the
changelog goes down the drain... unless gentoo itself maintain an
archive of the release notes... hey! that sounds like something!
Spundun


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] changelogs...

[foser]

On Fri, 2003-05-23 at 00:02, Spundun Bhatt wrote:
> On Thu, 2003-05-22 at 14:58, Spundun Bhatt wrote:
> <all the rant about cant find the release notes on homepage>
> 
> I just realised I proved that for many packages such release note dont
> exist (or do they?) on web. So the suggestion of including aurl in the
> changelog goes down the drain... unless gentoo itself maintain an
> archive of the release notes... hey! that sounds like something!
> Spundun

The ChangeLog's for these releases are not released in any way except
for inside the package, which in it's turn should be available when
installed in the package's /usr/share/doc.

Anyway all these releases are minor stable releases consisting of a few
typo fixes and translation updates anyway.

Besides that, the package ChangeLog is about changes between ebuilds,
'version bump' or 'new version' are to indicate nothing worth mentioning
changed in the ebuild.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] changelogs...

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Fri, May 23, 2003 at 02:36:38AM +0200, foser wrote:
> Besides that, the package ChangeLog is about changes between ebuilds,
> 'version bump' or 'new version' are to indicate nothing worth mentioning
> changed in the ebuild.

I agree, Gentoo ChangeLogs are for Gentoo changes, such as fixes in ebuilds.
If you want the know what the new things are in the package, and it isn't on
the respective website, contact the author and ask to put it online.

Wkr,
	Sven Vermeulen
	Gentoo Documentation

-- 
Thanks to DRM, you know that something has been built in environment of 
unspecified degree of security, from source you cannot check, written by 
programmers you don't know, released after passing QA of unknown quality and 
which is released under a license that disclaims any responsibility...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] changelogs...

[foser]

On Thu, 2003-05-22 at 23:58, Spundun Bhatt wrote:
> Orbit and gnome-vfs point
> directly to gnome.org where I havent been able to find any release note.
> (I looked for release notes of ORBit for like more than an hour.... then
> I posted the message). fileroller website hasnt even announced any such
> release... only the tarballs available on on gnome (boy is gentoo
> cutting edge :) ). 

orbit and gnome-vfs like a lot of the gnome libs don't have really
homepages (even if there's something it is usually not kept up to date,
see file-roller). In that case we just point to gnome.org .

As you see, things happen for a reason.

- foser


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Changelogs

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Recent discussion on this ML and on the portage-ml as well as
#gentoo-portage regarding pkg_warn() and the basic concept behind it.
We talked about adding new functionality, about adding a warning section
to the ebuild or to the metadata.  However.  all of these tend to have
problems.  The dev won't write the extra function, duplication of data
in pkg_{post/pre}inst, mangling of metadata.xml.

Portage current features the -l switch, to show changelogs.  It works
pretty well to show changes in packages prior to emerging.  For example,
emerge -uDpvl world -> shows what will emerge then shows the changelogs
for each package.  For a very large set of packages the output can be
overwhelming, however all the changelogs are provided and the user at
least has data to parse through.

The problem is that the ebuild is where all the action is, and the
changelogs lay empty.  Users cannot run most ebuild functions prior to
emerging packages ( usually pkg_postinst() for migrating instructions ),
thus any important messages that need to be seen that deal with the
package are only seen after it is installed.  This is bad because the
user is not warned ahead of time about any issues ( new library
installed, breaks new processes that link to it ).

Basically this is a suggestion for developers to put more information in
the changelog.  You are ( usually ) the maintainer, you know what the
program can do, what problems it can cause.  Putting this information in
pkg_postinst() is good, but putting it in the changelog is better.
Believe it or not; users actually read the changelog and hope at times
that it provides valuable information about the package and not "marked
stable on foo ( #41975 )".

Marking it stable on an arch and knowing that moving to stable has the
potential to break stable systems should be noted in the changelog, even
if there is just a pointer to a website, or to the ebuild itself to read
the pkg_postinst() and figure out wtf is going to happen.

*Marches toward better changelogs since most of the current logs are
rather skimpy on any details*

- -Ajec
warnera6@egr.msu.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQubrsWzglR5RwbyYAQI3dg/+KVFX4GctDzVjfhVDVDzGbx7q+T+0P+yf
AYOrsoWuFWcUh2/0FDV8z2aZ1P55M/SBWKgtFmkdMOGTUD34KGTZlyWMlcswxKfO
a3D43Dr1DQ6x66I2Gcf3VyHqpBgnPKgVhuNUiuFO8WD5N/W/sICLoTW415GEA7U7
jktDqrE+TDKBAdHvY2YaGD8iXZBX0zrS2v/1eeBLJ5/rSVVQfG9DICbMcRZ4lf5L
B6ktoarY5xjv6raE9wlZgrkjGpd7VoSn8yRnd10ekwftAlk1JKbAn8TIttWeMmYJ
9ZgLm/ZVjxAbzfoRhHjpw1nRb2q5oOeODfZQyOvlWFpZRhvMFySsDddfGsCbC2BS
Yf6pf8vKIMHRFLRSSupOl8agzHOm+CSGLHCpv+gs9sZ2eXzO2UjKqnN1VwoMO1sd
AJO/z28BvjqnBFU5WsTVmAxhuvziplrLTMfZP93k2VJ3zIni7NhKsLs4rJLnYbbP
xFg/Ji/YrZWwqXKFANYV2m/rw2HciKuFQzS2YmrZceAWjPz6s21m4yX6z+Hr1p+3
cu1TMIbZsg5ZA5V+nnmV1vfwW1fCLsyItOjYfv9IZi6JdupU22Lr3yR13wcUL6ZN
oFt3KmgLzZLjakXiIgICvKT9ZMKBMTkfkHh4qf6cxKmPHPan3Mi+5eBXmPWZ2oGQ
Q7gW3j/+Cps=
=Ymtl
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changelogs

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

maillog: 26/07/2005-22:05:49(-0400): Alec Warner types
> 
... skip some text that I mostly agree with...
> 

I mentioned this before, but it would be nice to somehow mark important
messages in the changelog. Prefix them with something, say "WARNING
around there", anything, as long as it is agreed upon and everybody uses
it. Changelogs are huge and even if portage is not made to show only the
relevant *important* information, it would be nice to have an easy way
to see it by grepping the output of emerge -l.

-- 
()   Georgi Georgiev   () You will receive a legacy which will place   ()
()    chutz@gg3.net    () you above want.                              ()
()  +81(90)2877-8845   ()                                              ()

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Wednesday 27 July 2005 11:05, Alec Warner wrote:
> 
> Recent discussion on this ML and on the portage-ml as well as
> #gentoo-portage regarding pkg_warn() and the basic concept behind it.
> We talked about adding new functionality, about adding a warning section
> to the ebuild or to the metadata.  However.  all of these tend to have
> problems.  The dev won't write the extra function, duplication of data
> in pkg_{post/pre}inst, mangling of metadata.xml.

Quicker closer than me! ;)

> Portage current features the -l switch, to show changelogs.  It works
> pretty well to show changes in packages prior to emerging.  For example,
> emerge -uDpvl world -> shows what will emerge then shows the changelogs
> for each package.  For a very large set of packages the output can be
> overwhelming, however all the changelogs are provided and the user at
> least has data to parse through.

"The dev won't write the extra function"
Same problem, no?

Not sure what you meant by "duplication of data" or "mangling of metadata.xml"
but I still don't see why pkg_warn() can't work. Those that are writing stuff
in pkg_postinst() presently can use pkg_warn() and feel warm and fuzzy knowing
that more people are making use of the information. Those that don't make use
of it? No different to not making use of pkg_postinst().

If you could explain what you meant by the other two listed issues?

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Alec Warner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Stubbs wrote:
> On Wednesday 27 July 2005 11:05, Alec Warner wrote:
> 
>>Recent discussion on this ML and on the portage-ml as well as
>>#gentoo-portage regarding pkg_warn() and the basic concept behind it.
>>We talked about adding new functionality, about adding a warning section
>>to the ebuild or to the metadata.  However.  all of these tend to have
>>problems.  The dev won't write the extra function, duplication of data
>>in pkg_{post/pre}inst, mangling of metadata.xml.
> 
> 
> Quicker closer than me! ;)
> 
> 
>>Portage current features the -l switch, to show changelogs.  It works
>>pretty well to show changes in packages prior to emerging.  For example,
>>emerge -uDpvl world -> shows what will emerge then shows the changelogs
>>for each package.  For a very large set of packages the output can be
>>overwhelming, however all the changelogs are provided and the user at
>>least has data to parse through.
> 
> 
> "The dev won't write the extra function"
> Same problem, no?
> 
> Not sure what you meant by "duplication of data" or "mangling of metadata.xml"
> but I still don't see why pkg_warn() can't work. Those that are writing stuff
> in pkg_postinst() presently can use pkg_warn() and feel warm and fuzzy knowing
> that more people are making use of the information. Those that don't make use
> of it? No different to not making use of pkg_postinst().
> 
> If you could explain what you meant by the other two listed issues?
> 

In hindsight, arguing over almost two different things.  We both agree
that upgrade paths for changes that break the system are good, and that
information regarding the upgrade path *SHOULD* be provided in some
manner.  Some developers think that providing detailed instructions in
pkg_postinst() is good, others will direct you to a website ( usually
UPSTREAM's webpage ) which has the instructions; it saves them time.
Which is correct, or are both?

In the latter case all that is really needed is some sort of switch (
NOT a use flag ) that says this package causes problems, look at
UPSTREAMS webpage for migration information.  I am not particularly in
favor of that, but it's simple for a developer to do, and it's simple
for me to check out a potential 4 or 5 packages in a given upgrade to
figure out what I have to do.

In the former case where more specific information is provided to the
user by portage you generally want a more complex system.  You want the

"<warn from="2.6.4:2[baduse]" to="2.7[-baduse]">You enabled baduse?
Removing it will rm -rf /!</warn>" syntax ( from our conversation last
night ) which is decidedly more complex to write and more complex to parse,

Don't get me wrong, I like it, but I doubt it will get used by enough
people to be useful.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQuggmWzglR5RwbyYAQIOPhAAj9ugQNjuz8Ij218QEO3Tp2EY1kN/D0rL
C7Fqj8RX5yn1QL+R+TR9m1e+pkmigfFIWnmMxwzrUsYupd7I9hXgGiHaVD9L6//A
wIdqBBrxZ4JXp4S3nzrWWKtPOx3Cgdf++cYOPwDnOME7XOV5qYj0v+iLeKx89xGN
QUkRQNlK8/mBLabgOSmzffOQbQvq6qr02DNdXYFgb4JZg3MaJ+KtAZnDseutzzc4
DYrhpz82gXdRdYPwHthdcSqcFWhh9I+3hp4f+piFBl8L+5wKIch3fUjQn3wDDhDr
EVGh4mvrCAUlnI/I00YK/kcxkIdf3132gz7hKlUVHNlbf8ClvnwEM9aUzeOZTgWw
YGfyCjdcuFxX5t3VeDJgbe/YdXzAmhRDZfSVu+uw+rPPuyFHLttbA65bSn1RvaLd
bn5VXGGeP71QnhtNX2HKRhsLIiwtIcePt4vTRiuRjKWrZ7tR7jVDQ+CtzCNpj1y0
9PlHBDs3uyuBwp/xbtYqB/YMLnC3CRVMHMF93jiD4NQzZXRCIcn2LzxUkBa6KGh/
t4NIFCkfiJtK0enGe/nZOy1rh9cza9tFBi4UbxXDmfR+8mX8wHyl52LBUnltAjC8
D07xUZVUESW5qnP+QTSwLosOs9b6u4GhvcehnQCSUVXWeZFhkVfn/Kfk/1C7ArTQ
TrU1YwNLVco=
=nf8R
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changelogs

[Jason Stubbs]

[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

On Thursday 28 July 2005 09:02, Alec Warner wrote:
> In hindsight, arguing over almost two different things.  We both agree
> that upgrade paths for changes that break the system are good, and that
> information regarding the upgrade path *SHOULD* be provided in some
> manner.  Some developers think that providing detailed instructions in
> pkg_postinst() is good, others will direct you to a website ( usually
> UPSTREAM's webpage ) which has the instructions; it saves them time.
> Which is correct, or are both?

Both are correct. Some developers are willing to put the effort into getting
upgrade info immediately before the user and some are happy with the user
putting 50% of the effort. Either is fine, but you're also missing major
changes that happen in ebuilds themselves.

The real point, though, is that there should be a consistent way for this
information to be delivered to users. Whether is be via ChangeLog,
metadata.xml or pkg_warn(), the requirement is that developers are able
to provide as little or much information as they want in such a way that
users get easy access to it.

> In the former case where more specific information is provided to the
> user by portage you generally want a more complex system.  You want the
> 
> "<warn from="2.6.4:2[baduse]" to="2.7[-baduse]">You enabled baduse?
> Removing it will rm -rf /!</warn>" syntax ( from our conversation last
> night ) which is decidedly more complex to write and more complex to parse,
> 
> Don't get me wrong, I like it, but I doubt it will get used by enough
> people to be useful.

I never said I wanted that. I just used it to illustrate how it could be
easily handled in metadata.xml rather than pkg_warn() if necessary. Nor
is it complex to write or parse. My heart is not set on the above in any way
whatsoever, though.

I think you might be jumping to a solution without fully considering the
problem. On the whole, this is a relatively small problem anyway, so
an immediate solution is not really necessary.

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On Tue, Jul 26, 2005 at 10:05:49PM -0400, Alec Warner wrote:
> Recent discussion on this ML and on the portage-ml as well as
> #gentoo-portage regarding pkg_warn() and the basic concept behind it.
> We talked about adding new functionality, about adding a warning section
> to the ebuild or to the metadata.  However.  all of these tend to have
> problems.  

> The dev won't write the extra function, 
In your proposal this would be "the dev won't write the extra changelog
content" and ...

> duplication of data in pkg_{post/pre}inst, 
... "duplication of data in Changelog/pkg_post".


> mangling of metadata.xml.
I don't know what this means, but I don't think pkg_warn has this
problem.

So I don't see any advantage of putting it in the changelog. I actually
like the pkg_warn idea much better. 

So tell me again, what does your proposal solve of the problems you see
with pkg_warn?

Regards,
Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Changelogs

[Alec Joseph Warner]

Maurice van der Pot wrote:
> On Tue, Jul 26, 2005 at 10:05:49PM -0400, Alec Warner wrote:
> 
>>Recent discussion on this ML and on the portage-ml as well as
>>#gentoo-portage regarding pkg_warn() and the basic concept behind it.
>>We talked about adding new functionality, about adding a warning section
>>to the ebuild or to the metadata.  However.  all of these tend to have
>>problems.  
> 
> 
>>The dev won't write the extra function, 
> 
> In your proposal this would be "the dev won't write the extra changelog
> content" and ...
> 
> 
>>duplication of data in pkg_{post/pre}inst, 
> 
> ... "duplication of data in Changelog/pkg_post".
> 
> 
> 
>>mangling of metadata.xml.
> 
> I don't know what this means, but I don't think pkg_warn has this
> problem.
> 
> So I don't see any advantage of putting it in the changelog. I actually
> like the pkg_warn idea much better. 
> 
> So tell me again, what does your proposal solve of the problems you see
> with pkg_warn?
  -l support for reading changelogs is already in portage, pkg_warn 
support would only be in CVS which won't be out for a long time(*), and 
pkg_warn() doesn't fit in with the rest of the ebuild functions.  This 
solution is done now, in the changelog, to be viewed by users.  Metadata 
ideas were not liked because metadata is not versioned and the parsing 
would not be easy.

* Long time being whenever, not starting a flamewar about it.

> Regards,
> Maurice.
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changelogs

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alec Joseph Warner wrote:
| solution is done now, in the changelog, to be viewed by users.  Metadata
| ideas were not liked because metadata is not versioned and the parsing
| would not be easy.

The metadata dtd explicitly supports versioning. It looks like it even
supports full changelog functionality.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC59KDXVaO67S1rtsRAsooAJ9dUqpTDUX/p/E6vm8wNzYBhwhLpwCgtGaW
7lwLAwI84ydE4YZK4aHEYjw=
=gQz1
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

RE: [gentoo-dev] changelogs...

[Rex Young]

>unfotunately this is oftem the case. Right now as I write on my machine
>if I execute the following.you will see that only the vim 
>updates have a
>proper release notes right on the front page. Orbit and gnome-vfs point
>directly to gnome.org where I havent been able to find any 
>release note.
>(I looked for release notes of ORBit for like more than an 
>hour.... then
>I posted the message). fileroller website hasnt even announced any such
>release... only the tarballs available on on gnome (boy is gentoo
>cutting edge :) ). gaim also doesnt provide any realease note 
>on the web
>site. I suppose all these packages provide release notes in the source
>tarball... but thats not very convenient.. it defeats some of the
>purpose of the gentoo system to download the file and expand just to
>read the release note.


I would like to echo this.  More than twice, I've looked to a web page
to learn a little more about a package only to find scant information,
or worse, a dead link.

I like this idea so much, that I'll offer to get it rolling.  If it should
be decided that this will be done, I'm sure that there will be quite a
number
of previously released packages which would like a longer description added
to them.  I'm only an engineer, not a software developer, but this is
something
I think I can handle.

-rex

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] changelogs...

[Dylan Carlson]

On Thu May 22 2003 6:31 pm, Rex Young wrote:
> I'm only an engineer, not a software developer, but this
> is something
> I think I can handle.

I remember when "engineer" meant "software developer".  :-P

/me shrugs

Cheers,
Dylan Carlson

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
Key fingerprint = 3AEA DE38 FE42 15A6 C0E2 730E 3D04 BCC1 708E 165F


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] changelogs

[Jon Nelson]

One thing I find I miss in gentoo from other distros is a
changelog
of what is different from ebuild to ebuild.  Debian, I think,
has this down pat, although rpm is capable of it as well.

After (or perhaps as part of) an emerge rsync, I'd like to know
what is new, what has been removed, and the *human reasoning*
behind those decisions.

IE,

foo-1.0 removed -- superceced by foo-1.1

bar-5.3 added -- changes from bar-5.2 include:
"blah blah blah blah,
and blah
and more blah
We tried to fix this bug, and that bug.
Added optional USE support for hammer and nail capability"

etc...

Re: [gentoo-dev] changelogs

[Grant Goodyear]

> One thing I find I miss in gentoo from other distros is a
> changelog
> of what is different from ebuild to ebuild.  Debian, I think,
> has this down pat, although rpm is capable of it as well.
> 
> After (or perhaps as part of) an emerge rsync, I'd like to know
> what is new, what has been removed, and the *human reasoning*
> behind those decisions.
> 
> IE,
> 
> foo-1.0 removed -- superceced by foo-1.1
> 
> bar-5.3 added -- changes from bar-5.2 include:
> "blah blah blah blah,
> and blah
> and more blah
> We tried to fix this bug, and that bug.
> Added optional USE support for hammer and nail capability"

In lieu of anything more formal, there's always cvsweb, which is
the method I generally use.  Also, it's useful for developers to
be subscribed to gentoo-cvs.

-g2boojum-
-- 
___________________________________________________________________
|     Grant Goodyear                  |  The Secrets of Physics:   |
|     Dept. of Chemistry - Clemson U  |1. Add zero.                |
|     Clemson, SC  29634              |2. Multiply by one.         |
|-------------------------------------|3. Expand in a Taylor series|
|e-mail: goodyea@clemson.edu          |4. Integrate by parts.      |
|www:bernacchi.chem.uh.edu/~grant     |5. Fourier transform.       |
|                                     |6. Add auxiliary variables  |
|_____________________________________|____________________________|
 

Re: [gentoo-dev] changelogs

[Jon Nelson]

On Mon, 5 Nov 2001 13:36:27 -0500
Grant Goodyear <grant@g2.ces.clemson.edu> wrote:

> > One thing I find I miss in gentoo from other distros is a
> > changelog
> > of what is different from ebuild to ebuild.  Debian, I think,
> > has this down pat, although rpm is capable of it as well.
...
 
> In lieu of anything more formal, there's always cvsweb, which
> is
> the method I generally use.  Also, it's useful for developers
> to
> be subscribed to gentoo-cvs.

Oh, yeah, sure. However, it's something of a pain, and often
times
its not very useful anyhow, when different ebuilds don't have
a cvs changelog that is very useful.  Think "new checkin" versus
"fixed bug in -r1 causing foo to barf"

Incidentally, I find it interesting that gentoo is so
python-based
and yet uses cvsweb instead of viewcvs (IMHO, superior).