[gentoo-dev] updated gentoolkit with echangelog modification

[gentoo-dev] updated gentoolkit with echangelog modification

[Aron Griffis]

I just updated gentoolkit to version 0.1.21.  This version includes two
changes:

1. echangelog now follows the older, sanctioned format for the
   ChangeLog.  This means that all new entries are added at the top.  A
   new version or revision will cause a new *version string.

2. There is now a man-page for echangelog

Aron

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Nicholas Wourms]

Aron Griffis wrote:
> I just updated gentoolkit to version 0.1.21.  This version includes two
> changes:
> 
> 1. echangelog now follows the older, sanctioned format for the
>    ChangeLog.  This means that all new entries are added at the top.  A
>    new version or revision will cause a new *version string.

I don't think this is appropriate for -dev, but since you 
started it here, I'm going to comment.  Why are you doing 
this?  Sanctioned or not, the "old" way was never enforced, 
and not clearly stated as policy in the developer's 
handbook.  Also, many prefer the new way.  Let's consider this:

Old Way:
Changes were spread all willy-nilly over the Changelog in 
chronological order.  There was no organization other then 
that, so it was often difficult to isolate which specific 
revision was changed at a glance and when.  This, obviously, 
doesn't scale well when we start getting changelogs with 
100+ entries

New Way:
Changes are still in chronological order, but they are 
indexed under each specific ebuild preceded by the star. 
that means, if I want to know what's changed to what 
version, I can quickly scan the *'ed entries for the 
revision I want and there you go.  As for finding out 
overall what's changed in the last few days, that is also 
just as easy as before.  I'd merely scan the the top portion 
of each revision.  This method scales much better and keeps 
Changelog entries neat and orderly, even when faced with 
100+ entries.

So, for the time being, can we put echangelog back to the 
way it was until this is further discussed?

Comments welcomed.

Cheers,
Nicholas


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

Nicholas,

I agree with all your reasons but I don't think I should revert this
change without a general consensus.  Here is what happened in the
discussion a while ago, by my recollection:

When I announced echangelog, lots of people liked it and also liked the
new format.  Dan Armak was concerned about consistency in the ChangeLogs
so he asked Daniel Robbins about the sanctioned ChangeLog format.
Daniel said that the old way was the right way.  There was a flurry of
continued discussion, a number of developers spoke up who felt one way
or the other.  In the end, there was no real decision except that Daniel
did not recant his earlier statement.

At the time, I had just finished putting some work into echangelog to
make it use the new format, so I was hesitant to change the tool.  Since
then, the issue has come up a couple times on IRC that echangelog is
still using the new format as opposed to the right format.  For that
reason, I finally made the change.

The code is still in echangelog; it's trivial to re-enable the new
format.  However I don't think it should change until the discussion has
been re-awakened and Daniel has said okay.  Generally we can arrive at
decisions without Daniel's blessing, but since he effectively vetoed it
last time, I think we need to use the old format unless he says
differently.

Regarding -core vs -dev, I think this is a fine discussion for -dev;
there may be outside input that would be beneficial.  After all, the
last time we talked about it was on -core and the discussion died 
out.  ;-)

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Daniel Armyr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| I don't think this is appropriate for -dev, but since you started it
| here, I'm going to comment.

Oh, so is this one of those "98% of the discussions held on -core are
not interesting"?

|Why are you doing this?  Sanctioned or not,
| the "old" way was never enforced, and not clearly stated as policy in
| the developer's handbook.  Also, many prefer the new way.  Let's
| consider this:

What about
~
***************************************************************************
~  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account
~  of all changes made to a set of ebuilds. That means that the most 		
recent ChangeLog entry *always* goes at the top of the file. More
~  explanation below.
***************************************************************************

I normally wouldn't care, but since the topic was wildly discussed just
a few days ago and writing proper ChangeLogs was mentioned as a must.

//Daniel Armyr
- --
=========================================
daniel.armyr@home.se     f00-dar@f.kth.se

C118 KEVII Hall
1A Kent Ridge Rd S.119224
Singapore                 PGP@pgp.mit.edu
=========================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+rHRMhxtTUWLs2lERAtNQAKCkFB01qL9AJaEDPVoxjtm2ZXTQ4wCfXVdi
FZmAQTPjdMHPOlCy+iWcMDY=
=YH6f
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Nicholas Wourms]

Daniel Armyr wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> | I don't think this is appropriate for -dev, but since you started it
> | here, I'm going to comment.
> 
> Oh, so is this one of those "98% of the discussions held on -core are
> not interesting"?

Frankly, I found the signal->noise ratio to be quite 
unacceptable.  The volume was way to high to be able to 
sensibly keep up with discussions.  Too much stuff which 
belonged on other lists was discussed here instead of 
development.  Also, I was concerned that this might not be 
appropriate to discuss here since the decision was made by 
my superiors and without any prior notice.  I was worried 
that bringing this up here would be overstepping my bounds. 
  However, I agree with Aron that community feedback would 
be useful.

> |Why are you doing this?  Sanctioned or not,
> | the "old" way was never enforced, and not clearly stated as policy in
> | the developer's handbook.  Also, many prefer the new way.  Let's
> | consider this:
> 
> What about
> ~
> ***************************************************************************
> ~  THIS IS IMPORTANT: The ChangeLog format is a *chronological* account
> ~  of all changes made to a set of ebuilds. That means that the 
> most        
> recent ChangeLog entry *always* goes at the top of the file. More
> ~  explanation below.
> ***************************************************************************

Well, it's hard to explain without some background.  That 
change was only made recently (check the viewcvs history for 
that file).  This debate has been ongoing for some time now. 
  When I started, there was no official policy in the 
developer's and ebuild policy guides on the web site.  To my 
knowledge, the only place that mentions it is still only the 
skel.ChangeLog.  As was stated, it wasn't enforced and when 
I was trained, I was told to follow the format I found in 
current ebuilds.  It just so happened that I followed the 
format of the Gnome ebuilds when I first started, thus I was 
led to believe that the "new" style was the correct way to 
do things.  Later, I realized the other way, but I became 
convinced that the "new" style made more sense.  Anyway, 
that's my take...

> I normally wouldn't care, but since the topic was wildly discussed just
> a few days ago and writing proper ChangeLogs was mentioned as a must.

What defines "proper" ?  Can you provide some arguments why 
the old style is more proper then the new style?  Does it 
scale well?  Which makes more sense in the short-term until 
a more permanent, extensible format can be developed?  I'd 
like to hear your views on readability.  Sure it isn't at 
all like the GNU sanctioned change log entries, but lets not 
  do it just because it is the way the GNU people do it. 
Anyhow, comments are appreciated, and thanks for your feedback.

Cheers,
Nicholas


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Daniel Armyr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| Frankly, I found the signal->noise ratio to be quite unacceptable.
| The volume was way to high to be able to sensibly keep up with
| discussions.
Yes, perhaps. I posted a comment to bug #19220. And I definately respect
that policy can and must change.

| What defines "proper" ?
Whatever I read in the manuals and documentation presented to me when I
ask how to do things.

If policy is wrong, change it. If the docs are wrong, rewrite them, or
at least put a note saying they are out of date. But this is perhaps
wishful thinking. We are all volunteers after all.

//Daniel Armyr
- --
=========================================
daniel.armyr@home.se     f00-dar@f.kth.se

C118 KEVII Hall
1A Kent Ridge Rd S.119224
Singapore                 PGP@pgp.mit.edu
=========================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+rVA4hxtTUWLs2lERAoZuAKCqGEANV3VQkYGsiqrewkfPsqLw/ACgsG3f
BrNx3Xp1Ae0ZJ9iYPsIn/Uk=
=qOqF
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On Mon, 2003-04-28 at 15:29, Nicholas Wourms wrote:

> Frankly, I found the signal->noise ratio to be quite 
> unacceptable.  The volume was way to high to be able to 
> sensibly keep up with discussions.  Too much stuff which 
> belonged on other lists was discussed here instead of 
> development.  Also, I was concerned that this might not be 
> appropriate to discuss here since the decision was made by 
> my superiors and without any prior notice.  I was worried 
> that bringing this up here would be overstepping my bounds. 
>   However, I agree with Aron that community feedback would 
> be useful.
> 

I think the big issue was that -dev was unmanageable at some
stage, so we rather just did discussions there.  And then
-core because -dev/-user 8)

It was anyhow not really set in stone by anybody in authority.
I really do not think anybody would have moaned or noticed (:P)
anyhow if you posted to -dev, as long as you do not flame
somebody ;)


Regards,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Evan Powers]

On Monday 28 April 2003 09:29 am, Nicholas Wourms wrote:
> do things.  Later, I realized the other way, but I became
> convinced that the "new" style made more sense.
...
> Can you provide some arguments why
> the old style is more proper then the new style?  Does it
> scale well?  Which makes more sense in the short-term until
> a more permanent, extensible format can be developed?  I'd
> like to hear your views on readability.

The more I think about it, the more I think the "old" style is ultimately a 
better native storage format, and the less I agree with you about the 
scalability of the "new" format. I'll argue my point by discussing how to 
perform the different operations one performs on a change log.

The short summary of the following is that with the "old" style:
1) you can leverage existing software or write simple software to mitigate the 
conveniences of the "new" format
2) with the "new" format, you have to write more complicated software to 
mitigate the conveniences of the "old" format; existing software is not much 
help
3) as the log grows, the time required to perform operations on the "new" 
style is at least O(n) worse (assuming O(n^3)/O(n^2) = O(n)) than the same 
operation on the "old" style

The operations are:
1) adding a new entry which touches one ebuild
2) adding a new entry which touches several ebuilds
3) extracting the most recent changes of a particular ebuild
4) extracting the most recent changes across all ebuilds
5) more complicated operations:
	a) changes made by a developer
	b) changes made within a time range
	c) ...

Let's assume that we're willing to use software to help us, and write it if 
necessary, in order to hit the optimal native format.

OK, sort-of-big-O analysis of operations on the "old" format (n is the number 
of entries in the changelog, e the number of ebuilds):
1) O(1) [just add it to the top]
2) O(1)
3) O(n) [iterate over the n entries and print those against the specified 
ebuild]
4) O(1) [just take the top few]
5)
	a) O(n) [iterate over the n entries and print those by the developer]
	b) on average, O(n/2) [find the beginning of the range and print it]

Note that, for each query operation:
1) "less ChangeLog", run a / search will work
2) "grep -A nnn" almost works
3) only need simple awk/perl to extract the result

sort-of-big-O analysis of operations on the "new" format:
1) on average, O(n/2) [have to find the ebuild section]
2) O(n) [not cleanly possible, unless you duplicate the log in each section or 
split it apart and tag each piece with something unique to the original 
changeset]
3) on average, O(n/2) [have to find the ebuild section]
4) O(n*log(n)) [have to resort the entries; assume best known sorting algo.]
5)
	a) O(n^2*log(n)) [have to iterate over entries to find those by a particular 
developer (number presumably proportional to n), then sort them]
	b) about O(n^2*log(n)) [similar to 5a]

Note that the new format is never more efficient than by a coefficient, and is 
in general significantly worse. Further:
1) less searches are useless
2) "grep | sort" will give you the line numbers
3) awk/perl software doubles in complexity (as measured by L.O.C.)

Evan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Evan Powers]

On Sunday 27 April 2003 06:12 pm, Nicholas Wourms wrote:
> Old Way:
> Changes were spread all willy-nilly over the Changelog in
> chronological order.  There was no organization other then
...
> New Way:
> Changes are still in chronological order, but they are
> indexed under each specific ebuild preceded by the star.

When sorting log entries you can either sort by ebuild name first then 
timestamp, or sort by timestamp first then ebuild name; neither is any more 
or less organized than the other. But obviously certain questions are 
answered most readily when the entries are sorted (name, timestamp), and 
other questions are answered more readily when the entries are sorted 
(timestamp, name). Maybe developers ask more questions where (name, 
timestamp) is most convenient, but I'm not sure (timestamp, name) isn't more 
convenient for users. So I doubt the issue is cut-and-dry.

In any case, it's quite easy to convert one sorting into the other in 
software, so probably the best course of action is to extend echangelog (or 
create another utility, since users would probably use it) which can output 
whichever form isn't decided upon as the default.

> > 1. echangelog now follows the older, sanctioned format for the
> >    ChangeLog.  This means that all new entries are added at the top.  A
> >    new version or revision will cause a new *version string.
>
> I don't think this is appropriate for -dev

Whyever not?

Evan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 545 bytes --]

On Monday 28 April 2003 09:52, Evan Powers wrote:
> In any case, it's quite easy to convert one sorting into the other in
> software, so probably the best course of action is to extend echangelog (or
> create another utility, since users would probably use it) which can output
> whichever form isn't decided upon as the default.
>

In any case it should also at the same time resort "wrong" Changelogs, as they 
are now quite mixed.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Aron Griffis]

Paul de Vrieze wrote:	[Mon Apr 28 2003, 06:12:24AM EDT]
> In any case it should also at the same time resort "wrong"
> Changelogs, as they are now quite mixed.

I agree.  I will add that capability to echangelog or write a second
utility, whichever makes more sense after investigation.

Aron

--
gentoo-dev@gentoo.org mailing list