From: Francesco Riosa <vivo@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] ChangeLogs and rsync time
Date: Tue, 03 Jan 2006 00:47:37 +0100 [thread overview]
Message-ID: <43B9BB99.7040605@gentoo.org> (raw)
In-Reply-To: <1136227249.7131.1.camel@vertigo.twi-31o2.org>
[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]
Ok, last shoot, then let put this stuff to sleep.
Description of the attachment at the end:
Chris Gianelloni wrote:
> On Mon, 2006-01-02 at 11:25 -0600, Lance Albertson wrote:
>>> I'm also for telling the users to rsync exclude the ChangeLogs if they
>>> don't want them instead of getting rid of them or crippling them.
>> I don't think that's really a solution. That's just a way to minimize
>> what they get. If you really want to look at a solution, you should
>> reduce whats actually in the changelog. All the changelogs are in CVS,
>> and if someone wanted to go look back at any changes, they can either
>> look at viewcvs or (hopefully soon), grab it via anoncvs. I bet you >80%
>> of things in the changelogs are for things that are in the attic. I say
>> we need a way to either have echangelog (or another script) to clean out
>> changelog entries for things that are in the attic (and make sense to
>> take out). Maybe another option would be to remove any 'version bump'
>> type entries that are old as well.
>
> OK. I keep seeing this argument about ChangeLog stuff for ebuilds in
> the Attic and I just think people might not be thinking it totally
> trough. For example, I made changes to the vmware-workstation ebuilds
> to force group membership a while back because of a security bug.
> However, there's been another security bug since, so those changes were
> made on ebuilds now in Attic, but the change is still valid in the
> current ebuilds.
Could ignore the revision (-r*) address this issue ?
>
> I don't see a problem with removing version bump and stabilization
> messages, but everything else should stay in the ChangeLog for as long
> as the package is still around.
>
>> I just don't see the point of keeping changelog entries for stuff that
>> isn't even viewable in the tree anymore. We have CVS, the record will be
>> there, lets use it. We can't cater to every user out there, but come up
>> with a solid solution that makes sense and still gives them some form of
>> ability to look back.
>
> Because as I stated before, there are many times where the ChangeLog
> entry for an older ebuild applies to the newer ones. This is especially
> true when ebuilds are simply copied for version bumps. Removing this
> information removes a lot of data. Forcing users/developers to use CVS
> makes it more of a hassle than the gains will give us.
same as before
>
> Again, I think this is another case of us doing things that aren't
> necessary rather than educating users.
>
> I wouldn't have a problem with seeing ChangeLog in a default
> RSYNC_EXCLUDES with a nice comment explaining how to get the ChangeLog
> files. This way we are removing the problem by default, educating
> users, and still not removing any data or options for our users and
> developers.
>
IMHO RSYNC_EXCLUDES it's a bad option, in it's extended version, exclude
foo/bar could bring to every sort of problems, difficult to address (but
I've never tryed that ;-).
The attached bash script attempt to purge the ChangeLog (it broke a bit
but could be solved)
It clean out all entries without corresponding files (*.ebuild files/*)
It left in place date of addition of euilds and developer that changed
something
The test is moved in two new files Changelog.{new,old}
be careful, it leave a ".tmp__revisions" in place
The size of the resulting ChangeLog may be less han 50% than the original.
[-- Attachment #2: elogcleaner --]
[-- Type: text/plain, Size: 2955 bytes --]
#! /bin/bash
function exit_no_changelog() {
echo "No ChangeLog found"
exit 1
}
function main() {
local ChangeLog="ChangeLog"
local ChangeLogNew="ChangeLog.new"
local ChangeLogOld="ChangeLog.old"
local inside=0
local buffer
CWD="."
pushd "${CVD}" &> /dev/null
[[ -f "${ChangeLog}" ]] || exit_no_changelog
# create a list of each version, remove gentoo specific revisions
#grep ^\* ChangeLog \
# | sed -e 's/^*//;s/ .*//;s/-r[[:digit:]][[:digit:]]*//' \
# | sort \
# | uniq \
# > .tmp__versions
# create a list of each version
grep ^\* "${ChangeLog}" \
| sed -e 's/^*//;s/ .*//' \
| sort \
| uniq \
> .tmp__revisions
# keep track of each modify and author
# FIXME this is a sed job
local entry_pattern='[[:digit:]][[:digit:]]\ [[:alnum:]][[:alnum:]][[:alnum:]]\ 20[[:digit:]][[:digit:]]; '
echo -n "" > .tmp__revisions
while read line ; do
case "${line}" in
${entry_pattern}*:*)
echo "${line}" >> .tmp__revisions
;;
${entry_pattern}*)
echo -n ${line} >> .tmp__revisions
inside=1
;;
*:*)
if [[ inside -eq 1 ]] ; then
echo ${line} >> .tmp__revisions
inside=0
fi
;;
*)
[[ inside -eq 1 ]] && echo -n ${line} >> .tmp__revisions
;;
esac
done < "${ChangeLog}"
sed -i -e 's/:.*$/:/' .tmp__revisions
# mark revisions to keep
local sed_prg f
for e in *.ebuild files/* ; do
buffer="${e%.ebuild}"
buffer="${buffer%-r*}"
sed_prg="${sed_prg};s!^\(.*${buffer}.*$\)!K\1!"
done
sed -i -e "${sed_prg}" \
-e 's/^KK*/K/' \
-e 's/^\([^K]\)/D\1/' \
.tmp__revisions
# attempt to write the purged ChangeLog
echo -n "" > "${ChangeLogNew}"
echo -n "" > "${ChangeLogOld}"
local cl="${ChangeLogNew}"
inside=0
while read line ; do
case "${line}" in
\#*)
echo "${line}" >> "${ChangeLogNew}"
;;
\**)
echo "${line}" >> "${ChangeLogNew}"
echo "${line}" >> "${ChangeLogOld}"
;;
${entry_pattern}*)
if $(grep -q "D${line%%:*}" .tmp__revisions) ; then
cl="${ChangeLogOld}"
echo " ${line%%>*}>:" >> "${ChangeLogNew}"
else
cl="${ChangeLogNew}"
fi
echo " ${line}" >> "${cl}"
;;
*)
echo " ${line}" >> "${cl}"
;;
esac
done < "${ChangeLog}"
# further cleaning
sed -i -e 's/[ \t]*$//' "${ChangeLogNew}"
sed -i -e '$!N; /^ .. ... ....; \(.*\)\n .. ... ....; \1$/!P; D' "${ChangeLogNew}"
popd &> /dev/null
}
main
next prev parent reply other threads:[~2006-01-02 23:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-01 20:35 [gentoo-dev] ChangeLogs and rsync time Francesco Riosa
2006-01-01 21:48 ` Grobian
2006-01-01 22:43 ` [gentoo-dev] " Duncan
2006-01-02 9:26 ` [gentoo-dev] " Francesco Riosa
2006-01-04 9:22 ` Brian Harring
2006-01-01 22:55 ` Ciaran McCreesh
2006-01-01 23:50 ` Andrej Kacian
2006-01-02 9:37 ` Francesco Riosa
2006-01-02 10:44 ` Paweł Madej
2006-01-02 15:00 ` Matti Bickel
2006-01-02 16:37 ` Francesco Riosa
2006-01-02 16:45 ` Matti Bickel
2006-01-02 16:47 ` Henrik Brix Andersen
2006-01-02 17:25 ` Lance Albertson
2006-01-02 18:40 ` Chris Gianelloni
2006-01-02 19:20 ` Lance Albertson
2006-01-02 23:08 ` Paweł Madej
2006-01-03 5:28 ` Donnie Berkholz
2006-01-03 11:47 ` Chris Gianelloni
2006-01-03 12:18 ` Re[2]: " Jakub Moc
2006-01-03 14:29 ` Paweł Madej
2006-01-03 14:35 ` Mike Frysinger
2006-01-02 23:47 ` Francesco Riosa [this message]
2006-01-01 22:59 ` Andrej Kacian
2006-01-02 9:12 ` Francesco Riosa
2006-01-02 21:35 ` Peter Volkov (pva)
2006-01-03 11:50 ` Chris Gianelloni
2006-01-03 17:56 ` Francesco Riosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43B9BB99.7040605@gentoo.org \
--to=vivo@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox