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
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).
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
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.
> 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?
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?
> 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.)