Re: [gentoo-dev] ChangeLog generation, profiles/ mess.
> On Tue, 29 Nov 2016, Robin H Johnson wrote: >> - one ChangeLog for each first-level subdir other than categories >> (i.e. eclass, licenses, profiles, etc.), > Already done, just querying if profiles/ needs more ChangeLog detail. Yeah, keep one ChangeLog for all of profiles/. The existing sub-ChangeLogs there are rather confusing because they don't seem to follow any consistent layout. Keeping one single file would also agree with the recommendation for commit messages, namely to prepend "profiles:" for any change below the profiles/ dir. https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Commit_message_format > Here's the size of the non-category non-package changelogs, with > splitting to all top-levels. > 127 scripts/ChangeLog-2016 >1266 metadata/ChangeLog-2016 >1929 ChangeLog-2016 > 11987 licenses/ChangeLog-2016 > 198021 eclass/ChangeLog-2016 > 362733 profiles/ChangeLog-2016 > If we collapse to have: > - per-package > - major top-levels: eclass/, profile/, licenses/ > - (everything else) > Then we get: > 11972 licenses/ChangeLog-2016 > 12941 ChangeLog-2016 > 196905 eclass/ChangeLog-2016 > 362040 profiles/ChangeLog-2016 I like the second scheme better. (No strong opinion about keeping separate ChangeLogs for metadata/ and scripts/ though.) Ulrich pgpJIMernMHEX.pgp Description: PGP signature
Re: [gentoo-dev] ChangeLog generation, profiles/ mess.
My question was explicitly asking about profiles/, but I'll respond to the other pieces in turn. On Tue, Nov 29, 2016 at 11:59:57PM +0100, Ulrich Mueller wrote: > I'd say keep it simple: > - one ChangeLog for each package dir, Already done. > - no ChangeLog for category dirs (they contain only a single metadata.xml), Presently implemented, but considering turning it off, because it's mostly duplicated entries (tree-wide changes to $CAT/metadata.xml). The rate-of-change on category dirs is very slow, and they are tiny: 92562 bytes over 163 files (mean is 567 bytes). See below for more size on what happens if they get collapsed to the top-level. > - one ChangeLog for each first-level subdir other than categories > (i.e. eclass, licenses, profiles, etc.), Already done, just querying if profiles/ needs more ChangeLog detail. > - top-level ChangeLog for anything not covered by the other ChangeLogs. Other than the per-category changelogs, here's the size Here's the size of the non-category non-package changelogs, with splitting to all top-levels. 127 scripts/ChangeLog-2016 1266 metadata/ChangeLog-2016 1929 ChangeLog-2016 11987 licenses/ChangeLog-2016 198021 eclass/ChangeLog-2016 362733 profiles/ChangeLog-2016 If we collapse to have: - per-package - major top-levels: eclass/, profile/, licenses/ - (everything else) Then we get: 11972 licenses/ChangeLog-2016 12941 ChangeLog-2016 196905 eclass/ChangeLog-2016 362040 profiles/ChangeLog-2016 -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] ChangeLog generation, profiles/ mess.
On Tue, 29 Nov 2016 23:59:57 +0100 Ulrich Mueller wrote: > > On Tue, 29 Nov 2016, Robin H Johnson wrote: > > > TL;DR: Let's replace profiles/**/ChangeLog with profiles/ChangeLog, > >because it's a mess. > > > I'm writing the new changelog generation code [1][2], and I'm > > wondering if we can clean up the mess that we have in profiles/. > > > The existing Portage egencache --update-changelogs command does NOT > > generate any ChangeLogs for profiles/ (or eclasses, licenses, > > scripts, metadata, toplevel skel.*). > > I'd say keep it simple: > - one ChangeLog for each package dir, > - one ChangeLog for each first-level subdir other than categories > (i.e. eclass, licenses, profiles, etc.), > - no ChangeLog for category dirs (they contain only a single > metadata.xml), > - top-level ChangeLog for anything not covered by the other > ChangeLogs. > > Ulrich +1, keep it simple -- Brian Dolbec pgpY7ZcxtzCHE.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ChangeLog generation, profiles/ mess.
> On Tue, 29 Nov 2016, Robin H Johnson wrote: > TL;DR: Let's replace profiles/**/ChangeLog with profiles/ChangeLog, >because it's a mess. > I'm writing the new changelog generation code [1][2], and I'm > wondering if we can clean up the mess that we have in profiles/. > The existing Portage egencache --update-changelogs command does NOT > generate any ChangeLogs for profiles/ (or eclasses, licenses, > scripts, metadata, toplevel skel.*). I'd say keep it simple: - one ChangeLog for each package dir, - one ChangeLog for each first-level subdir other than categories (i.e. eclass, licenses, profiles, etc.), - no ChangeLog for category dirs (they contain only a single metadata.xml), - top-level ChangeLog for anything not covered by the other ChangeLogs. Ulrich pgp2s5WVNSzXD.pgp Description: PGP signature
[gentoo-dev] ChangeLog generation, profiles/ mess.
TL;DR: Let's replace profiles/**/ChangeLog with profiles/ChangeLog, because it's a mess. I'm writing the new changelog generation code [1][2], and I'm wondering if we can clean up the mess that we have in profiles/. The existing Portage egencache --update-changelogs command does NOT generate any ChangeLogs for profiles/ (or eclasses, licenses, scripts, metadata, toplevel skel.*). There is no strict pattern to the past CVS ChangeLogs for profiles. Some directories have their own ChangeLogs covering everything in that scope, but occasionally there is also deeper ChangeLogs that mean the top-level changelog doesn't cover it anymore. Notable examples: profiles/default/bsd/fbsd/amd64/9.1/clang/ChangeLog-2015 profiles/default/bsd/ChangeLog-2015 (of all default/bsd/, why did only bsd/fbsd/amd64/9.1/clang warrant it's own changelog?) profiles/features/ChangeLog-2015 profiles/features/prefix/ChangeLog-2015 (why did features/prefix/ get it's own changelog?) profiles/releases/freebsd-8.2/ChangeLog-2015 profiles/releases/freebsd-9.1/ChangeLog-2015 (the rest of profiles/releases/, including other freebsd releases, is all in the root profiles/ChangeLog). [1] https://wiki.gentoo.org/wiki/User:Robbat2:ChangeLog-Generation#Git_output_command [2] https://gitweb.gentoo.org/infra/mastermirror-scripts.git/tree/egenchangelog2.py [3] All profiles/ ChangeLogs from CVS: profiles/arch/alpha/ChangeLog-2015 profiles/arch/amd64/ChangeLog-2015 profiles/arch/amd64-fbsd/ChangeLog-2015 profiles/arch/arm64/ChangeLog-2015 profiles/arch/arm/ChangeLog-2015 profiles/arch/hppa/ChangeLog-2015 profiles/arch/ia64/ChangeLog-2015 profiles/arch/m68k/ChangeLog-2015 profiles/arch/mips/ChangeLog-2015 profiles/arch/powerpc/ChangeLog-2015 profiles/arch/s390/ChangeLog-2015 profiles/arch/sh/ChangeLog-2015 profiles/arch/sparc/ChangeLog-2015 profiles/arch/sparc-fbsd/ChangeLog-2015 profiles/arch/x86/ChangeLog-2015 profiles/arch/x86-fbsd/ChangeLog-2015 profiles/base/ChangeLog-2015 profiles/ChangeLog-2007 profiles/ChangeLog-2008 profiles/ChangeLog-2009 profiles/ChangeLog-2010 profiles/ChangeLog-2011 profiles/ChangeLog-2012 profiles/ChangeLog-2013 profiles/ChangeLog-2014 profiles/ChangeLog-2015 profiles/default/bsd/ChangeLog-2015 profiles/default/bsd/fbsd/amd64/9.1/clang/ChangeLog-2015 profiles/default/linux/alpha/ChangeLog-2015 profiles/default/linux/amd64/ChangeLog-2015 profiles/default/linux/arm64/ChangeLog-2015 profiles/default/linux/arm/ChangeLog-2015 profiles/default/linux/ChangeLog-2015 profiles/default/linux/hppa/ChangeLog-2015 profiles/default/linux/ia64/ChangeLog-2015 profiles/default/linux/m68k/ChangeLog-2015 profiles/default/linux/mips/ChangeLog-2015 profiles/default/linux/powerpc/ChangeLog-2015 profiles/default/linux/s390/ChangeLog-2015 profiles/default/linux/sh/ChangeLog-2015 profiles/default/linux/sparc/ChangeLog-2015 profiles/default/linux/uclibc/ChangeLog-2015 profiles/default/linux/x86/ChangeLog-2015 profiles/embedded/ChangeLog-2015 profiles/features/ChangeLog-2015 profiles/features/prefix/ChangeLog-2015 profiles/hardened/ChangeLog-2015 profiles/prefix/ChangeLog-2012 profiles/prefix/ChangeLog-2015 profiles/releases/freebsd-8.2/ChangeLog-2015 profiles/releases/freebsd-9.1/ChangeLog-2015 -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On 11/18/2015 12:55 PM, Michael Orlitzky wrote:
>
> That's taking about half a second if I run it from the command-line.
>
...and this takes even longer:
cinfo = self.grab(['git', self._work_tree, 'diff-tree',
'--name-status',
'--no-renames',
'--format=%ct %cN <%cE>%n%B',
'--root',
'--relative=%s' % (cp, ),
'-r',
c,
'--', '.']).rstrip('\n').split('\n')
That happens for every commit.
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On 11/18/2015 09:48 AM, Peter Stuge wrote:
> Peter Stuge wrote:
>> Robin H. Johnson wrote:
>>> However, the largest sticking point, even with parallel threads, is that
>>> it seems the base ChangeLog generation is incredibly slow. It averages
>>> above 350ms per package right now (at 19k packages in a full cycle, it's
>>> a long time), but some packages can take up to 5 seconds so far.
>>
>> Which code is doing this generation? Sorry - ENOOVERVIEW. :\
>
> Bump. Does anyone know where I can take a look at this code?
>
I don't know, but since no one else is answering, I'll try to find out.
There are a few bugs on b.g.o. (search "changelog") that suggest
`egencache --update-changelog` is being used. The egencache command is
part of portage, so
$ git clone http://anongit.gentoo.org/git/proj/portage.git
Looking at bin/egencache, you'll find a bunch of indirection, but
ultimately, the generate_changelog() method of the GenChangeLogs class
is doing the work. The implementation is straightforward. I suspect the
slow part is,
# now grab all the commits
revlist_cmd = ['git', self._work_tree, 'rev-list']
if self._changelog_reversed:
revlist_cmd.append('--reverse')
revlist_cmd.extend(['HEAD', '--', '.'])
commits = self.grab(revlist_cmd).split()
where
@staticmethod
def grab(cmd):
p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
return _unicode_decode(p.communicate()[0],
encoding=_encodings['stdio'],
errors='strict')
That's taking about half a second if I run it from the command-line.
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
Peter Stuge wrote: > Robin H. Johnson wrote: > > However, the largest sticking point, even with parallel threads, is that > > it seems the base ChangeLog generation is incredibly slow. It averages > > above 350ms per package right now (at 19k packages in a full cycle, it's > > a long time), but some packages can take up to 5 seconds so far. > > Which code is doing this generation? Sorry - ENOOVERVIEW. :\ Bump. Does anyone know where I can take a look at this code? //Peter
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
Robin H. Johnson wrote: > However, the largest sticking point, even with parallel threads, is that > it seems the base ChangeLog generation is incredibly slow. It averages > above 350ms per package right now (at 19k packages in a full cycle, it's > a long time), but some packages can take up to 5 seconds so far. Which code is doing this generation? Sorry - ENOOVERVIEW. :\ Thanks //Peter
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, 12 Nov 2015 13:57:58 +0300 Alexander Tsoy wrote: > On Thu, 12 Nov 2015 18:49:38 +0800 > Jason Zaman wrote: > > > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: > > > On Wed, 11 Nov 2015 23:11:48 + > > > "Robin H. Johnson" wrote: > > > > > > > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > > > > It's not perfectly clean but I don't see any problem here: > > > > > ChangeLog-2015 : all ChangeLog from CVS > > > > > ChangeLog: autogenerated from git > > > > FYI, this was implemented. > > > > > > > > > Thanks! > > > > > > How should one report bugs ? to infra or portage ? > > > From my just rsynced tree, I see changelogs in reverse order: oldest > > > come first, latest come last > > > > NOTABUG, it was changed because rsync can deal really well with > > appending to the end of files. rsyncing a file where things were things > > were added to the beginning of the file means rsync will copy the whole > > file from scratch which is pretty sub-optimal. > > > > PORTAGE_RSYNC_OPTS by default contains "--whole-file". So I guess > appending to the ChangeLog files doesn't really help. :) Additionally rsync module appends --whole-file to rsync_opts: https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/sync/modules/rsync/rsync.py#n361 -- Alexander Tsoy
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
> On Thu, 12 Nov 2015, Jason Zaman wrote: > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: >> How should one report bugs ? to infra or portage ? >> From my just rsynced tree, I see changelogs in reverse order: oldest >> come first, latest come last > NOTABUG, it was changed because rsync can deal really well with > appending to the end of files. rsyncing a file where things were > things were added to the beginning of the file means rsync will copy > the whole file from scratch which is pretty sub-optimal. Our ChangeLogs were always in newest-first order, so why would this suddenly be an issue? Also readability for users should take priority over technical matters. Newest first is the usual order (e.g. it agrees with the default of git log), and ChangeLog having different order from ChangeLog-20* seems rather confusing to me. Ulrich pgp4Izj86cT6F.pgp Description: PGP signature
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, 12 Nov 2015 18:49:38 +0800 Jason Zaman wrote: > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: > > On Wed, 11 Nov 2015 23:11:48 + > > "Robin H. Johnson" wrote: > > > > > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > > > It's not perfectly clean but I don't see any problem here: > > > > ChangeLog-2015 : all ChangeLog from CVS > > > > ChangeLog: autogenerated from git > > > FYI, this was implemented. > > > > > > Thanks! > > > > How should one report bugs ? to infra or portage ? > > From my just rsynced tree, I see changelogs in reverse order: oldest > > come first, latest come last > > NOTABUG, it was changed because rsync can deal really well with > appending to the end of files. rsyncing a file where things were things > were added to the beginning of the file means rsync will copy the whole > file from scratch which is pretty sub-optimal. > PORTAGE_RSYNC_OPTS by default contains "--whole-file". So I guess appending to the ChangeLog files doesn't really help. :) -- Alexander Tsoy
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, 12 Nov 2015 18:49:38 +0800 Jason Zaman wrote: > On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: > > On Wed, 11 Nov 2015 23:11:48 + > > "Robin H. Johnson" wrote: > > > > > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > > > It's not perfectly clean but I don't see any problem here: > > > > ChangeLog-2015 : all ChangeLog from CVS > > > > ChangeLog: autogenerated from git > > > FYI, this was implemented. > > > > > > Thanks! > > > > How should one report bugs ? to infra or portage ? > > From my just rsynced tree, I see changelogs in reverse order: oldest > > come first, latest come last > > NOTABUG, it was changed because rsync can deal really well with > appending to the end of files. rsyncing a file where things were > things were added to the beginning of the file means rsync will copy > the whole file from scratch which is pretty sub-optimal. k, rsync limitation then :)
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, Nov 12, 2015 at 11:46:19AM +0100, Alexis Ballier wrote: > On Wed, 11 Nov 2015 23:11:48 + > "Robin H. Johnson" wrote: > > > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > > It's not perfectly clean but I don't see any problem here: > > > ChangeLog-2015 : all ChangeLog from CVS > > > ChangeLog: autogenerated from git > > FYI, this was implemented. > > > Thanks! > > How should one report bugs ? to infra or portage ? > From my just rsynced tree, I see changelogs in reverse order: oldest > come first, latest come last NOTABUG, it was changed because rsync can deal really well with appending to the end of files. rsyncing a file where things were things were added to the beginning of the file means rsync will copy the whole file from scratch which is pretty sub-optimal.
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Wed, 11 Nov 2015 23:11:48 + "Robin H. Johnson" wrote: > On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > > It's not perfectly clean but I don't see any problem here: > > ChangeLog-2015 : all ChangeLog from CVS > > ChangeLog: autogenerated from git > FYI, this was implemented. Thanks! How should one report bugs ? to infra or portage ? From my just rsynced tree, I see changelogs in reverse order: oldest come first, latest come last
Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle
On Thu, Nov 05, 2015 at 12:54:06PM +0100, Alexis Ballier wrote: > It's not perfectly clean but I don't see any problem here: > ChangeLog-2015 : all ChangeLog from CVS > ChangeLog: autogenerated from git FYI, this was implemented. For reference, the old CVS changelogs are now taken from HEAD of this repo: https://gitweb.gentoo.org/data/gentoo-changelogs.git/ mgorny and I have been poking at the generation issue, with the features I requested now implemented, plus one patch I pushed up to portage-dev. There are still some issues remaining. I filed bugs for some of them: 565536 - need to exclude some commits/paths 565538 - need to exclude some lines 565540 - need parallel threads However, the largest sticking point, even with parallel threads, is that it seems the base ChangeLog generation is incredibly slow. It averages above 350ms per package right now (at 19k packages in a full cycle, it's a long time), but some packages can take up to 5 seconds so far. Incremental processing does help this hugely, but isn't always available. Right now, I'm considering promising 30 minute syncs as a best case interval; if changelog generation causes it to take longer, then a push window WILL be missed. How often might this happen? Since we converted to Git, excluding the initial large commits, there were three instances where it would have added more than 10 minutes without the improvements I created bugs for. Plus, any other changes that cause loss of timestamps/reference for comparison will trigger a full run, at ~6 hours of delay. (Yes, that's why there hasn't been an rsync update in the last 3 hours, and won't be for another ~3 hours: because it's crunching to generate ChangeLogs). -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] ChangeLog - Infra Response
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Donnerstag, 5. November 2015, 12:54:06 schrieb Alexis Ballier: > > if/when there is a need to split git changelogs, autogenerated > changelogs will start from say, Jan. 1st 2016, and previous changes > will now be static. Merging CVS2015 and git2015 changelogs is just a > matter of running a script. Or just skip splitting them for 2016, and > start splitting in 2017, so that ChangeLog-2015 is CVS ones, > ChangeLog-2016 is git logs from Aug. 8. 2015 to Dec. 31 2016. > > IMHO this is still better than having ChangeLog stopping in 2015 and > ChangeLog.git starting from this date: Having ChangeLog-2015 from CVS > still carries partial information on the timeline. > > > Alexis. +1 - -- Andreas K. Huettel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWPzNBAAoJEB9VdM6hupKVwPYP/joJImpsmJ+jZQ89Mm6HzaOT FSTmL3zpRxw1XNYQGPO7WUyDwtbVaD+RufiSOINME6+KqhGrII2LxUYeEjd+MvA3 jjA2pNKK/wmYV+inGDvjdXjZ5QpJLVSjpnwf+Igv1NvbA6g87xFkTz55vSZaELIq ytmeIS8gzSN89QeOzq+4YljvfQcEzWR73URCwegjmD/Bh7i/rmDQ2gGswMuVZg+z VsX1OMTeiAo7mRFeT5hzfcquRP4UAULSy4jU9L1Aw5tVMhp6A81easV1TH3oL2S4 WgWu9UutdhZpUqF4W1ZNLMbu5ePseP0DcVuLwo8PoWtxteh0I+oMqaNj/M8xKnPT tolJR0UwHgEQoilJHFH+E6SEICe+hmGgDFlpuRlmdC0UC/YOdQbC/aeaJWZMnNYB 5sMpQ4OgXyXWzIQ4rEBnJeqnh1IThg0CZuubG1X10x9+T0yCUiEDKerlfMgPGz1d GaFF/q91rjxsIrxe487so9BPjdO7oaZ2L2IYSq8GMyXHtMCftLaYIAPlvZZtdgjh QYEmk1k1epWg+LeOKoOvMjvuLcsUmDmAdOr2GtQDb0egdcWFKXwWDfgcV71K8tO4 5QmAcJFz8oQx+n1mtjvjoQU9ummPucJGZVag1mr2kwYjiZrt/3UbIHKvyXyii5ui 9O5dgzM462g50kU30UY7 =3hon -END PGP SIGNATURE-
Re: [gentoo-dev] ChangeLog - Infra Response
On 11/05/2015 12:39 PM, Ulrich Mueller wrote: >> On Thu, 5 Nov 2015, Alexis Ballier wrote: > >> On Mon, 2 Nov 2015 20:18:07 + >> "Robin H. Johnson" wrote: > >>> On Mon, Nov 02, 2015 at 08:05:56AM +0100, Ulrich Mueller wrote: What would be the problem with renaming? IMHO it would be nicer to keep the ChangeLog name for the autogenerated files and rename the ones from CVS. We already have files renamed to ChangeLog- when they became to large, so we could just use ChangeLog-2015 to stay within that scheme. > >>> If we rename the old ChangeLog files from CVS to ChangeLog-2015, then >>> we'll have both 'ChangeLog-2015' and 'ChangeLog' (generated from Git) >>> containing 2015 entries. Worse, what happens when we hit 2016? Do we >>> merge the old files? > >> It's not perfectly clean but I don't see any problem here: >> ChangeLog-2015 : all ChangeLog from CVS >> ChangeLog: autogenerated from git > >> if/when there is a need to split git changelogs, autogenerated >> changelogs will start from say, Jan. 1st 2016, and previous changes >> will now be static. Merging CVS2015 and git2015 changelogs is just a >> matter of running a script. Or just skip splitting them for 2016, and >> start splitting in 2017, so that ChangeLog-2015 is CVS ones, >> ChangeLog-2016 is git logs from Aug. 8. 2015 to Dec. 31 2016. > >> IMHO this is still better than having ChangeLog stopping in 2015 and >> ChangeLog.git starting from this date: Having ChangeLog-2015 from CVS >> still carries partial information on the timeline. > > +1 > > You said it better than I could have. > > Ulrich > yeah, +1 on that too. I am not too bothered with the name to be honest. However, using 'ChangeLog' for git logs sounds like something most of us and users are familiar with already so that should work. -- Regards, Markos Chandras
Re: [gentoo-dev] ChangeLog - Infra Response
> On Thu, 5 Nov 2015, Alexis Ballier wrote: > On Mon, 2 Nov 2015 20:18:07 + > "Robin H. Johnson" wrote: >> On Mon, Nov 02, 2015 at 08:05:56AM +0100, Ulrich Mueller wrote: >> > What would be the problem with renaming? IMHO it would be nicer to >> > keep the ChangeLog name for the autogenerated files and rename the >> > ones from CVS. We already have files renamed to ChangeLog- >> > when they became to large, so we could just use ChangeLog-2015 to >> > stay within that scheme. >> If we rename the old ChangeLog files from CVS to ChangeLog-2015, then >> we'll have both 'ChangeLog-2015' and 'ChangeLog' (generated from Git) >> containing 2015 entries. Worse, what happens when we hit 2016? Do we >> merge the old files? > It's not perfectly clean but I don't see any problem here: > ChangeLog-2015 : all ChangeLog from CVS > ChangeLog: autogenerated from git > if/when there is a need to split git changelogs, autogenerated > changelogs will start from say, Jan. 1st 2016, and previous changes > will now be static. Merging CVS2015 and git2015 changelogs is just a > matter of running a script. Or just skip splitting them for 2016, and > start splitting in 2017, so that ChangeLog-2015 is CVS ones, > ChangeLog-2016 is git logs from Aug. 8. 2015 to Dec. 31 2016. > IMHO this is still better than having ChangeLog stopping in 2015 and > ChangeLog.git starting from this date: Having ChangeLog-2015 from CVS > still carries partial information on the timeline. +1 You said it better than I could have. Ulrich pgpo6SR_8xCd7.pgp Description: PGP signature
Re: [gentoo-dev] ChangeLog - Infra Response
On Mon, 2 Nov 2015 20:18:07 + "Robin H. Johnson" wrote: > On Mon, Nov 02, 2015 at 08:05:56AM +0100, Ulrich Mueller wrote: > > > On Mon, 2 Nov 2015, Robin H Johnson wrote: > > > > > 1. Control of the OUTPUT filename for the generated changelog > > > - the from-git generated changelog will go to 'ChangeLog.git' > > > > > [...] > > > > > Without #1, we have to rename ALL of the old changelogs, otherwise > > > they will be overwritten by the new ones from Git history. > > What would be the problem with renaming? IMHO it would be nicer to > > keep the ChangeLog name for the autogenerated files and rename the > > ones from CVS. We already have files renamed to ChangeLog- > > when they became to large, so we could just use ChangeLog-2015 to > > stay within that scheme. > In the rsync tree, but NOT the Git tree, we have > ChangeLog > ChangeLog- > Where so far goes as far as 2014. > > And 'ChangeLog' files stopped getting updates on August 8th. > > The old ChangeLog files from CVS are explicitly NOT in Git, but > manually injected during the rsync tree creation. > > If we rename the old ChangeLog files from CVS to ChangeLog-2015, then > we'll have both 'ChangeLog-2015' and 'ChangeLog' (generated from Git) > containing 2015 entries. Worse, what happens when we hit 2016? Do we > merge the old files? It's not perfectly clean but I don't see any problem here: ChangeLog-2015 : all ChangeLog from CVS ChangeLog: autogenerated from git if/when there is a need to split git changelogs, autogenerated changelogs will start from say, Jan. 1st 2016, and previous changes will now be static. Merging CVS2015 and git2015 changelogs is just a matter of running a script. Or just skip splitting them for 2016, and start splitting in 2017, so that ChangeLog-2015 is CVS ones, ChangeLog-2016 is git logs from Aug. 8. 2015 to Dec. 31 2016. IMHO this is still better than having ChangeLog stopping in 2015 and ChangeLog.git starting from this date: Having ChangeLog-2015 from CVS still carries partial information on the timeline. Alexis.
Re: [gentoo-dev] ChangeLog
On 11/04/2015 05:44 PM, Chí-Thanh Christopher Nguyễn wrote: > hasufell schrieb: > >> If you want to improve the situation, go talk to git upstream >> and send patches. > > Or do what Andrew suggested should happen. > > If you want to break the whole git workflow yes. Good suggestion.
Re: [gentoo-dev] ChangeLog
hasufell schrieb: If you want to improve the situation, go talk to git upstream and send patches. Or do what Andrew suggested should happen. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] ChangeLog
On 11/04/2015 05:33 PM, Chí-Thanh Christopher Nguyễn wrote: > hasufell schrieb: >> On 11/04/2015 09:56 AM, Andrew Savchenko wrote: >>> No, it is not. The whole git tree is insecure and no better than >>> rsync or CVS in terms of data security because SHA1 is vulnerable. >>> >> Another one who is confusing _any_ collision with _preimage attack_ ;) > > While Andrew's view is very pessimistic here, yours is decidedly > optimistic. > > There is no known computationally feasible preimage attack against MD5, > still that hash function is broken in serious ways with attacks already > having real-world consequences. > > It would be quite naïve to assume that SHA1 will remain secure until a > preimage attack is found. > I didn't. Numerous crypto-analysts have already expressed that SHA-1 is not future-proof. However, saying "it is vulnerable" is simply exaggeration and suggests people should do the math before posting such things. We already had that discussion before the git migration and it is quite pointless. If you want to improve the situation, go talk to git upstream and send patches.
Re: [gentoo-dev] ChangeLog
hasufell schrieb: On 11/04/2015 09:56 AM, Andrew Savchenko wrote: No, it is not. The whole git tree is insecure and no better than rsync or CVS in terms of data security because SHA1 is vulnerable. Another one who is confusing _any_ collision with _preimage attack_ ;) While Andrew's view is very pessimistic here, yours is decidedly optimistic. There is no known computationally feasible preimage attack against MD5, still that hash function is broken in serious ways with attacks already having real-world consequences. It would be quite naïve to assume that SHA1 will remain secure until a preimage attack is found. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/04/2015 05:18 PM, hasufell wrote: > On 11/04/2015 09:56 AM, Andrew Savchenko wrote: >> No, it is not. The whole git tree is insecure and no better than >> rsync or CVS in terms of data security because SHA1 is >> vulnerable. >> > > Another one who is confusing _any_ collision with _preimage attack_ > ;) > Or even worse, 2nd preimage :) In all seriousness, though, it is indeed an important distinction. As for OpenPGP signed distribution of files in rsync as well, it is certainly something I look forwards to and Gentoo Keys project is working hard on. - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJWOjIcAAoJECULev7WN52FivEH/RssmJdQLug2E4B0ZUMUBDum fp5E4PipD9WBFIfqwK36acp/QoJIAjsQrA6B8bfOoK+AVCryQGbMNlR2OAWZzZrG ISn3TTsXjfBeyP0ajiFT1qfTe9OvLNpweyB1GUBvq0vnvtDdmET1DO2d2Yxagmyz 41+QtEWw0s3yypinpgyWqkz5ddJxCAnIXPrOVwwdJJx1yRvAP3rnoM7vvoSCjJps SannPK1ks6ChXtXhEpIX0cHTgm9oXAnn+BhbEGWISuziOfOXmIrBLmPZG9ZYdwEM vttt3uRXc42VBG4zLgKq0Qc5TtD4IsWtGn+Hm4sNYV3atHPS78LW05h82HrE7Fo= =63hW -END PGP SIGNATURE-
Re: [gentoo-dev] ChangeLog
On 11/04/2015 09:56 AM, Andrew Savchenko wrote: > On Sun, 1 Nov 2015 14:53:20 +0100 hasufell wrote: You shouldn't use rsync anymore, it is inherently insecure. The git tree is _properly_ gpg signed so you can verify it's correctness. With the following portage configuration/hooks, any user can run the tree directly from git: https://github.com/hasufell/portage-gentoo-git-config >>> >>> More secure by fetching metadata cache via rsync ? >>> Better by running egencache after each sync ? >>> I don't think so. >>> >> >> Yes it is. > > No, it is not. The whole git tree is insecure and no better than > rsync or CVS in terms of data security because SHA1 is vulnerable. > Another one who is confusing _any_ collision with _preimage attack_ ;)
Re: [gentoo-dev] ChangeLog
On Sun, 1 Nov 2015 14:53:20 +0100 hasufell wrote: > >> You shouldn't use rsync anymore, it is inherently insecure. The git > >> tree is _properly_ gpg signed so you can verify it's correctness. > >> > >> With the following portage configuration/hooks, any user can run the > >> tree directly from git: > >> https://github.com/hasufell/portage-gentoo-git-config > > > > More secure by fetching metadata cache via rsync ? > > Better by running egencache after each sync ? > > I don't think so. > > > > Yes it is. No, it is not. The whole git tree is insecure and no better than rsync or CVS in terms of data security because SHA1 is vulnerable. What we really need for security is GnuPG-signed tree. Right now we have only signed commits and pushes. This is work in progress if understand correctly current situation. Best regards, Andrew Savchenko pgp_CjNHfYh0f.pgp Description: PGP signature
Re: [gentoo-dev] ChangeLog
El dom, 01-11-2015 a las 14:25 +0100, Patrick Lauer escribió: > > On 11/01/2015 01:53 PM, Rich Freeman wrote: > > On Sun, Nov 1, 2015 at 7:33 AM, Мисбах-Соловьёв Вадим > > wrote: > > > And why don't just only generate them on rsync mirrors, but > > > remove them from git repo (like was planned initially, AFAIRC)? > > > > > That is in fact how it works. Or, at least how it is supposed to > > work. I don't use the rsync mirror, so I can't vouch for whether > > they're producing ChangeLogs. > Supposed to, but it doesn't > > > > Personally I'd just as soon see them go away entirely, but if > > somebody > > wants to make them work I won't stop them. > > > I'd really not prefer to fly blind, ChangeLogs are awesome for users. > > I am a user too. I really would like to know why something changed, > and > maybe who did it. > Yeah, I also miss ChangeLogs many times when I want to review last changes without needing to go to open a browser instance and visit gitweb and search for the relevant package for the same purpose :|
Re: [gentoo-dev] ChangeLog
On 2015-11-03 05:24, Jeroen Roovers wrote: > On Mon, 2 Nov 2015 16:17:18 -0500 > "Aaron W. Swenson" wrote: > > > Vadim, please don't top post. > > But do quote some forty lines from the message you reply to. It > really helps in case someone lost the original, right? :-) > > > jer Exactly! I'm glad somebody shares my views. (^_^) signature.asc Description: Digital signature
Re: [gentoo-dev] ChangeLog
On Mon, 2 Nov 2015 16:17:18 -0500 "Aaron W. Swenson" wrote: > Vadim, please don't top post. But do quote some forty lines from the message you reply to. It really helps in case someone lost the original, right? :-) jer
Re: [gentoo-dev] ChangeLog
On 2015-11-03 02:22, Vadim A. Misbakh-Soloviov wrote: > Actually, git log understands if you specify path for it (especially > after --)... > > > 03.11.2015 02:05, Daniel Campbell пишет: > > On 11/01/2015 04:22 AM, Anthony G. Basile wrote: > > > On 11/1/15 7:16 AM, Patrick Lauer wrote: > > >> Ahoi, > > >> > > >> I'm getting mildly very irritated with the lack of easily > > >> accessible ChangeLogs for our packages. > > >> > > >> Apparently updating them stopped some time in August, so now > > >> there are some outdated ChangeLogs that don't really serve any > > >> purpose, and the easiest way for users to figure out why > > >> something changed is to yell at the clumsy gitweb.g.o interface. > > >> So instead of grep we now need lots of patience. > > >> > > >> This does not look reasonable to me. > > >> > > >> Can we please either properly remove ChangeLogs and tell people > > >> to not be curious about changes, or make them useful again? > > >> > > >> Thanks, > > >> > > >> A Gentoo User. > > >> > > > I don't have strong feelings about this, but I'm happy with `git > > > log` to tell me what's going on with packages. I would be okay > > > with the ChangeLog files just being archived and removed. > > > > > > Is there a way for us (devs and users both) to only get `git log` > > results from a specific directory or package? I'm aware we could pipe > > git log to grep, but that seems hackish, like git has a better way to > > isolate log entries. > > > > > > Vadim, please don't top post. Daniel, yes, you just do: git log cat/pkg Or: git log . `git log' understands path arguments within the repo. But, that doesn't really give you the full picture. You will be better served by: git log --grep= signature.asc Description: Digital signature
Re: [gentoo-dev] ChangeLog
Actually, git log understands if you specify path for it (especially after --)... 03.11.2015 02:05, Daniel Campbell пишет: > On 11/01/2015 04:22 AM, Anthony G. Basile wrote: > > On 11/1/15 7:16 AM, Patrick Lauer wrote: > >> Ahoi, > >> > >> I'm getting mildly very irritated with the lack of easily > >> accessible ChangeLogs for our packages. > >> > >> Apparently updating them stopped some time in August, so now > >> there are some outdated ChangeLogs that don't really serve any > >> purpose, and the easiest way for users to figure out why > >> something changed is to yell at the clumsy gitweb.g.o interface. > >> So instead of grep we now need lots of patience. > >> > >> This does not look reasonable to me. > >> > >> Can we please either properly remove ChangeLogs and tell people > >> to not be curious about changes, or make them useful again? > >> > >> Thanks, > >> > >> A Gentoo User. > >> > > I don't have strong feelings about this, but I'm happy with `git > > log` to tell me what's going on with packages. I would be okay > > with the ChangeLog files just being archived and removed. > > > Is there a way for us (devs and users both) to only get `git log` > results from a specific directory or package? I'm aware we could pipe > git log to grep, but that seems hackish, like git has a better way to > isolate log entries. > >
Re: [gentoo-dev] ChangeLog - Infra Response
On Mon, Nov 02, 2015 at 08:05:56AM +0100, Ulrich Mueller wrote: > > On Mon, 2 Nov 2015, Robin H Johnson wrote: > > > 1. Control of the OUTPUT filename for the generated changelog > > - the from-git generated changelog will go to 'ChangeLog.git' > > > [...] > > > Without #1, we have to rename ALL of the old changelogs, otherwise > > they will be overwritten by the new ones from Git history. > What would be the problem with renaming? IMHO it would be nicer to > keep the ChangeLog name for the autogenerated files and rename the > ones from CVS. We already have files renamed to ChangeLog- when > they became to large, so we could just use ChangeLog-2015 to stay > within that scheme. In the rsync tree, but NOT the Git tree, we have ChangeLog ChangeLog- Where so far goes as far as 2014. And 'ChangeLog' files stopped getting updates on August 8th. The old ChangeLog files from CVS are explicitly NOT in Git, but manually injected during the rsync tree creation. If we rename the old ChangeLog files from CVS to ChangeLog-2015, then we'll have both 'ChangeLog-2015' and 'ChangeLog' (generated from Git) containing 2015 entries. Worse, what happens when we hit 2016? Do we merge the old files? The main tree Git history starts at August 8th, so it can't be used to generate older entries either (ignoring using the full history to generate full ChangeLog.git files since the start of time, because CVS commit messages used to be a LOT worse than the manual ChangeLog messages). Thus, I was proposing to explicitly name the from-git ChangeLog as ChangeLog.git or ChangeLog-git. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/01/2015 04:22 AM, Anthony G. Basile wrote: > On 11/1/15 7:16 AM, Patrick Lauer wrote: >> Ahoi, >> >> I'm getting mildly very irritated with the lack of easily >> accessible ChangeLogs for our packages. >> >> Apparently updating them stopped some time in August, so now >> there are some outdated ChangeLogs that don't really serve any >> purpose, and the easiest way for users to figure out why >> something changed is to yell at the clumsy gitweb.g.o interface. >> So instead of grep we now need lots of patience. >> >> This does not look reasonable to me. >> >> Can we please either properly remove ChangeLogs and tell people >> to not be curious about changes, or make them useful again? >> >> Thanks, >> >> A Gentoo User. >> > I don't have strong feelings about this, but I'm happy with `git > log` to tell me what's going on with packages. I would be okay > with the ChangeLog files just being archived and removed. > Is there a way for us (devs and users both) to only get `git log` results from a specific directory or package? I'm aware we could pipe git log to grep, but that seems hackish, like git has a better way to isolate log entries. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWN8ICAAoJEAEkDpRQOeFwa7UP/191KfADyGZfF/cPfBp5tpE8 SP9mYoZB4ZUbCV/UUE5/Oz5st2lBtK+LNI2C8Apea53bu+Qd48qP/Q2l4WtFTVR5 JTfT/EK10kE+hu2tie1Bq43lFdWB+yWSS7lmoHMWkQH5wSr+0jGi1jm5njTvbvSE GxlNMqFjHcVg3zwkRXoGtPjqQqJqjbX81ZSxxIHYwpYbDJIXgZcgrEy6Hvf8nzTi 5G6GtSoW490rZm+HtRQ8NiC8mKnLqyzsVAQZSFomKu7lA0r9dsI2vzwc31pSBljs K+Gh1oTho8YCV/+LFADgxJOWk2oI3AaCH5ar39oV8sWO8Hs1VuvAGVFY+0EqiMUL nSZX/ghjjWP7yO6FrBF8eh32hmP3K/F+ZuMbCubx9pdL+OcuoGWVu3kf8sa64zyY pJITSy0AqFrdMdTXnpRc4QWW+CmScQFrS8X5uYgQaceKtGHSy6vDzKRYyC6YJcDy afMB4jHCaLiNFkOzjIkJ6/TnTaCXbnICy5HXb3IAWA+6vj6CZ/zJpSVMm+gdx8np MDS4ROltElah7yVsauGqca93ux5TNCGkktw3zSJcvYiDZo/0LVsMwXFNOPaT1R2R p53tW9juK2Tj2eY357DrAij770ru5LznJ00bVFx2HFp8j+fjakflZlZK1BTNFZHK lZEiWbGPJa54QTcLah7J =8NAr -END PGP SIGNATURE-
Re: [gentoo-dev] ChangeLog - Infra Response
On Mon, 2 Nov 2015 05:50:39 + "Robin H. Johnson" wrote: > I'm replying to the top level of the thread, because I've been on > offline vacation recharging myself for a week, and this thread seems > to have degenerated into ways to avoid the issue, rather than > focusing with what's actually wrong. > > rsync-as-a-way-to-get-the-tree is NOT being deprecated, it has very > valid use cases, and places where git is not suited. > > I asked zmedico & dol-sen for TWO critical changes to egencache's > --update-changelogs code. > > 1. Control of the OUTPUT filename for the generated changelog > - the from-git generated changelog will go to 'ChangeLog.git' > 2. Control for the order ENTRY for the generated changelog > - changing to OLDEST-first, with appending the new data at the end > - this massively improves rsync performance. > > dol-sen said he was busy with the repoman rewrite, and didn't want to > introduce the change at the time, so this has been deferred for the > moment. > > Without #1, we have to rename ALL of the old changelogs, otherwise > they will be overwritten by the new ones from Git history. > > I probably should have created a bug for both of these, because I > don't know if they got tracked accurately since I asked for them in > August, and I certainly don't see the code being updated in the > repoman or master branches of the portage repo (it also still > generates a $Header$ entry, which does have an open bug as well). > > Since dol-sen and zmedico are so busy as well, somebody from this > thread with time to complain, please implement & test these changes! > It's NOT as trivial as dropping a variable into the place where it > opens the file, because there is other code later that also hardcodes > the filename. > Well, to be honest, I kinda forgot about this. (too many things on my plate) The repoman code is released and mostly stable, and starting work on stage2 of that process. So That is one thing less to worry about for the moment. Any other required repoman changes are certainly possible now. The $HEADER$ did get an initial change, but as I recall there has been no official/final decision on whether it is to be dropped completely. Plus I'm not finding that bug this morning. If it is to be dropped completely, that can be done. As I recall it was you that wanted to keep it, at least for an interim period for some other infra use in the rsync tree generation. I don't recall the exact reason. Most certainly patches are welcome. -- Brian Dolbec
Re: [gentoo-dev] ChangeLog - Infra Response
> On Mon, 2 Nov 2015, Robin H Johnson wrote: > 1. Control of the OUTPUT filename for the generated changelog > - the from-git generated changelog will go to 'ChangeLog.git' > [...] > Without #1, we have to rename ALL of the old changelogs, otherwise > they will be overwritten by the new ones from Git history. What would be the problem with renaming? IMHO it would be nicer to keep the ChangeLog name for the autogenerated files and rename the ones from CVS. We already have files renamed to ChangeLog- when they became to large, so we could just use ChangeLog-2015 to stay within that scheme. Ulrich pgpeIWzEGeDCQ.pgp Description: PGP signature
Re: [gentoo-dev] ChangeLog - Infra Response
Dnia 2 listopada 2015 06:50:39 CET, "Robin H. Johnson" napisał(a): >I'm replying to the top level of the thread, because I've been on >offline vacation recharging myself for a week, and this thread seems to >have degenerated into ways to avoid the issue, rather than focusing >with >what's actually wrong. > >rsync-as-a-way-to-get-the-tree is NOT being deprecated, it has very >valid use cases, and places where git is not suited. > >I asked zmedico & dol-sen for TWO critical changes to egencache's >--update-changelogs code. > >1. Control of the OUTPUT filename for the generated changelog >- the from-git generated changelog will go to 'ChangeLog.git' >2. Control for the order ENTRY for the generated changelog >- changing to OLDEST-first, with appending the new data at the end >- this massively improves rsync performance. > >dol-sen said he was busy with the repoman rewrite, and didn't want to >introduce the change at the time, so this has been deferred for the >moment. > >Without #1, we have to rename ALL of the old changelogs, otherwise they >will be overwritten by the new ones from Git history. > >I probably should have created a bug for both of these, because I don't >know if they got tracked accurately since I asked for them in August, >and I certainly don't see the code being updated in the repoman or >master branches of the portage repo (it also still generates a $Header$ >entry, which does have an open bug as we. You should have indeed. Both seem trivial and I'd have done them a long time ago if anybody bothered telling me about it. > >Since dol-sen and zmedico are so busy as well, somebody from this >thread >with time to complain, please implement & test these changes! >It's NOT as trivial as dropping a variable into the place where it >opens >the file, because there is other code later that also hardcodes the >filename. -- Best regards, Michał Górny
Re: [gentoo-dev] ChangeLog - Infra Response
I'm replying to the top level of the thread, because I've been on offline vacation recharging myself for a week, and this thread seems to have degenerated into ways to avoid the issue, rather than focusing with what's actually wrong. rsync-as-a-way-to-get-the-tree is NOT being deprecated, it has very valid use cases, and places where git is not suited. I asked zmedico & dol-sen for TWO critical changes to egencache's --update-changelogs code. 1. Control of the OUTPUT filename for the generated changelog - the from-git generated changelog will go to 'ChangeLog.git' 2. Control for the order ENTRY for the generated changelog - changing to OLDEST-first, with appending the new data at the end - this massively improves rsync performance. dol-sen said he was busy with the repoman rewrite, and didn't want to introduce the change at the time, so this has been deferred for the moment. Without #1, we have to rename ALL of the old changelogs, otherwise they will be overwritten by the new ones from Git history. I probably should have created a bug for both of these, because I don't know if they got tracked accurately since I asked for them in August, and I certainly don't see the code being updated in the repoman or master branches of the portage repo (it also still generates a $Header$ entry, which does have an open bug as well). Since dol-sen and zmedico are so busy as well, somebody from this thread with time to complain, please implement & test these changes! It's NOT as trivial as dropping a variable into the place where it opens the file, because there is other code later that also hardcodes the filename. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] ChangeLog
On 11/01/2015 07:16 AM, Patrick Lauer wrote: > Ahoi, > > I'm getting mildly very irritated with the lack of easily accessible > ChangeLogs for our packages. > > Apparently updating them stopped some time in August, so now there are > some outdated ChangeLogs that don't really serve any purpose, and the > easiest way for users to figure out why something changed is to yell at > the clumsy gitweb.g.o interface. So instead of grep we now need lots of > patience. > How about e.g. https://packages.gentoo.org/packages/dev-lang/php ?
Re: [gentoo-dev] ChangeLog
On Sun, 1 Nov 2015 12:26:04 -0500 Rich Freeman wrote: > On Sun, Nov 1, 2015 at 10:24 AM, Alexis Ballier > wrote: > > On Sun, 1 Nov 2015 10:17:54 -0500 > > Rich Freeman wrote: > >> > >> I haven't heard anybody propose a new plan. I certainly am not > >> proposing one. > > > > The part you cut: > > > >> > >> You shouldn't use rsync anymore, it is inherently insecure. The git > >> tree is _properly_ gpg signed so you can verify it's correctness. > >> > > That was just a random developer offering random advice. People are > welcome to do that on the lists. Nobody is preventing anybody from > fixing the bug. > > There is no approved grandiose plan to obsolete rsync. Hence me asking where the discussion took place... Y'know, the email you replied to :)
Re: [gentoo-dev] ChangeLog
On Sun, Nov 1, 2015 at 10:24 AM, Alexis Ballier wrote: > On Sun, 1 Nov 2015 10:17:54 -0500 > Rich Freeman wrote: >> >> I haven't heard anybody propose a new plan. I certainly am not >> proposing one. > > The part you cut: > >> >> You shouldn't use rsync anymore, it is inherently insecure. The git >> tree is _properly_ gpg signed so you can verify it's correctness. >> That was just a random developer offering random advice. People are welcome to do that on the lists. Nobody is preventing anybody from fixing the bug. There is no approved grandiose plan to obsolete rsync. -- Rich
Re: [gentoo-dev] ChangeLog
> git clone --depth=1 (you can also put that into your repos.conf, the > option is called 'sync-depth'). --depth is also available for regular pulls. ``` $ LC_ALL=C git clone --depth=1 git://git.gentoo.org/repo/gentoo.git Cloning into 'gentoo'... remote: Counting objects: 113359, done. remote: Compressing objects: 100% (99921/99921), done. Receiving objects: 17% (19272/113359), 7.32 MiB | 30 KiB/s # $ LC_ALL=C ls gentoo ls: cannot access gentoo: No such file or directory ``` So? How should I sync then? Git can *not* sync file by file, while rsync can. > And thanks for calling me selfish for trying to make it possible for > users to directly use a git checkout as the local tree. I appreciate it. :) No. Making it *possible* for all users to use git (instead of old cvs+rsync behaviour) is a great thing and you're awesome in making it *possible*. But do not be authoritarian and do not *force* (!) users to "use only git and forget about rsync". I called you selfish not for doing good things like introducing possibility to use git, but for authoritarian thinking, that all users has as good internet connection (taking that thread) or tech. knowledge (talking prev. threads) as you. They are not. At least, far not always.
Re: [gentoo-dev] ChangeLog
On Sun, 1 Nov 2015 10:17:54 -0500 Rich Freeman wrote: > On Sun, Nov 1, 2015 at 10:00 AM, Alexis Ballier > wrote: > > On Sun, 1 Nov 2015 09:19:25 -0500 > > Rich Freeman wrote: > > > > [...] > >> What discussion or decision is necessary? > > > > One that announces the initial and current plan has changed and > > describes the new plan maybe? > > > > I haven't heard anybody propose a new plan. I certainly am not > proposing one. The part you cut: > > You shouldn't use rsync anymore, it is inherently insecure. The git > tree is _properly_ gpg signed so you can verify it's correctness. > > With the following portage configuration/hooks, any user can run the > tree directly from git: > https://github.com/hasufell/portage-gentoo-git-config
Re: [gentoo-dev] ChangeLog
On Sun, Nov 1, 2015 at 10:00 AM, Alexis Ballier wrote: > On Sun, 1 Nov 2015 09:19:25 -0500 > Rich Freeman wrote: > > [...] >> What discussion or decision is necessary? > > One that announces the initial and current plan has changed and > describes the new plan maybe? > I haven't heard anybody propose a new plan. I certainly am not proposing one. Like I said, I don't have a problem with there being Changelogs in rsync. By all means go fix it. -- Rich
Re: [gentoo-dev] ChangeLog
On Sun, 1 Nov 2015 09:19:25 -0500 Rich Freeman wrote: [...] > What discussion or decision is necessary? One that announces the initial and current plan has changed and describes the new plan maybe? [...] > So, if you want to see what has changed there are half a dozen ways of > doing it without using changelogs. I imagine the 'you' in your long tirade is a generic 'you', otherwise, let me make this clear: I'm in favor of removing changelogs. They made sense with the per-file tracking of cvs, git made them much less useful.
Re: [gentoo-dev] ChangeLog
On Sun, Nov 1, 2015 at 8:47 AM, Alexis Ballier wrote: > Considering the original plan was to have changelogs auto-generated > from git and still serving the tree via rsync, where's the relevant > discussion and decision about this? What discussion or decision is necessary? As far as I'm aware nobody has forbidden making changelogs available via rsync. It just sounds like there is a bug in their generation. What is needed is for those who want changelogs to fix the bug, not endless discussion. If the issue is infra access, just make your own mirror with working code and I'm sure infra will borrow it, and if not nobody really HAS to use infra. I'm syncing from the github mirror that contains pre-generated metadata for convenience, which is just one of the many options available. Nobody is actively preventing anybody from having what they want. This isn't some corporation where we are paying people and we can demand that the responsible parties fix things or lose their jobs. Lots of effort has gone into making the git migration as seamless as possible, but it was bound to be imperfect. Personally I would have been fine with less effort being spent on it than actually was. Gentoo has never been a hand-holding distro. I have nothing against people who choose to invest their time into making it more helpful to those who wish to use alternate tools (like changelogs), but I don't favor telling those who are working on new features to not actually deploy them unless THEY spend their time on such things as long as we have a reasonable path forward for everybody. So, if you want to see what has changed there are half a dozen ways of doing it without using changelogs. -- Rich
Re: [gentoo-dev] ChangeLog
On 11/01/2015 02:51 PM, Мисбах-Соловьёв Вадим wrote: >> You shouldn't use rsync anymore, it is inherently insecure. The git tree >> is _properly_ gpg signed so you can verify it's correctness. >> >> With the following portage configuration/hooks, any user can run the >> tree directly from git: >> https://github.com/hasufell/portage-gentoo-git-config >> >> At some point, rsync schould be deprecated completely. > > Nice try, but sometimes (say, in case of very unstable internet connection) > it is IMPOSSIBLE to properly sync git repo (because it tries to fetch all the > queue (between local HEAD and remote one) in a row, from the exactly same > place every time it fails), while it still possible to sync tree by rsync, > because it only fetches differences and do not drop properly downloaded files. > > Do NOT (!) assume flawless shiny 40Gbit internet everywhere in the world. > Stop being so selfish and thinking only from position of the developer. > Always do imagine you as the gentoo user in the worst possible case. > Please. > git clone --depth=1 (you can also put that into your repos.conf, the option is called 'sync-depth'). --depth is also available for regular pulls. And thanks for calling me selfish for trying to make it possible for users to directly use a git checkout as the local tree. I appreciate it. :)
Re: [gentoo-dev] ChangeLog
On 11/01/2015 02:47 PM, Alexis Ballier wrote: > On Sun, 1 Nov 2015 14:33:07 +0100 > hasufell wrote: git log -- app-misc/foo or git log -- eclass/autotools.eclass will give you _any_ commit that has touched that file/directory, even if it was part of a huge mass commit. >>> >>> $ cd /usr/portage/app-admin/rex/; git log >>> fatal: Not a git repository (or any of the parent directories): .git >>> >>> sooo ... ??? >>> >> >> You shouldn't use rsync anymore, it is inherently insecure. The git >> tree is _properly_ gpg signed so you can verify it's correctness. >> >> With the following portage configuration/hooks, any user can run the >> tree directly from git: >> https://github.com/hasufell/portage-gentoo-git-config > > More secure by fetching metadata cache via rsync ? > Better by running egencache after each sync ? > I don't think so. > Yes it is. You have the option of generating it yourself (only takes long for the first time) or fetch it from the following gentoo mirror instead https://github.com/gentoo-mirror/gentoo We might adjust those hooks to do that. >> At some point, rsync schould be deprecated completely. > > > Considering the original plan was to have changelogs auto-generated > from git and still serving the tree via rsync, where's the relevant > discussion and decision about this? > > There's no technical reason for not doing this *today*, the only reason > not to is the lack of decision and concrete plan on how to properly > serve what is in the rsync'ed tree and not in gentoo.git. > > > Until then, we are serving outdated and useless changelogs via rsync > and Patrick's point still holds: Either remove them or serve proper > ones. > +1 for removing.
Re: [gentoo-dev] ChangeLog
> You shouldn't use rsync anymore, it is inherently insecure. The git tree > is _properly_ gpg signed so you can verify it's correctness. > > With the following portage configuration/hooks, any user can run the > tree directly from git: > https://github.com/hasufell/portage-gentoo-git-config > > At some point, rsync schould be deprecated completely. Nice try, but sometimes (say, in case of very unstable internet connection) it is IMPOSSIBLE to properly sync git repo (because it tries to fetch all the queue (between local HEAD and remote one) in a row, from the exactly same place every time it fails), while it still possible to sync tree by rsync, because it only fetches differences and do not drop properly downloaded files. Do NOT (!) assume flawless shiny 40Gbit internet everywhere in the world. Stop being so selfish and thinking only from position of the developer. Always do imagine you as the gentoo user in the worst possible case. Please.
Re: [gentoo-dev] ChangeLog
On Sun, 1 Nov 2015 14:33:07 +0100 hasufell wrote: > >> > >> git log -- app-misc/foo > >> or > >> git log -- eclass/autotools.eclass > >> > >> will give you _any_ commit that has touched that file/directory, > >> even if it was part of a huge mass commit. > > > > $ cd /usr/portage/app-admin/rex/; git log > > fatal: Not a git repository (or any of the parent directories): .git > > > > sooo ... ??? > > > > You shouldn't use rsync anymore, it is inherently insecure. The git > tree is _properly_ gpg signed so you can verify it's correctness. > > With the following portage configuration/hooks, any user can run the > tree directly from git: > https://github.com/hasufell/portage-gentoo-git-config More secure by fetching metadata cache via rsync ? Better by running egencache after each sync ? I don't think so. > At some point, rsync schould be deprecated completely. Considering the original plan was to have changelogs auto-generated from git and still serving the tree via rsync, where's the relevant discussion and decision about this? There's no technical reason for not doing this *today*, the only reason not to is the lack of decision and concrete plan on how to properly serve what is in the rsync'ed tree and not in gentoo.git. Until then, we are serving outdated and useless changelogs via rsync and Patrick's point still holds: Either remove them or serve proper ones. Alexis.
Re: [gentoo-dev] ChangeLog
On 11/01/2015 02:28 PM, Patrick Lauer wrote: >> >> ChangeLogs are a deprecated and unreliable method of the times we were >> still on CVS. E.g. some people didn't find it useful to add ChangeLog >> entries when they did large eclass changes. This problem is gone now. > ... ?!??!#??$>@%%*%**%@!!! > > From the point of view of a user ChangeLogs are VERY VERY USEFUL. > > Why would you claim they are deprecated? Because they are unreliable and we have a better method. >> >> git log -- app-misc/foo >> or >> git log -- eclass/autotools.eclass >> >> will give you _any_ commit that has touched that file/directory, even if >> it was part of a huge mass commit. > > $ cd /usr/portage/app-admin/rex/; git log > fatal: Not a git repository (or any of the parent directories): .git > > sooo ... ??? > You shouldn't use rsync anymore, it is inherently insecure. The git tree is _properly_ gpg signed so you can verify it's correctness. With the following portage configuration/hooks, any user can run the tree directly from git: https://github.com/hasufell/portage-gentoo-git-config At some point, rsync schould be deprecated completely.
Re: [gentoo-dev] ChangeLog
On 11/01/2015 02:24 PM, hasufell wrote: > On 11/01/2015 01:16 PM, Patrick Lauer wrote: >> Ahoi, >> >> I'm getting mildly very irritated with the lack of easily accessible >> ChangeLogs for our packages. >> >> Apparently updating them stopped some time in August, so now there are >> some outdated ChangeLogs that don't really serve any purpose, and the >> easiest way for users to figure out why something changed is to yell at >> the clumsy gitweb.g.o interface. So instead of grep we now need lots of >> patience. >> >> This does not look reasonable to me. >> >> Can we please either properly remove ChangeLogs and tell people to not >> be curious about changes, or make them useful again? >> > > ChangeLogs are a deprecated and unreliable method of the times we were > still on CVS. E.g. some people didn't find it useful to add ChangeLog > entries when they did large eclass changes. This problem is gone now. ... ?!??!#??$>@%%*%**%@!!! >From the point of view of a user ChangeLogs are VERY VERY USEFUL. Why would you claim they are deprecated? > > git log -- app-misc/foo > or > git log -- eclass/autotools.eclass > > will give you _any_ commit that has touched that file/directory, even if > it was part of a huge mass commit. $ cd /usr/portage/app-admin/rex/; git log fatal: Not a git repository (or any of the parent directories): .git sooo ... ??? > > There's really not much ChangeLogs add for you here, except duplicating > git functionality. It's more useful to familiarize yourself with git > log. There's no reason to depend on the gitweb interface. > > If you want the history from before the migration to work with that as > well, you can use this method: > https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_History_Onto_the_Active_Repo > > Also see > https://www.atlassian.com/git/tutorials/git-log/filtering-the-commit-history > I have no idea what you are trying to say, but for most users this advice is not even useless but actively wrong. With that out of the way, can we please return to the original discussion?
Re: [gentoo-dev] ChangeLog
On 11/01/2015 01:53 PM, Rich Freeman wrote: > On Sun, Nov 1, 2015 at 7:33 AM, Мисбах-Соловьёв Вадим wrote: >> And why don't just only generate them on rsync mirrors, but remove them from >> git repo (like was planned initially, AFAIRC)? >> > That is in fact how it works. Or, at least how it is supposed to > work. I don't use the rsync mirror, so I can't vouch for whether > they're producing ChangeLogs. Supposed to, but it doesn't > > Personally I'd just as soon see them go away entirely, but if somebody > wants to make them work I won't stop them. > I'd really not prefer to fly blind, ChangeLogs are awesome for users. I am a user too. I really would like to know why something changed, and maybe who did it.
Re: [gentoo-dev] ChangeLog
On 11/01/2015 01:16 PM, Patrick Lauer wrote: > Ahoi, > > I'm getting mildly very irritated with the lack of easily accessible > ChangeLogs for our packages. > > Apparently updating them stopped some time in August, so now there are > some outdated ChangeLogs that don't really serve any purpose, and the > easiest way for users to figure out why something changed is to yell at > the clumsy gitweb.g.o interface. So instead of grep we now need lots of > patience. > > This does not look reasonable to me. > > Can we please either properly remove ChangeLogs and tell people to not > be curious about changes, or make them useful again? > ChangeLogs are a deprecated and unreliable method of the times we were still on CVS. E.g. some people didn't find it useful to add ChangeLog entries when they did large eclass changes. This problem is gone now. git log -- app-misc/foo or git log -- eclass/autotools.eclass will give you _any_ commit that has touched that file/directory, even if it was part of a huge mass commit. There's really not much ChangeLogs add for you here, except duplicating git functionality. It's more useful to familiarize yourself with git log. There's no reason to depend on the gitweb interface. If you want the history from before the migration to work with that as well, you can use this method: https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Grafting_Gentoo_History_Onto_the_Active_Repo Also see https://www.atlassian.com/git/tutorials/git-log/filtering-the-commit-history
Re: [gentoo-dev] ChangeLog
On Sun, Nov 1, 2015 at 7:33 AM, Мисбах-Соловьёв Вадим wrote: > And why don't just only generate them on rsync mirrors, but remove them from > git repo (like was planned initially, AFAIRC)? > That is in fact how it works. Or, at least how it is supposed to work. I don't use the rsync mirror, so I can't vouch for whether they're producing ChangeLogs. Personally I'd just as soon see them go away entirely, but if somebody wants to make them work I won't stop them. -- Rich
Re: [gentoo-dev] ChangeLog
And why don't just only generate them on rsync mirrors, but remove them from git repo (like was planned initially, AFAIRC)? 01.11.2015, 18:17, "Patrick Lauer" : > Ahoi, > > I'm getting mildly very irritated with the lack of easily accessible > ChangeLogs for our packages. > > Apparently updating them stopped some time in August, so now there are > some outdated ChangeLogs that don't really serve any purpose, and the > easiest way for users to figure out why something changed is to yell at > the clumsy gitweb.g.o interface. So instead of grep we now need lots of > patience. > > This does not look reasonable to me. > > Can we please either properly remove ChangeLogs and tell people to not > be curious about changes, or make them useful again? > > Thanks, > > A Gentoo User.
Re: [gentoo-dev] ChangeLog
On 11/1/15 7:16 AM, Patrick Lauer wrote: Ahoi, I'm getting mildly very irritated with the lack of easily accessible ChangeLogs for our packages. Apparently updating them stopped some time in August, so now there are some outdated ChangeLogs that don't really serve any purpose, and the easiest way for users to figure out why something changed is to yell at the clumsy gitweb.g.o interface. So instead of grep we now need lots of patience. This does not look reasonable to me. Can we please either properly remove ChangeLogs and tell people to not be curious about changes, or make them useful again? Thanks, A Gentoo User. I don't have strong feelings about this, but I'm happy with `git log` to tell me what's going on with packages. I would be okay with the ChangeLog files just being archived and removed. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] ChangeLog
Ahoi, I'm getting mildly very irritated with the lack of easily accessible ChangeLogs for our packages. Apparently updating them stopped some time in August, so now there are some outdated ChangeLogs that don't really serve any purpose, and the easiest way for users to figure out why something changed is to yell at the clumsy gitweb.g.o interface. So instead of grep we now need lots of patience. This does not look reasonable to me. Can we please either properly remove ChangeLogs and tell people to not be curious about changes, or make them useful again? Thanks, A Gentoo User.
Re: [gentoo-dev] ChangeLog in eclass dir
On 11/15/2011 11:15 AM, Jeroen Roovers wrote: > On Fri, 4 Nov 2011 00:25:32 +0100 > "Andreas K. Huettel" wrote: > >> 1) Why is there no ChangeLog in the eclass directory? In my personal opinion this is missing there, if only for historical reasons... Should we still start one? >>> >>> as there was only positive feedback to this suggestion, I'll create >>> a ChangeLog file in the eclass directory during the next days. >>> (Last chance to protest!) >> >> And done. :) > > Great. Now do we enforce writing ChangeLog entries like we do > everywhere else? Can we then get repoman to also do commits in > non-ebuild directories (i.e. ignore a missing $CAT and missing *.ebuild? Sure, I've filed a bug: https://bugs.gentoo.org/show_bug.cgi?id=390651 -- Thanks, Zac
Re: [gentoo-dev] ChangeLog in eclass dir (was: Old changelogs / eclass dir)
On Fri, 4 Nov 2011 00:25:32 +0100 "Andreas K. Huettel" wrote: > > > > 1) Why is there no ChangeLog in the eclass directory? > > > In my personal opinion this is missing there, if only for > > > historical reasons... Should we still start one? > > > > as there was only positive feedback to this suggestion, I'll create > > a ChangeLog file in the eclass directory during the next days. > > (Last chance to protest!) > > And done. :) Great. Now do we enforce writing ChangeLog entries like we do everywhere else? Can we then get repoman to also do commits in non-ebuild directories (i.e. ignore a missing $CAT and missing *.ebuild? jer
Re: [gentoo-dev] ChangeLog in eclass dir (was: Old changelogs / eclass dir)
> > 1) Why is there no ChangeLog in the eclass directory? > > In my personal opinion this is missing there, if only for historical > > reasons... Should we still start one? > > as there was only positive feedback to this suggestion, I'll create a > ChangeLog file in the eclass directory during the next days. (Last chance > to protest!) And done. :) huettel@pinacolada ~/Gentoo/gentoo-x86/eclass $ cvs commit /var/cvsroot/gentoo-x86/eclass/ChangeLog,v <-- ChangeLog initial revision: 1.1 huettel@pinacolada ~/Gentoo/gentoo-x86/eclass $ -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] ChangeLog in eclass dir (was: Old changelogs / eclass dir)
Dear all, > 1) Why is there no ChangeLog in the eclass directory? > In my personal opinion this is missing there, if only for historical > reasons... Should we still start one? as there was only positive feedback to this suggestion, I'll create a ChangeLog file in the eclass directory during the next days. (Last chance to protest!) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
I'm summarising this thread [0] for the upcoming council meeting. Automatic ChangeLog generation Some people have expressed disagreement with committing ChangeLog updates for some changes. Discussion on that lead to an updated policy to document nearly all changes. Some people still really disagree with that and go as far to commit dummy placeholders just to make sure they don't do what they deem is useless for everybody. ChangeLog generation is often suggested as a solution to this by those people who do not like to document their changes in the ChangeLog file. Auto generation of ChangeLogs, implies changes, and also influences how current ChangeLog information is to be handled. What if auto-generation is done, what does it take? - what messages to include (all?), what not to include (ignore some?) -- ignore some messages, git: Commit Limiting ([trivial]) [1][3] --- policy? what to ignore, what not? what does the current policy mean if commits can be made to be ignored? -- only include messages for a time range, or relevant messages for current files (ebuilds) in the directory (package) [3] = balance between hard policy effectuated by the generation and fuzzy control via keywords that is subject to the interpretation of the committer = opening for new opportunities to safe space for and present more relevant information to our users - inability to edit changelog entries (make corrections) -- git: git notes --help -> append notes to commit msgs [1] -- not a real issue [3] = balance between either allowing it through complex scripting, or just ignoring the ability at all since it is rarely used and not done by others either ([3]) - history, ChangeLogs are often more useful than the CVS logs -- retain existing ChangeLog and append? [1] --- use setup with separate git repo for ChangeLogs [2] --- auto-generate if non-existent (per maintainer pref) [3] -- just forget it, it's old [3] = balance between either retaining the original information, or forgetting about it completely since it is likely outdated information anyway -- note: this is only about differences in CVS log and ChangeLog = balance between generating all ChangeLogs, or just those whose maintainer likes it Generating ChangeLog opens opportunities (only commit, limit contents, consistency), and can ease the life of developers. However, the currently existing ChangeLog files might differ from a generated one from VCS logs significantly, if this is considered important, a strategy for retaining the old messages has to be deployed (keep ChangeLog file, store ChangeLog in separate repo, selectively retain ChangeLog files per package). If a ChangeLog is generated, are all commits to show up in them, or can certain messages be ignored? The latter requires specification of how, but also when. Updating a ChangeLog file is close to such situation without policies. Since commit messages cannot be changed, are methods necessary to add notices to messages when they appear wrong/incorrect? Should ChangeLogs be generated? If yes - should all commit message be included - should commit messages be appended to/updated? - should existing information in ChangeLog files be retained? [0] http://archives.gentoo.org/gentoo-dev/msg_2ff02d6910d797045af3659fb21c712f.xml [1] http://archives.gentoo.org/gentoo-dev/msg_934d783d619540a2e97725da7e767253.xml [2] (not on archives.g.o and gmane) http://www.gossamer-threads.com/lists/gentoo/dev/231903?do=post_view_threaded [3] http://archives.gentoo.org/gentoo-dev/msg_3156112af9944a6c8736159247275ccb.xml On 02-06-2011 11:13:38 +0200, Fabian Groffen wrote: > Following up on the recent discussions about ChangeLogs, and what should > be in there, versus what not, this email tries to describe the pros and > cons of the frequently mentioned generation of ChangeLogs from the VCS > we use. > > I would like the council to discuss the generation of ChangeLogs from > the VCS in the next meeting for which this message is in time. I prefer > the council to decide upon whether or not generation of ChangeLogs is > desirable for Gentoo or not. In this email, I will try to describe the > pros and cons, but I invite anyone else to contribute/discuss ideas. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On 09-06-2011 18:06:02 +0200, Andreas K. Huettel wrote: > > > If typos matter then they matter to everybody, and if they don't then > > > we should not care. QA in Gentoo should be a consistent experience. > > > > while the last sentence is true, the first is not. if a minority of > > people care about typos, and/or they rarely fix said typos, then the > > logical answer is that their opinion loses out. it doesnt mean that > > everyone agrees. > > -mike > > you will surely agree then- if a minority of people thinks ebuild > removals should not go into the changelog, their opinion just loses > out. Right? > > Anyway. You and Samuli are at the moment just wasting everyone's time > here. Please don't mix threads. This thread is just about what we should do with ChangeLogs (if, and if, how to generate them) not about a particular preference of documenting things or not. So far, this thread was reasonably made of constructive, and sort of objective replies. It would be nice, and probably most useful for the council, if we could keep it this way. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
You are receiving this automated reply because you have sent mail to an invalid email address. If you are trying to contact YouTube, please visit the YouTube Help Center at: http://www.google.com/support/youtube If you're unable to find the answer to your question in the Help Center, you may use the contact forms located there to send us your question. Original Message Follows: From: Mike Frysinger Subject: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request) Date: Thu, 9 Jun 2011 16:01:42 -0400 On Thursday, June 09, 2011 12:47:02 Ciaran McCreesh wrote: > On Thu, 9 Jun 2011 12:40:46 -0400 Mike Frysinger wrote: > > what exactly is your point ? nowhere did i say i wasnt going to > > follow the new policy in this case. this e-mail is, as you said > > yourself, a waste of time. > > Instead, you said you'd just not properly maintain packages, by > neglecting to remove things that you think should be removed. are there any such packages ? are there any bugs along these lines ? no ? then come back later when you have something useful. -mike
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thursday, June 09, 2011 12:47:02 Ciaran McCreesh wrote: > On Thu, 9 Jun 2011 12:40:46 -0400 Mike Frysinger wrote: > > what exactly is your point ? nowhere did i say i wasnt going to > > follow the new policy in this case. this e-mail is, as you said > > yourself, a waste of time. > > Instead, you said you'd just not properly maintain packages, by > neglecting to remove things that you think should be removed. are there any such packages ? are there any bugs along these lines ? no ? then come back later when you have something useful. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, 9 Jun 2011 12:40:46 -0400 Mike Frysinger wrote: > what exactly is your point ? nowhere did i say i wasnt going to > follow the new policy in this case. this e-mail is, as you said > yourself, a waste of time. Instead, you said you'd just not properly maintain packages, by neglecting to remove things that you think should be removed. Will you be finding replacement maintainers who are prepared to do the entire maintenance job rather than just part of it for all of your packages? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thursday, June 09, 2011 12:06:02 Andreas K. Huettel wrote: > > > If typos matter then they matter to everybody, and if they don't then > > > we should not care. QA in Gentoo should be a consistent experience. > > > > while the last sentence is true, the first is not. if a minority of > > people care about typos, and/or they rarely fix said typos, then the > > logical answer is that their opinion loses out. it doesnt mean that > > everyone agrees. > > you will surely agree then- if a minority of people thinks ebuild removals > should not go into the changelog, their opinion just loses out. Right? what exactly is your point ? nowhere did i say i wasnt going to follow the new policy in this case. this e-mail is, as you said yourself, a waste of time. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
Mike, > > If typos matter then they matter to everybody, and if they don't then > > we should not care. QA in Gentoo should be a consistent experience. > > while the last sentence is true, the first is not. if a minority of > people care about typos, and/or they rarely fix said typos, then the > logical answer is that their opinion loses out. it doesnt mean that > everyone agrees. > -mike you will surely agree then- if a minority of people thinks ebuild removals should not go into the changelog, their opinion just loses out. Right? Anyway. You and Samuli are at the moment just wasting everyone's time here. If you would like to make a productive contribution, I suggest you run and campaign in the upcoming council election. After all, we do have some sort-of democratic process here in Gentoo, and as luck runs, the election is indeed pretty soon (so you might feel able to remove ebuilds already in the near future again). That is the best way to get policies changed and make your point. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, Jun 9, 2011 at 07:14, Rich Freeman wrote: > On Thu, Jun 9, 2011 at 1:59 AM, Mike Frysinger wrote: >> thinking about it a little more, i think this can easily be addressed. >> only auto-generate the ChangeLog file if it doesnt exist in VCS. >> thus the few people who are actually anal about typos (or just think >> they are) can retain their ChangeLogs in the packages they maintain >> and continue to hand update them. for the rest of us, we can >> autogenerate from the VCS logs. > > I'm not sure we should really leave that up to individual practice. > Remember that while packages have one or more maintainers, nobody > "owns" a package. the maintainer kind of does own that > If 99% of the tree is ChangeLog-free then will an > arch team remember to run echangelog on the 1% that still have them, > and so on? fair point, although overlays and such wont have changelogs generated automatically, so there is going to be a disconnect. we could have echangelog simply ignore a missing ChangeLog file so that people dont have to change their scripts ... > If typos matter then they matter to everybody, and if they don't then > we should not care. QA in Gentoo should be a consistent experience. while the last sentence is true, the first is not. if a minority of people care about typos, and/or they rarely fix said typos, then the logical answer is that their opinion loses out. it doesnt mean that everyone agrees. -mike
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, Jun 9, 2011 at 1:59 AM, Mike Frysinger wrote: > thinking about it a little more, i think this can easily be addressed. > only auto-generate the ChangeLog file if it doesnt exist in VCS. > thus the few people who are actually anal about typos (or just think > they are) can retain their ChangeLogs in the packages they maintain > and continue to hand update them. for the rest of us, we can > autogenerate from the VCS logs. I'm not sure we should really leave that up to individual practice. Remember that while packages have one or more maintainers, nobody "owns" a package. If 99% of the tree is ChangeLog-free then will an arch team remember to run echangelog on the 1% that still have them, and so on? This seems like we're adding complexity for a questionable return. If typos matter then they matter to everybody, and if they don't then we should not care. QA in Gentoo should be a consistent experience. Just my two cents. Rich
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Tue, Jun 7, 2011 at 17:20, Mike Frysinger wrote: > On Thursday, June 02, 2011 05:13:38 Fabian Groffen wrote: >> - inability to edit ChangeLog entries (typos, bug refs, etc.) > > in practice, i rarely see this being an issue. it certainly hasnt impeded any > of the huge projects out there (many of which are bigger than Gentoo) that > only have a changelog in the VCS history. typos happen, no one cares, and > people get over it. thinking about it a little more, i think this can easily be addressed. only auto-generate the ChangeLog file if it doesnt exist in VCS. thus the few people who are actually anal about typos (or just think they are) can retain their ChangeLogs in the packages they maintain and continue to hand update them. for the rest of us, we can autogenerate from the VCS logs. i think that brings your pros/cons list to only pros and no cons. so let's do it already. -mike
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thursday, June 02, 2011 05:13:38 Fabian Groffen wrote: > Simple pros I see mentioned: additional pro: automatic culling of information no longer relevant. entries dating back to 2002 rarely are useful today. we could easily implement a cap via date, size, files still in the tree, # of entries, etc... reality is, if developers want to see what's going on, go to the VCS and get the full history. > Simple cons I see mentioned: > - useless information on removals of ebuilds/files if people are forcing this crap either way, i dont see it being a con > - useless information on whitespace changes could easily be mitigated by prefixing the message with '[trivial]' and then the generator skips those > - inability to edit ChangeLog entries (typos, bug refs, etc.) in practice, i rarely see this being an issue. it certainly hasnt impeded any of the huge projects out there (many of which are bigger than Gentoo) that only have a changelog in the VCS history. typos happen, no one cares, and people get over it. > 1) it appears echangelog messages more than just a couple of times >differ from the repoman commit messages; sometimes useful information >is lost when just using the VCS logs just bite our lip and move on. as time moves forward, the desync will become relegated to history. > 2) typo fixing on VCS-generated logs is sometimes necessary, but >probably impossible in practice, it's rarely (if ever) necessary > 4) package moves might lose all history for essentially the same files this is a technical matter of the generator that can be overcome > > -# $Header: /var/cvsroot/gentoo-x86/dev-vcs/git/ChangeLog,v 1.95 > > 2011/05/31 06:4 7:22 grobian Exp $ > > +# $Header: this/file/is/a/generated/ChangeLog,v 1.1 2011/06/02 09:47:14 > > cvsps2changelog Exp $ > > The $Header line is likely going to be useless, and probably is best > removed. Is there something useful that can be substituted here? the VCS ids used to generate the log (and perhaps their associated dates) > sys-devel/gcc-config: > > - 16 Mar 2008; Christian Heim Manifest: > > - Fixing the Manifest (emerge is complaining about missing > > - $FILESDIR/wrapper-1.5.0.o). > > This entry disappears because Manifest and ChangeLog changes are ignored. which is fine -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Sun, Jun 5, 2011 at 1:30 PM, Fabian Groffen wrote: > On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote: >> All these problems are fixed if we don't re-generate the *existing* >> ChangeLogs. We should simply archive the existing ChangeLog, and >> append to it after the move to git. > > About this slightly hybrid approach: > > - the ChangeLog file is retained, some script just appends from VCS log > to it > * where is the ChangeLog file stored? > * is the VCS log appended to the ChangeLog every time it is generated, > or is it "committed" to the file? > - in case of a committed update to the ChangeLog file (commit hook? > repoman?), people would have the ability to edit the ChangeLog > I would suggest these things (I've omitted details irrelevant to ChangeLog management): (1) Convert using cvs2git, archive the old cvs repo. We now have a git repo with full history. (2) The new git tree must be without ChangeLog or (optionally) non-DIST Manifests. Remove all crud, git commit -m "Cleanup useless crud". Reason: no need to clutter the tree up with useless stuff that no one should touch. This will reduce the checked-out tree size by half. (3) No merge commits allowed to gentoo-x86.git. All commits must be rebased during pulls (git pull --rebase) or before pushing (git rebase && git push). Reason: keeps the history simple and easy to follow. The server can be made to reject merge commits. Most centralized git repos already follow this model. (4) No forced pushes which rewrite history are allowed to the server. Reason: well, this one is obvious. A lot of servers are configured to completely disallow this. (5) ChangeLogs do not exist in the git tree, they're maintained in a separate git repo by a script[1]. Reason: a git repo with history allows us to debug problems with the script, and follow its progress. (6) ChangeLog is updated incrementally with each changeset[2] (or every $time?), and the changes committed to its own git repo. This is made possible by (3) and (4). Reason: this way the workload of generating the ChangeLog won't increase at O(n*m) with time[3]. (7) The rsync server just copies over ebuilds, and then ChangeLogs, re-manifests (introducing non-DIST manifests if needed), maybe signs everything, and then pushes to mirrors. [1]. Note that pkgmoves would have to be detected and handled properly. [2]. This involves updating old ChangeLog entries if there are new git notes. [3]. n is the no. of commits per package, and m is the total no. of packages in the portage tree. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote: > All these problems are fixed if we don't re-generate the *existing* > ChangeLogs. We should simply archive the existing ChangeLog, and > append to it after the move to git. About this slightly hybrid approach: - the ChangeLog file is retained, some script just appends from VCS log to it * where is the ChangeLog file stored? * is the VCS log appended to the ChangeLog every time it is generated, or is it "committed" to the file? - in case of a committed update to the ChangeLog file (commit hook? repoman?), people would have the ability to edit the ChangeLog -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, Jun 2, 2011 at 6:29 PM, Fabian Groffen wrote:
> On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote:
>> > - no discussion on what to include or not (everything is in there)
>>
>> In git, we can make git log skip commit messages while generating the
>> ChangeLog, so this is incorrect. See section "Commit Limiting" in git
>> log --help.
>
> Assuming this is actually desirable, what rules would you suggest here?
>
Mostly only the trivial commits should be skipped. We should refer to
the other thread to decide what this consists of.
>> > Simple cons I see mentioned:
>> > - useless information on removals of ebuilds/files
>> > - useless information on whitespace changes
>>
>> None of these are valid with Commit Limiting and a tag such as
>> '[trivial]' in the commit message subject.
>
> By allowing this, "[trivial] old" is bringing you back to current policy
> ("commont sense") problems.
>
Yes, except that now it doesn't affect developers, and will result in
much less controversy. It certainly shouldn't come to forced
retirement. I don't see why we should bombard users with trivial
commits for political reasons...
>> Infact, if you do the same experiment on the openrc ChangeLog, you'll
>> see that it's too much work to regenerate the current ChangeLog
>> because a few commits managed to change the encoding of names in the
>> file, and a reverse-patch had to be applied to fix it. A number of
>> developers have made this mistake, and it shows up across the tree.
>
> I just created openrc's ChangeLog (attached to this mail). In what way
> exactly is it too much work? It's just a ChangeLog like many others, e.g.:
>
Ah, you don't include changes to ChangeLog as a part of your script.
Nevermind then :)
>> In git, there's no harm with making commit messages verbose, so we
>
> Why is this harmful with the current system?
>
Because it results in double the wasted space inside the repository.
Also, git is orders of magnitude better at compressing commit
messages, so the cost is massively lower.
>> > - a clear policy is necessary on what is going in the ChangeLog and what
>> > not (like the current "common sense" discussions going on and the
>> > updated devmanual)
>>
>> However, with git the issue is simplified because then developers will
>> stop relying on ChangeLogs for information, and ChangeLogs will be
>> used entirely to convey information to users.
>
> I don't see how that simplifies. I only see how that would completely
> change things/intents. Can you elaborate?
>
It simplifies things because most of the current situation arises from
shoe-horning of user as well as developer needs into a feature that is
supposed to be primarily user-oriented.
With CVS: "Trivial" changes that weren't documented in ChangeLog cause
breakage. cvs log/diff is too slow/hard to use, that delays
identification and fixing of breakage, and leads to a stricter policy
on ChangeLog updation.
With git: Changes that were marked [Trivial] in the commit message
cause breakage. git log, and you're done. There's no ChangeLog in the
git repo anyway, so no one will use ChangeLogs for this information.
This leaves us with user-oriented information. 99.99% of users won't
care about some commit messages being skipped from ChangeLog. Those
that do can clone the git repo, or sources.gentoo.org (which will be
faster with git). This doesn't mean we should skip *all* information
and not care at all. Just that the situation is less controversial
than before.
Cheers,
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On 02-06-2011 17:15:11 +0530, Nirbheek Chauhan wrote:
> > - no discussion on what to include or not (everything is in there)
>
> In git, we can make git log skip commit messages while generating the
> ChangeLog, so this is incorrect. See section "Commit Limiting" in git
> log --help.
Assuming this is actually desirable, what rules would you suggest here?
> > Simple cons I see mentioned:
> > - useless information on removals of ebuilds/files
> > - useless information on whitespace changes
>
> None of these are valid with Commit Limiting and a tag such as
> '[trivial]' in the commit message subject.
By allowing this, "[trivial] old" is bringing you back to current policy
("commont sense") problems.
> All these problems are fixed if we don't re-generate the *existing*
> ChangeLogs. We should simply archive the existing ChangeLog, and
> append to it after the move to git.
Fair suggestion, I didn't consider at first.
> Infact, if you do the same experiment on the openrc ChangeLog, you'll
> see that it's too much work to regenerate the current ChangeLog
> because a few commits managed to change the encoding of names in the
> file, and a reverse-patch had to be applied to fix it. A number of
> developers have made this mistake, and it shows up across the tree.
I just created openrc's ChangeLog (attached to this mail). In what way
exactly is it too much work? It's just a ChangeLog like many others, e.g.:
| - 06 Jan 2011; William Hubbs openrc-.ebuild:
| - remove /etc/init.d/{depscan,runscript}.sh for bug #347483.
| + 07 Jan 2011; Bob the Builder openrc-.ebuild:
| + Fix bug #347483 -- remove broken symlinks for depscan.sh and runscript.sh.
> In git, there's no harm with making commit messages verbose, so we
Why is this harmful with the current system?
> > - a clear policy is necessary on what is going in the ChangeLog and what
> > not (like the current "common sense" discussions going on and the
> > updated devmanual)
>
> However, with git the issue is simplified because then developers will
> stop relying on ChangeLogs for information, and ChangeLogs will be
> used entirely to convey information to users.
I don't see how that simplifies. I only see how that would completely
change things/intents. Can you elaborate?
--
Fabian Groffen
Gentoo on a different level
# ChangeLog for sys-apps/openrc
# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
# $Header: this/file/is/a/generated/ChangeLog,v 1.1 2011/06/02 14:46:51
cvsps2changelog Exp $
20 May 2011; Tomáš Chvátal openrc-.ebuild:
Migrate to EAPI=4. Acked by William and Jeremy.
13 May 2011; Bob the Builder openrc-0.8.2-r1.ebuild:
alpha/arm/ia64/sh/sparc stable wrt #295613
12 May 2011; Bob the Builder openrc-0.8.2-r1.ebuild:
Marked ppc/ppc64 stable for bug #295613.
09 May 2011; Bob the Builder openrc-0.8.2-r1.ebuild:
Stable for HPPA (bug #295613).
08 May 2011; Bob the Builder openrc-0.8.2-r1.ebuild:
amd64 stable, bug 295613
08 May 2011; Bob the Builder openrc-0.8.2-r1.ebuild:
stable x86, bug 295613
*openrc-0.8.2-r1 (28 Apr 2011)
28 Apr 2011; Bob the Builder +openrc-0.8.2-r1.ebuild:
revision bump for local.d migration fix
17 Apr 2011; Bob the Builder openrc-.ebuild:
Fix the migration of /etc/conf.d/local.* for bug #363949.
16 Apr 2011; Bob the Builder -openrc-0.8.1.ebuild:
remove broken version
*openrc-0.8.2 (16 Apr 2011)
16 Apr 2011; Bob the Builder +openrc-0.8.2.ebuild:
version bump
15 Apr 2011; Bob the Builder openrc-.ebuild:
Fix conf.d/local -> local.d transition for bug #363637.
15 Apr 2011; Bob the Builder openrc-.ebuild:
Disable consolefont on hppa by default for bug #228889, thanks to Jeroen
Roovers.
12 Apr 2011; Bob the Builder -openrc-0.6.3.ebuild,
-openrc-0.6.5.ebuild, -openrc-0.6.6.ebuild, -openrc-0.6.7.ebuild,
-openrc-0.8.0.ebuild:
remove old versions
*openrc-0.8.1 (12 Apr 2011)
12 Apr 2011; Bob the Builder +openrc-0.8.1.ebuild:
version bump
24 Mar 2011; Bob the Builder openrc-0.8.0.ebuild,
openrc-.ebuild:
remove outdated instructions for /etc/conf.d/local for bug #360293.
*openrc-0.8.0 (22 Mar 2011)
22 Mar 2011; Bob the Builder +openrc-0.8.0.ebuild:
version bump
22 Feb 2011; Robin H. Johnson openrc-.ebuild:
README.net is now README.newnet.
01 Feb 2011; Bob the Builder openrc-.ebuild:
add selinux use flag support for bug #351712
01 Feb 2011; Bob the Builder openrc-.ebuild:
remove a workaround for parallel build issues.
23 Jan 2011; Bob the Builder openrc-.ebuild:
Fix local.start and local.stop migration for bug #351465.
*openrc-0.7.0 (13 Jan 2011)
13 Jan 2011; Bob the Builder +openrc-0.7.0.ebuild:
version bump with many bug fixes
07 Jan 2011; Bob the Builder openrc-.ebuild:
Fix bug #347483 -- remove broken symlinks for depscan.sh and runscript.sh.
*openrc-0.6.8 (08 Dec 2010)
08 Dec 2010; Bob the Builder +openrc-0.6
Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)
On Thu, Jun 2, 2011 at 2:43 PM, Fabian Groffen wrote: > I start from the assumption that generation of ChangeLogs is NOT limited > to any VCS. This assumption is incorrect, but I guess it's a close enough approximation for the current discussion. > Simple pros I see mentioned: > - no more need for echangelog + repoman commit (identical message) This can be done without autogeneration as well. We can make repoman commit run echangelog before cvs commit. The main advantage is that there's no duplication of information, which would result in a less bloated repository. > - no discussion on what to include or not (everything is in there) In git, we can make git log skip commit messages while generating the ChangeLog, so this is incorrect. See section "Commit Limiting" in git log --help. > Simple cons I see mentioned: > - useless information on removals of ebuilds/files > - useless information on whitespace changes None of these are valid with Commit Limiting and a tag such as '[trivial]' in the commit message subject. > - inability to edit ChangeLog entries (typos, bug refs, etc.) > See "git notes --help". It allows you to append notes to commit messages without editing them. > 1) it appears echangelog messages more than just a couple of times > differ from the repoman commit messages; sometimes useful information > is lost when just using the VCS logs > 2) typo fixing on VCS-generated logs is sometimes necessary, but > probably impossible > 3) dates and new ebuilds generated from VCS are always correct, > ChangeLog editting/echangelog -> commit delays can cause > inconsitencies > 4) package moves might lose all history for essentially the same files > 5) entries for all commits show up, including those that weren't > originally tracked in ChangeLog for some reason > All these problems are fixed if we don't re-generate the *existing* ChangeLogs. We should simply archive the existing ChangeLog, and append to it after the move to git. Since the beginning, we've been working with the assumption that ChangeLogs can be edited. This has caused a *lot* of quirks to appear as you've demonstrated. Infact, if you do the same experiment on the openrc ChangeLog, you'll see that it's too much work to regenerate the current ChangeLog because a few commits managed to change the encoding of names in the file, and a reverse-patch had to be applied to fix it. A number of developers have made this mistake, and it shows up across the tree. > If a move to VCS-generated ChangeLogs is to be made, it appears the > council has to decide that the following is desirable: > - a commit message is supposed to be always right/correct > - since the commit message is right, either > - repoman commit runs echangelog, or > - ChangeLogs are generated on current CVS as well > - any typos and incorrect refs, bugs, messages, etc. are accepted as > drawback of the system that does not compare to its advantages We can append to existing commit messages using git-notes. Typos are hard to fix, but using git-notes to include sed commands, we can hack up a solution if there's a *pressing* need for it. As a result, commit messages are supposed to be double-checked with git log -p before pushing; but if you make a mistake, that can be fixed as well. > - it is accepted that all current information in the ChangeLogs gets > lost in favour of the VCS commit messages This is not an issue if we archive and re-use the current ChangeLogs. > - there is no point in discussing what should be in or out of a > ChangeLog, since by definition, "everything" is in (and tools should > effectuate so ASAP) > This issue will come up again if we implement commit-message limiting using a [trivial] tag. > If the council deems a separate ChangeLog file useful, they decide that: > - ChangeLog messages can (and sometimes should) be different from commit > messages, as they are intended as information for users In git, there's no harm with making commit messages verbose, so we should give as much information as possible. However, if some developers *really* don't want some lines to show up in the ChangeLog, they can prepend it with a '#omit' (or similar), and the ChangeLog-generating script will skip those lines. > - editting ChangeLog messages is necessary to emit the most correct > information to our users at all times Once again, git-notes. > - a clear policy is necessary on what is going in the ChangeLog and what > not (like the current "common sense" discussions going on and the > updated devmanual) However, with git the issue is simplified because then developers will stop relying on ChangeLogs for information, and ChangeLogs will be used entirely to convey information to users. > - basically nothing changes, and the whole idea of generating ChangeLogs > from VCS is no longer a point of discussion > I'm not sure I understand this. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] ChangeLog added to default-linux/x86
I am sending this out (and cross-posting it) to let everyone know that I have just added a ChangeLog to default-linux/x86 to track changes. Anyone who makes any changes to the default-linux/x86 profile, or any of the sub-profiles, should make a ChangeLog entry. It works perfectly fine with "echangelog" so it should be easy to update. This will help us keep track of changes, especially USE flag changes, and also changes to use.mask and package.mask settings. The amd64 team has already done this, and I recommend that other architectures do it, too. Thanks, -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
