Council May Summary: Changes to ChangeLog handling

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Nirbheek Chauhan-2
On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel <[hidden email]> wrote:
>
>> So we come back to the problem being *CVS* not ChangeLog rules.
>
> Well of course we can just tell everyone "go look it up on sources.gentoo.org".
> However, this is a different discussion.
>

sources.gentoo.org is a much worse (and slower) solution than cvs log.
The main advantage of a ChangeLog (and of git) is that it allows you
to check the history locally, without needing access to the network.

>> All this is such a massive waste of time. Can't we just expend this
>> energy on the move to git?
>
[snip]
> We're not talking about future plans here but about the current situation.
> And about how to deal with it.
>

The current situation is:

(a) Not dire.
(b) Not urgent.

And if we decide, hey, let's move to git instead of having this
discussion, the current situation is also:

(c) A waste of everyone's time.

So no, future plans are not independent of the current situation, and
a move to git *is* a way to deal with the current situation.

In effect, we kill (at least) two birds with one stone and prevent a
lot of argument and bad blood.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Rich Freeman
In reply to this post by Duncan-42
On Wed, Jun 1, 2011 at 12:44 PM, Duncan <[hidden email]> wrote:
> The current "every change" policy goes overboard, I doubt anyone
> disagrees, but it's worth repeating the point someone else made already,
> every added exception makes the rule harder to remember.  The four
> numbered exceptions (plus my proposed exception to the exception) above
> are IMO a reasonable compromise between practicality and simplicity, but
> getting much more complicated than that and... IMO it's better to stay
> simple.

I think that we need a simple policy like:
Write up Changelogs for any change that impacts what gets installed on
our user's computers.

Then we can write up some guidelines about how to apply this policy in practice.

I think the problem is that we're getting a bit legalistic here.  I
have no idea why we even needed the policy change.  IMHO what should
happen is:

1.  Dev does something significant and doesn't update a Changelog.
2.  QA or another dev calls them on it.  Tells them not to do it again.
3.  Dev does it again.
4.  QA or another dev escalates to devrel.  Devrel deals with the
issue, resulting in either a dev who takes the rules more seriously or
one less dev.

What it almost sounds like to me is that step 4 is breaking down.
Perhaps somebody is arguing "well, it isn't clear in the rules so you
can't do anything to me."  To that my only answer is "sure we can!"
When it comes to money and taxes we need to have pretty clear rules
for legal reasons, but when it comes down to expecting devs to be
mature and team players, I don't think that we really need 14 appeals
and a team of lawyers to eliminate every loophole in our policies.  If
a misunderstanding is genuine then everybody should get past it
quickly and maybe we update the policy to be more clear.  When
policies are flaunted despite explanation, and the authority of devrel
or QA or whatever and ultimately the council (on appeal) is
questioned, then we're not playing like a team.  It is amazing what
intelligent people can fail to understand when getting something they
want depends on it.

More rules will never save an organization.  Sometimes you need rules,
but I think that for a group like Gentoo to work well we need to keep
them to a minimum.  "Well, that's not written in black and white so I
won't cooperate until it is" is no reason for anybody to pause even a
moment before escalating.  Unclear policies are a reason to assume
good intentions - not a reason to overlook obvious bad intentions.
You can't solve a people problem with a better algorithm.

Just my two cents...  That, and in the big scheme of things this is a
bit of a tempest in a teapot but I do share concerns that QA is an
attitude and small problems today just lead to big ones tomorrow.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Diego Elio Pettenò
Il giorno mer, 01/06/2011 alle 18.59 -0400, Rich Freeman ha scritto:
> Write up Changelogs for any change that impacts what gets installed on
> our user's computers.
>

This is not really a good approach; Peter's approach is more reliable on
this.

Let me explain: an EAPI bump _should not_ impact what gets installed. On
the other hand, I'd argue it _should_ be in the ChangeLog:

a) it is a functional change: it changes _a lot_ the way the package
manager sees  the ebuild — even though one argues that if the package
manager is perfectly compliant the result wouldn't change, it might very
well expose a bug in the package manager;

b) we can't assume nobody makes mistakes: "it's such a minimal change I
cannot have made a mistake" is no way to argue a policy; mistakes are
possible by anyone, and any change that is not strictly trivial
(whitespace, comments) should be treated as a possible entrypoint for a
mistake.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/



Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Dale-46
In reply to this post by Rich Freeman
Rich Freeman wrote:

>
> I think that we need a simple policy like:
> Write up Changelogs for any change that impacts what gets installed on
> our user's computers.
>
> Then we can write up some guidelines about how to apply this policy in practice.
>
> I think the problem is that we're getting a bit legalistic here.  I
> have no idea why we even needed the policy change.  IMHO what should
> happen is:
>
> 1.  Dev does something significant and doesn't update a Changelog.
> 2.  QA or another dev calls them on it.  Tells them not to do it again.
> 3.  Dev does it again.
> 4.  QA or another dev escalates to devrel.  Devrel deals with the
> issue, resulting in either a dev who takes the rules more seriously or
> one less dev.
>
> What it almost sounds like to me is that step 4 is breaking down.
> Perhaps somebody is arguing "well, it isn't clear in the rules so you
> can't do anything to me."  To that my only answer is "sure we can!"
> When it comes to money and taxes we need to have pretty clear rules
> for legal reasons, but when it comes down to expecting devs to be
> mature and team players, I don't think that we really need 14 appeals
> and a team of lawyers to eliminate every loophole in our policies.  If
> a misunderstanding is genuine then everybody should get past it
> quickly and maybe we update the policy to be more clear.  When
> policies are flaunted despite explanation, and the authority of devrel
> or QA or whatever and ultimately the council (on appeal) is
> questioned, then we're not playing like a team.  It is amazing what
> intelligent people can fail to understand when getting something they
> want depends on it.
>
> More rules will never save an organization.  Sometimes you need rules,
> but I think that for a group like Gentoo to work well we need to keep
> them to a minimum.  "Well, that's not written in black and white so I
> won't cooperate until it is" is no reason for anybody to pause even a
> moment before escalating.  Unclear policies are a reason to assume
> good intentions - not a reason to overlook obvious bad intentions.
> You can't solve a people problem with a better algorithm.
>
> Just my two cents...  That, and in the big scheme of things this is a
> bit of a tempest in a teapot but I do share concerns that QA is an
> attitude and small problems today just lead to big ones tomorrow.
>
> Rich
>
>    

I'm not a dev, just a user but I do follow this list and read most
things posted here.

The point of the discussion is this.  Someone didn't log something that
should have been logged.  Even after it was posted that the change is
supposed to be logged, the person that didn't think he should log it
said the rules didn't say he had to log it.  So, it appears that #1, #2
happened but the rules wasn't clear enough so it was changed.

I think the point of the discussion is this.  The rules wasn't clear
enough so they were changed to be much clearer.  From my understanding,
the NEW rules say if you touch it, log it.  Thing is, that seemed to
have went to far.  So, round two is to smooth out the edges and get it
back to what it was except in writing this time.  That way, if this
happens again, another dev, user, devrel or whatever can point to the
rules and settle the argument quickly.

It would be nice if when this originally started, the reply would have
been "sorry, I didn't realize.  It won't happen again".  That could have
been the end of it and it would have ended loooooong ago.  :-)

I do agree with your post tho.  Sometimes you etch something in stone
then realize you misspelled the thing.

Dale

:-)  :-)

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Jorge Manuel B. S. Vicetto-2
In reply to this post by Nirbheek Chauhan-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-06-2011 19:50, Nirbheek Chauhan wrote:

> On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel <[hidden email]> wrote:
>>
>>> So we come back to the problem being *CVS* not ChangeLog rules.
>>
>> Well of course we can just tell everyone "go look it up on sources.gentoo.org".
>> However, this is a different discussion.
>>
> sources.gentoo.org is a much worse (and slower) solution than cvs log.
> The main advantage of a ChangeLog (and of git) is that it allows you
> to check the history locally, without needing access to the network.
>
>>> All this is such a massive waste of time. Can't we just expend this
>>> energy on the move to git?
>>
> [snip]
>> We're not talking about future plans here but about the current situation.
>> And about how to deal with it.
>>
>
> The current situation is:
>
> (a) Not dire.
> (b) Not urgent.

(c) has irked enough developers and users that people pushed council to
update the policy about the use of ChangeLogs.

> And if we decide, hey, let's move to git instead of having this
> discussion, the current situation is also:
>
> (c) A waste of everyone's time.
>
> So no, future plans are not independent of the current situation, and
> a move to git *is* a way to deal with the current situation.
>
> In effect, we kill (at least) two birds with one stone and prevent a
> lot of argument and bad blood.

To be clear I support the goal to move our tree to git.
However, I'd like to point out that simply moving to git will leave us
in the same state. Assuming everyone agrees that git is far more useful
than cvs to check for changes in the tree, a simple but important issue
remains: the plan is to move the "development tree" to git, but to keep
the rsync mirrors for users. So the "move to git" doesn't fix the issue
for users or developers using an rsync tree.
One solution that has been proposed before and that was raised again in
this thread is to generate ChangeLogs directly from scm commit messages.
That is already a solution with cvs, so moving to git won't help here.
The same objections that have been raised about doing it for cvs, not
being able to use different messages for the commit message and in
ChangeLog (something I understand but admit have hardly used before),
are also valid if we move to git.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN5stWAAoJEC8ZTXQF1qEPIPMQAJOBJxGkWJZ3saNdQvAjbR7l
KQdLHbO3IdUTBixqSqnmBXop4d6XFBd6lZyjiLu29x9xBn68wE4gm7rlpulITs6R
Yqh4ASyLkUF88qezmqdkBaIy/TUGpGS7ZQWMu7ViarhPtLpcyrVWIh8U0T7oJZBh
offLYHiQK9dDajLro83aIGLfRlLEYTB9MhjHegv8sDTUCr+ti23OuKjO0CoI7LFx
yYdnzkA1YQWA1MGj6iEAVHzcy+RsaGK1QfVn26qAyly3Mg4mPkbKjtIHUEleIV0X
TiWPQfNOvPbbNNyuaJ2cBZoGSTLtTstwUKMccYspQawCpDz0h2yNxNLtVS5ws5AO
HBvfuWROKtWQ90hSiHb5dy13KXhRYR0CZzGPPLMs316YzdsFtKRL5AG3ywzLT2Bu
Dj/wiUoRIRhoPuBTRskCxmXBd04nE/MtDZM/MRn0OZE9zHeYvZYIqCtWVXaGejtZ
uID3LxOdGvJn07+TeH7/i8ap4zchRvwZaW6H9LBFr5bIHzKEFPUAfL3NqquGj66d
HOHsh/RdPG25gKAZy5/zJ92lsRbFyZlxZFNYoTBTSFg89z7YldPMMxPPpNMWro+n
ZzhyourKYprtt2+ZI05gPB/f24KMBhZY8kALoORSeNpUxBwTQ/aanpbKKqjFcfuv
j0asDqRgkHAvpF3aTmaI
=cSzK
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Matt Turner-5
On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto
<[hidden email]> wrote:
> To be clear I support the goal to move our tree to git.
> However, I'd like to point out that simply moving to git will leave us
> in the same state. Assuming everyone agrees that git is far more useful
> than cvs to check for changes in the tree, a simple but important issue
> remains: the plan is to move the "development tree" to git, but to keep
> the rsync mirrors for users. So the "move to git" doesn't fix the issue
> for users or developers using an rsync tree.

Temporarily or permanently?

One of the huge benefits in using git would be really fast emerge
--syncs. Not having some kind of system for migrating users to git
seems like a lot of the benefits are lost.

Matt

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Jorge Manuel B. S. Vicetto-2
In reply to this post by Rich Freeman
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-06-2011 22:59, Rich Freeman wrote:
<snip>

> I think the problem is that we're getting a bit legalistic here.  I
> have no idea why we even needed the policy change.  IMHO what should
> happen is:
>
> 1.  Dev does something significant and doesn't update a Changelog.
> 2.  QA or another dev calls them on it.  Tells them not to do it again.
> 3.  Dev does it again.
> 4.  QA or another dev escalates to devrel.  Devrel deals with the
> issue, resulting in either a dev who takes the rules more seriously or
> one less dev.
>
> What it almost sounds like to me is that step 4 is breaking down.
> Perhaps somebody is arguing "well, it isn't clear in the rules so you
> can't do anything to me."  To that my only answer is "sure we can!"

Rich,

besides a disagreement on how to deal with policy issues (as you can
read in my proposal to update GLEP48), the issue here is *exactly* that
whenever developers or QA warned *repeatedly* the people that don't
update ChangeLogs (a very restrict minority of developers), they've
always tried to find loopholes in the policy and argued others had no
support for their request.
About step 4 breaking down, the DevRel process would face the same
hurdle as the above, but then there's another important point that
people really need to think about: Do we really want to take all
technical issues to DevRel and in the limit fire people "only" for that?
I'm not saying that technical issues aren't relevant for DevRel or that
people can't get "fired" because of them, but in my experience the role
of DevRel is more to evaluate the ability and willingness of developers
to work in the team than to fire someone because they failed to apply a
policy here or there - to be clear, I'm talking here about mistakes and
ignorance, not about defiance and disregard for others and policy -
which in my view constitute the sort of behaviour patterns that DevRel
is meant to evaluate, help fixing and, when everything else fails, to
remove.

> When it comes to money and taxes we need to have pretty clear rules
> for legal reasons, but when it comes down to expecting devs to be
> mature and team players, I don't think that we really need 14 appeals
> and a team of lawyers to eliminate every loophole in our policies.  If
> a misunderstanding is genuine then everybody should get past it
> quickly and maybe we update the policy to be more clear.  When
> policies are flaunted despite explanation, and the authority of devrel
> or QA or whatever and ultimately the council (on appeal) is
> questioned, then we're not playing like a team.  It is amazing what
> intelligent people can fail to understand when getting something they
> want depends on it.

The sad fact is that increasingly it seems our developer base, or a
significant part of it, is losing all "common sense".

> Just my two cents...  That, and in the big scheme of things this is a
> bit of a tempest in a teapot but I do share concerns that QA is an
> attitude and small problems today just lead to big ones tomorrow.
>
> Rich

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN5s33AAoJEC8ZTXQF1qEPFEcP/2tLhDBXR24AF/GunN5BHKQy
+fganpXgO1OqZcFX6tEG7h+j6fjbSFwTPaNG9CiSyrz/NsYseuL7wzkxXZawfUax
ftiaFuOuKvLd56AizO0y0YNfrvIVxp2rTPas17yg+Noqgm3Hd5voh2J9FkN3x8X9
PPd8yA8f4DXA4ptdihGS694edtDtT2WwMVGbPuGl6I3U0tlLYlPyGoQDRaAhvQoB
LnOzqrYxFxDxcEUWyae25dp3DI1rhqWw8cUc1We6lOZENOtGxiLuxToIorVB8lAs
b3SB326WI5XJRyHWgWtcPkF9OrQvpsDXgO9YEqBbsXn3w6vsj2rD8IeswMGNt66R
h4cmHEwXEyZ9iQPEPwJKi/UI6MZHTM5ezYJDAbBxBuLt5dPuR7RQBspHkyjSSFe8
/RPLDYy0UYnh0uUw1Rq7DCB5rhLf9acnGhT247q+5PNMcfdN3aBYPIK2ruqTQGKD
SfNefj0tKJCXd/TsQUSn7GP7SLjiBNh7Ym+qy8Q5TFQs49vhYprbqRn6RdsMpPe6
eeHNiNzSw9Cfi6n/ZidHlvOXUM7g2yVOLzJ9ChzZRhftxABMWMJCzYvQfjE6Eqey
+pVX372nI2G9e9UErS8/Zfxxxw/+vOE7DLLYKe9HSXeM3XdNwEzotdcN+Xxth3f/
R5tVPjMUL3TACOcqA/zr
=vsto
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

pva0xd
In reply to this post by Matt Turner-5
В Срд, 01/06/2011 в 19:37 -0400, Matt Turner пишет:
> On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto
> <[hidden email]> wrote:
> > To be clear I support the goal to move our tree to git.
> > However, I'd like to point out that simply moving to git will leave us
> > in the same state.

++
ChangeLog files are text to be distributed to our users so they are
completely independent of vcs we use.

> > Assuming everyone agrees that git is far more useful
> > than cvs to check for changes in the tree, a simple but important issue
> > remains: the plan is to move the "development tree" to git, but to keep
> > the rsync mirrors for users. So the "move to git" doesn't fix the issue
> > for users or developers using an rsync tree.
>
> Temporarily or permanently?
>
> One of the huge benefits in using git would be really fast emerge
> --syncs. Not having some kind of system for migrating users to git
> seems like a lot of the benefits are lost.

Is git faster then rsync? I've never done any checks but it'll be
surprising if it will. Another useful feature of rsync is --exclude that
allows some categories to be excluded (for size and speed efficiency),
e.g. my servers don't need kde-* and games-*. Also taking into account
that we use portage tree on embedded devices where again both size and
speed really matters it looks like the answer on your question is
"permanently".

--
Peter.



Reply | Threaded
Open this post in threaded view
|

Re: RFC: better policy for ChageLogs

Duncan-42
Peter Volkov posted on Thu, 02 Jun 2011 09:09:04 +0400 as excerpted:

>> One of the huge benefits in using git would be really fast emerge
>> --syncs. Not having some kind of system for migrating users to git
>> seems like a lot of the benefits are lost.
>
> Is git faster then rsync? I've never done any checks but it'll be
> surprising if it will.

That's a question that has come up before.  I don't know the answer...

> Another useful feature of rsync is --exclude that
> allows some categories to be excluded (for size and speed efficiency),
> e.g. my servers don't need kde-* and games-*.

Git has similar options in the form of the .git/info/exclude file at the
(local) repository level, and .gitignore files at the subdir level (these
are normally synced with the repo but of course can be excluded locally by
the above repository level file, if desired).

Patterns similar to those used by rsync --exclude are even supported. =:^)

See also the git config core.excludefile command (git-config (1) manpage)
and the gitignore (5) manpage.

> Also taking into account
> that we use portage tree on embedded devices where again both size and
> speed really matters it looks like the answer on your question is
> "permanently".

With shallow checkouts, the size aspect is somewhat mitigated.  However,
it may be that there'd be three user sync options, adding git, to the
current two (rsync and webrsync).

IMO it'd be a real shame to not make the git sync option available to the
user, as a number of projects have already discovered that real community
involvement at the GOOD bug report and above level can increase
dramatically after a switch to git, due to the vastly increased
accessibility and ease of use of tools such as git bisect.

But the *REAL* decison on whether git is ultimately made available at the
user level or not will probably be infra's to make, based not on the
above, but on the very practical question of whether Gentoo's mirror
infrastructure can actually handle the git-pull load.  After all, that's
said to be the reason the CVS tree isn't made directly available to
ordinary users today.  Git should be better than CVS in that regard, but
will it be good /enough/ as compared to the resources demanded by rsync,
or not?  That I don't know, tho I suspect infra and/or the git upgrade
project already has a reasonably educated opinion on the matter.

Of course, someone like Google donating enough hardware and bandwidth to
"make it happen", based on, say, their use of Gentoo as a basis for
ChromeOS, thus making a healthy Gentoo good for them too, might help infra
with its decision.  One can hope. =:^)

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Eray Aslan-2
In reply to this post by pva0xd
On 2011-06-02 8:09 AM, Peter Volkov wrote:
> ChangeLog files are text to be distributed to our users so they are
> completely independent of vcs we use.

Just ditch the Changelogs and be done with it.  The only objection I
know is that changelogs act as a NEWS file.  Well, it is not a good
enough reason in my humble opionion.  Find another way to present NEWS
if it is deemed necessary.

> Is git faster then rsync? I've never done any checks but it'll be
> surprising if it will.

Git usually is faster - except the initial clone.  Basically, rsync
protocol scales with the project size not with change size.

And lastly, while I don't really care either way, I think at least some
of the push back is the result of unfamiliarity with git.  And my
impression is that unless a dev with enough political capital spearheads
the move, this issue will continue to come up for a long time yet.

--
Eray


signature.asc (916 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Nirbheek Chauhan-2
In reply to this post by Jorge Manuel B. S. Vicetto-2
On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto
<[hidden email]> wrote:
> On 01-06-2011 19:50, Nirbheek Chauhan wrote:
>> The current situation is:
>>
>> (a) Not dire.
>> (b) Not urgent.
>
> (c) has irked enough developers and users that people pushed council to
> update the policy about the use of ChangeLogs.


Yes, and I'm surprised that these same developers pushed towards a
negative solution (kick productive people out) rather than a positive
solution (move to git).

>> And if we decide, hey, let's move to git instead of having this
>> discussion, the current situation is also:
>>
>> (c) A waste of everyone's time.
>>
>> So no, future plans are not independent of the current situation, and
>> a move to git *is* a way to deal with the current situation.
>>
>> In effect, we kill (at least) two birds with one stone and prevent a
>> lot of argument and bad blood.
>
> To be clear I support the goal to move our tree to git.
> However, I'd like to point out that simply moving to git will leave us
> in the same state. Assuming everyone agrees that git is far more useful
> than cvs to check for changes in the tree, a simple but important issue
> remains: the plan is to move the "development tree" to git, but to keep
> the rsync mirrors for users. So the "move to git" doesn't fix the issue
> for users or developers using an rsync tree.

Arguably, if developers want to know the history they should use the
copy of the git tree that they're supposed to be having. Relying on
ChangeLogs for history is just silly if you have the complete history
at your fingertips with git.

> One solution that has been proposed before and that was raised again in
> this thread is to generate ChangeLogs directly from scm commit messages.
> That is already a solution with cvs, so moving to git won't help here.

This is not true. One of the main problems of generating ChangeLog
messages from cvs/svn is that you don't have much control over the
`cvs log` output, cvs itself is extremely slow, and cvs maintains log
information *per-file*. Hence ChangeLog generation in the format we
want would be slow/impractical. There's tens of thousands of packages.
How long do you think it'll take to generate ChangeLogs from cvs for
all of them?

Notice how every project that did a move to git from cvs/svn started
auto-generating ChangeLogs[1]. One reason was that ChangeLogs will
*always* cause merge conflicts, and they're duplicate information, so
there's no point keeping them in the local tree. The other reason is
that with git it takes a fraction of a second to generate a ChangeLog
from the commit messages.

1. https://live.gnome.org/Git/ChangeLog

> The same objections that have been raised about doing it for cvs, not
> being able to use different messages for the commit message and in
> ChangeLog (something I understand but admit have hardly used before),
> are also valid if we move to git.
>

Not really. This problem has been raised and the solution is to add a
'[trivial]' or '#trivial' etc tag to the commit message (either
subject of body), and it won't be included in the auto-generated
ChangeLog.

The main issue that people have with not writing ChangeLog messages
for removals is that developers can't figure out when, why, and by
whom an ebuild was removed; because there's no ChangeLog entry, and
cvs log/cvs diff is too painful to use. This makes it hard to fix
breakage.

There's a fringe issue of users wanting to know why an 'old' ebuild
was removed while they're offline in a train or something (and don't
want to keep a cloned git repo around), but that's not reason enough
to kick our second-most-hardworking developer.

In essence, the most basic issue here is *not* users who want to have
all information offline, but the fact that /developers/ rely on
ChangeLog for information because cvs log/diff suck. Note that the
developer in question always wrote proper commit messages, so `git
log` WOULD solve all our problems.

Cheers,

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Ciaran McCreesh-4
On Thu, 2 Jun 2011 16:35:24 +0530
Nirbheek Chauhan <[hidden email]> wrote:
> > (c) has irked enough developers and users that people pushed
> > council to update the policy about the use of ChangeLogs.
>
> Yes, and I'm surprised that these same developers pushed towards a
> negative solution (kick productive people out) rather than a positive
> solution (move to git).

Those developers have been pushing for a move to git for years. There
comes a point where it becomes necessary to accept that the perfect
solution is only the best solution if it will ever happen.

--
Ciaran McCreesh

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Patrick Lauer
In reply to this post by Eray Aslan-2
On 06/02/11 09:40, Eray Aslan wrote:

>> Is git faster then rsync? I've never done any checks but it'll be
>> surprising if it will.
>
> Git usually is faster - except the initial clone.  Basically, rsync
> protocol scales with the project size not with change size.

We're discussing performance of something that takes less than a minute.
I see times of ~30-45 seconds for emerge --sync vs. ~30 seconds for git
pull on the kde overlay.

And then portage takes so much longer to calculate deps anyway ... why
are we discussing the performance of the fastest operation? ;)

> And lastly, while I don't really care either way, I think at least some
> of the push back is the result of unfamiliarity with git.  And my
> impression is that unless a dev with enough political capital spearheads
> the move, this issue will continue to come up for a long time yet.
>
More the complexity of git making simple things an hour-long oddysey
through IRC, trying to find someone who has a clue how to get the HEAD
back ... it's a complex thing that usually gets in the way when I use
more than add, commit and push (and even push is aargh nooo why so
complimacated?!)

But I guess people prefer having to write wrapper scripts around
wrappers to get things done, so I'll just stay out of the way and
reserve the right to point and laugh when funny misbehaviour happens.

--
Patrick Lauer         http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Jorge Manuel B. S. Vicetto-2
In reply to this post by Ciaran McCreesh-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-06-2011 15:34, Ciaran McCreesh wrote:

> On Wed, 01 Jun 2011 18:27:04 +0300
> Samuli Suominen <[hidden email]> wrote:
>> Wouldn't it be better to just trust devs to use common sense in what
>> gets into ChangeLogs, and actually be grateful about if they take the
>> time to sensor the crap out from it, and scrap the whole topic?
>
> This whole thing came about because a select few developers repeatedly
> refused to use common sense, even after having been told to do so on
> numerous occasions. Unfortunately, common sense for some developers
> is running round the room whilst waving their wangs at everyone.

I had meant to send a reply to this message yesterday, saying I
agree with Ciaran on this.


- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJN53JUAAoJEC8ZTXQF1qEPr7MQALJKKNmx6McM93T9c5IepKGJ
k/AGcpbz6V1JRxzLToZigl6ChoRCfp1jIIE0kb8sr9l4R5BpYaIkHyO/o5+uDq/F
cg49IJc9A/syfacD8dcf+5ueLHQXJcZjgreok5gKGjjnrdayntc6ZHFgH569BtuG
8feC+iSa/5AQ9XBQ7JjTNlgblHCyXC9h6YTHOkYCENJT8zMhH0urTZqkrv3oNNVl
RuqsATeyop5aodht2XSlPoNnvJyZOjTo+ZTBfH+pe9q3Cx2XIR8MkPglqBoRucDn
RvPwTjBZLhDX4WyznDjZAZjk4SRU32TvSdxRH0TAnoTmEl/bBeUPB09fWuw6Go6j
cIbp4zAURYBE4QfxjKHG7J5Zzkk9A9YDX/2eDAHPepSnJKr0cpSU7O/lH/SMLpqo
4Cgdo9b83ElyK36madmXYB92S0tMycwWhjJaK8LNODKToLaPvjy3D3dI0iUIKBvn
Sj8WRG/zP4wNwoN25EPSPfArBoVsXnPrl8kIJNpdX3lHzBz7CHdDzFd95dzC4opH
sEVqNEIpyAHfgaXioVOmLgeJyuK9Hr9M5kH5QQpZCuKM7z4AkiVJaRJW8LdpgEMp
8P2CBTKyL8KrFDFw73SRsdt7rCAM28Ukt+HZLbsIOvwGkiRZB9JLy+TzGvvwpJTf
MwnHIigHpPdjbuknKO97
=x5eY
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: Re: RFC: better policy for ChageLogs

Rich Freeman
In reply to this post by Nirbheek Chauhan-2
On Thu, Jun 2, 2011 at 7:05 AM, Nirbheek Chauhan <[hidden email]> wrote:
> On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto
> <[hidden email]> wrote:
>> (c) has irked enough developers and users that people pushed council to
>> update the policy about the use of ChangeLogs.
>
>
> Yes, and I'm surprised that these same developers pushed towards a
> negative solution (kick productive people out) rather than a positive
> solution (move to git).

Getting developers to follow policy and common sense is a people
problem.  Git won't fix that - at best it might help with this
particular issue but not the next 14 that will come up.

I'd highly recommend listening to Donnie's "Assholes are killing your
project" talk.  I think we've come a long way from some of the
problems in the past.  I think that speaking up on lists when you
don't like a policy is healthy for the distro.  However, until policy
is changed it must be followed - especially for something as trivial
as this.

The second-to-last thing I want to see is productive developers
quitting Gentoo over policy frustrations.  The last thing I want to
see is a culture where anybody just does whatever they want to.  Such
a culture turns off far more potential future developers than it keeps
around.  Gentoo is already a very hands-off distro - just about any
dev can do just about whatever they want to improve things and we all
tend to go along with it as long as they're making a positive
contribution.  OpenRC is stable, some people are talking about getting
systemd working and others swear that they'll never run it, others
spend time making Gentoo work on everything from Win32 to BSD to
Plan9, and others look to improve the hardened/selinux experience.
The number of rules that I'd consider "restrictive" in Gentoo is very
small compared to more top-down organizations - we all do what we want
and the users get to choose with some basic safeguards to preserve the
mainstream experience.  There really is no reason to pitch a fit over
the few rules we have in the big scheme of things.

Rich

12