> 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
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
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
> > wond
> 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
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 gener
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',
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 i
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 som
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 s
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,
> 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 b
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 c
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 c
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 Change
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 impleme
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 thi
-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 git2
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
> 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 autogene
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
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.
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
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 co
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
-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 o
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/hook
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 gi
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 in
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
Exactl
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
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:
> > >> Aho
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
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
-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 s
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 wr
> 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
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 actua
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 v
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, a
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 c
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 gi
> 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: Com
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
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 pr
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
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 no
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:
>> h
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 c
> 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
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
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.
> ... ?!??!#??$>@%%*%**%@!!!
>
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
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
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, a
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
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
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 w
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 ch
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?
>>>
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
> > 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 th
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 t
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 dis
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 car
y 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:
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,
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
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
> > peop
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
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
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 Cha
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
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 entri
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
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 retaine
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
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 thi
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 f
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 "echang
79 matches
Mail list logo
