Devmanual text on ChangeLogs

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Robin H. Johnson-2
On Mon, May 02, 2011 at 06:50:01AM +0530, Nirbheek Chauhan wrote:
> I don't get why someone would want to edit ChangeLogs. Could you list
> some use-cases besides editing of typos?
One that I have seen before was the change of a URL for users to migrate
their data, when upstream changed the URL. The URL in question was in
the ebuild and the changelog.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : [hidden email]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Nirbheek Chauhan-2
On Mon, May 2, 2011 at 6:54 AM, Robin H. Johnson <[hidden email]> wrote:
> On Mon, May 02, 2011 at 06:50:01AM +0530, Nirbheek Chauhan wrote:
>> I don't get why someone would want to edit ChangeLogs. Could you list
>> some use-cases besides editing of typos?
> One that I have seen before was the change of a URL for users to migrate
> their data, when upstream changed the URL. The URL in question was in
> the ebuild and the changelog.
>

This is not a case for editing of ChangeLogs. I see three standard
ways for this information to be conveyed, in decreasing order of
likelihood of the user reading it:

(1) A Gentoo news file
(2) The ebuild itself via elog/ewarn
(3) The ChangeLog entry which changed the URL in the ebuild

In any case, ChangeLogs have always been historical records of the
changes that occurred in a package. What people seem to want is a
hybrid of ChangeLogs and NEWS files. I don't see how the costs of this
(inevitable merge conflicts, duplicated information, increased git
tree size) outweigh the benefits (the rare user who looks at the
ChangeLog but not the ebuild).


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Jeroen Roovers-3
In reply to this post by pva0xd
On Sat, 30 Apr 2011 16:12:01 +0400
Peter Volkov <[hidden email]> wrote:

> В Сбт, 30/04/2011 в 12:02 +0300, Samuli Suominen пишет:
> > On 04/30/2011 11:46 AM, Petteri Räty wrote:
> > > I propose a simple new text: "Every commit should have an entry in
> > > ChangeLog."
>
> Nonfunctional commits should not be recored in ChangeLog. Personally I
> quite frequently add URLs of upstream bug reports in ChangeLog. I
> don't think this addition should be recorded in ChangeLog.

To put it differently, commits that only change the ChangeLog should
not be recorded in the ChangeLog (or we would never get anything
done ;-).


     jer

Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Jeroen Roovers-3
In reply to this post by Brian Harring-2
On Sun, 1 May 2011 13:43:25 -0700
Brian Harring <[hidden email]> wrote:

> Beyond that... I suspect *everyone* would appreciate optimization
> done to echangelog.  From a quick look... seems like it's cvs status,
> than a cvs diff.  Trying to collapse that into a single op, falling
> back to status might not be a bad thing (or parallelizing the
> requests so the slowness of cvs doesn't cause sequentially stack up).
>
> Either way.. fix the tool, rather than just doing the wrong thing.

I couldn't figure out what could possibly make echangelog slow, but then
I figured that this fix is easy and outside the scope of echangelog:

ssh -f -n -N master-cvs.gentoo.org

Doing only one of the cvs commands might help too, of course.


     jer

Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Jeroen Roovers-3
In reply to this post by Panagiotis Christopoulos
On Sat, 30 Apr 2011 14:21:37 +0300
Panagiotis Christopoulos <[hidden email]> wrote:

>   Taking the latest portage snapshot from a mirror, the sum* of the
> apparent sizes of all its files (forgetting directories, filesystems.
> overhead etc.) is ~189Mb. The sum of ChangeLog files is ~66Mb, that
> is a ~35% fraction.

Anyone with a real problem with that could just do this?

PORTAGE_RSYNC_EXTRA_OPTS="--exclude='ChangeLog'"


     jer

Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Ulrich Müller
In reply to this post by Nirbheek Chauhan-2
>>>>> On Mon, 2 May 2011, Nirbheek Chauhan wrote:

> I don't get why someone would want to edit ChangeLogs. Could you
> list some use-cases besides editing of typos?

Fixing typos should be enough reason alone. It also happened to me
more than once that I specified a wrong bug number, or that I added
credits for a user retroactively.

Ulrich

Reply | Threaded
Open this post in threaded view
|

Re: Re: Devmanual text on ChangeLogs

Fabian Groffen-2
In reply to this post by Rich Freeman
On 01-05-2011 19:43:48 -0400, Rich Freeman wrote:
> My personal feeling is that we should keep the changelogs as-is, and
> include removals, until we're on git.  Then we should re-evaluate.

git doesn't magically solve all the problems!


--
Fabian Groffen
Gentoo on a different level

Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Fabian Groffen-2
In reply to this post by Ulrich Müller
On 02-05-2011 02:04:57 +0200, Ulrich Mueller wrote:

> > Having the servers do that, will also allow us to provide cut down
> > Changelogs ( lets say keep that last 10 entries ) so we can provide
> > a more minimal portage tree, size wise.
>
> Ten is way too small. Chances are that after one round of
> stabilisations the ChangeLog entry for the last real change to the
> package will be gone. We should keep at least one year (better two)
> of history, because our aim is that users' systems should still be
> upgradeable after this time. And IMHO emerge -l should give the user
> the full list of changes since his last update.

How about forgetting the time constraint, but just keeping all changelog
entries for all ebuilds that are in the tree?


--
Fabian Groffen
Gentoo on a different level

Reply | Threaded
Open this post in threaded view
|

Re: Re: Devmanual text on ChangeLogs

Arfrever Frehtes Taifersar Arahesis-3
In reply to this post by Markos Chandras-2
2011-05-02 02:16:49 Markos Chandras napisał(a):

> On Sun, May 01, 2011 at 04:31:08PM -0700, Brian Harring wrote:
> > On Sun, May 01, 2011 at 11:23:40PM +0000, Duncan wrote:
> > > What about having a dedicated server-based changlog-signing key?  That's
> > > still a lot of signing with a single key, but as you observed, the hazards
> > > of a loss of integrity there aren't as high as with most of the tree
> > > content.  It'd require changes, but I don't believe they're out of line
> > > with that required for the rest of the proposal.
> >
> > It means the only real trust that clients can level is on that key-
> > since it will be the last signer (thus /the/ signer) across all pkgs.
> >
> > Get at that key, and you've got the tree, versus the current form,
> > crack all signing keys and you've got the tree.
> >
> > Mind you this is ignoring eclasses, but getting eclasses sorted will
> > be mildly pointless if the rest of the solution has been
> > weakened/gutted since.
> >
> > Point is, it's not *just* about having a signature on it- it's about
> > mapping the trust of that signature back, and sectioning/containing
> > compromises.  What y'all are suggesting guts that layered defense.
> > ~brian
>
> Then the only choice here is to ignore Changelogs from Manifests and
> live with that. You have your changelogs unprotected but you keep your
> ebuilds safe(?). As I said, it is a balanced choice that has to be made.
Generated ChangeLogs could contain server-side-generated signatures for themselves
(gpg --sign --clearsign ChangeLog && mv ChangeLog.asc ChangeLog).
(Manifests wouldn't contain entries for ChangeLogs.)

--
Arfrever Frehtes Taifersar Arahesis

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Devmanual text on ChangeLogs

Gilles Dartiguelongue-3
In reply to this post by Petteri Räty-2
Le samedi 30 avril 2011 à 11:46 +0300, Petteri Räty a écrit :

> http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
>
> There doesn't seem to be a common opinion on what the policy for
> ChangeLog entries is. See:
>
> http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml
>
> I propose a simple new text: "Every commit should have an entry in
> ChangeLog." If we eventually autogenerate them from git logs this would
> happen any way (unless some kind of filtering system is in the middle)
> so we could already start now. I think it's better to have more than
> less information available to users.
>
> Regards,
> Petteri
>
As in any other open source project, history (even of removed files)
matters just as much as the outcome. Please make it a policy to always
have a ChangeLog entry for any changes.

--
Gilles Dartiguelongue <[hidden email]>
Gentoo

signature.asc (205 bytes) Download Attachment
123