| 1 |
Ok, last shoot, then let put this stuff to sleep. |
| 2 |
Description of the attachment at the end: |
| 3 |
|
| 4 |
Chris Gianelloni wrote: |
| 5 |
> On Mon, 2006-01-02 at 11:25 -0600, Lance Albertson wrote: |
| 6 |
>>> I'm also for telling the users to rsync exclude the ChangeLogs if they |
| 7 |
>>> don't want them instead of getting rid of them or crippling them. |
| 8 |
>> I don't think that's really a solution. That's just a way to minimize |
| 9 |
>> what they get. If you really want to look at a solution, you should |
| 10 |
>> reduce whats actually in the changelog. All the changelogs are in CVS, |
| 11 |
>> and if someone wanted to go look back at any changes, they can either |
| 12 |
>> look at viewcvs or (hopefully soon), grab it via anoncvs. I bet you >80% |
| 13 |
>> of things in the changelogs are for things that are in the attic. I say |
| 14 |
>> we need a way to either have echangelog (or another script) to clean out |
| 15 |
>> changelog entries for things that are in the attic (and make sense to |
| 16 |
>> take out). Maybe another option would be to remove any 'version bump' |
| 17 |
>> type entries that are old as well. |
| 18 |
> |
| 19 |
> OK. I keep seeing this argument about ChangeLog stuff for ebuilds in |
| 20 |
> the Attic and I just think people might not be thinking it totally |
| 21 |
> trough. For example, I made changes to the vmware-workstation ebuilds |
| 22 |
> to force group membership a while back because of a security bug. |
| 23 |
> However, there's been another security bug since, so those changes were |
| 24 |
> made on ebuilds now in Attic, but the change is still valid in the |
| 25 |
> current ebuilds. |
| 26 |
|
| 27 |
Could ignore the revision (-r*) address this issue ? |
| 28 |
|
| 29 |
> |
| 30 |
> I don't see a problem with removing version bump and stabilization |
| 31 |
> messages, but everything else should stay in the ChangeLog for as long |
| 32 |
> as the package is still around. |
| 33 |
> |
| 34 |
>> I just don't see the point of keeping changelog entries for stuff that |
| 35 |
>> isn't even viewable in the tree anymore. We have CVS, the record will be |
| 36 |
>> there, lets use it. We can't cater to every user out there, but come up |
| 37 |
>> with a solid solution that makes sense and still gives them some form of |
| 38 |
>> ability to look back. |
| 39 |
> |
| 40 |
> Because as I stated before, there are many times where the ChangeLog |
| 41 |
> entry for an older ebuild applies to the newer ones. This is especially |
| 42 |
> true when ebuilds are simply copied for version bumps. Removing this |
| 43 |
> information removes a lot of data. Forcing users/developers to use CVS |
| 44 |
> makes it more of a hassle than the gains will give us. |
| 45 |
|
| 46 |
same as before |
| 47 |
|
| 48 |
> |
| 49 |
> Again, I think this is another case of us doing things that aren't |
| 50 |
> necessary rather than educating users. |
| 51 |
> |
| 52 |
> I wouldn't have a problem with seeing ChangeLog in a default |
| 53 |
> RSYNC_EXCLUDES with a nice comment explaining how to get the ChangeLog |
| 54 |
> files. This way we are removing the problem by default, educating |
| 55 |
> users, and still not removing any data or options for our users and |
| 56 |
> developers. |
| 57 |
> |
| 58 |
|
| 59 |
IMHO RSYNC_EXCLUDES it's a bad option, in it's extended version, exclude |
| 60 |
foo/bar could bring to every sort of problems, difficult to address (but |
| 61 |
I've never tryed that ;-). |
| 62 |
|
| 63 |
The attached bash script attempt to purge the ChangeLog (it broke a bit |
| 64 |
but could be solved) |
| 65 |
|
| 66 |
It clean out all entries without corresponding files (*.ebuild files/*) |
| 67 |
It left in place date of addition of euilds and developer that changed |
| 68 |
something |
| 69 |
|
| 70 |
The test is moved in two new files Changelog.{new,old} |
| 71 |
|
| 72 |
be careful, it leave a ".tmp__revisions" in place |
| 73 |
|
| 74 |
The size of the resulting ChangeLog may be less han 50% than the original. |
Archives