public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: RFC: better policy for ChageLogs
Date: Wed, 1 Jun 2011 18:59:38 -0400	[thread overview]
Message-ID: <BANLkTi=NqFKx_5eo-JVL_2+K5jKYWYCvjw@mail.gmail.com> (raw)
In-Reply-To: <pan.2011.06.01.16.44.59@cox.net>

On Wed, Jun 1, 2011 at 12:44 PM, Duncan <1i5t5.duncan@cox.net> 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	other threads:[~2011-06-01 23:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 10:32 [gentoo-dev] Council May Summary: Changes to ChangeLog handling Petteri Räty
2011-05-20 10:19 ` Mart Raudsepp
2011-05-30 12:03   ` Peter Volkov
2011-05-30 12:23     ` Ulrich Mueller
2011-05-30 18:07       ` William Hubbs
2011-05-30 17:52     ` Michał Górny
2011-05-30 21:55     ` Brian Harring
2011-05-30 22:05       ` Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) Andreas K. Huettel
2011-05-30 22:14         ` [gentoo-dev] Re: Common sense in " Diego Elio Pettenò
2011-05-30 23:38         ` Common sense in [gentoo-dev] " Brian Harring
2011-05-31  0:01           ` Ângelo Arrifano
2011-06-01 15:08       ` RFC: better policy for ChageLogs (was: Re: [gentoo-dev] " Peter Volkov
2011-06-01 15:15         ` [gentoo-dev] Re: RFC: better policy for ChageLogs Markos Chandras
2011-06-01 15:27           ` Samuli Suominen
2011-06-01 15:34             ` Ciaran McCreesh
2011-06-02 11:21               ` Jorge Manuel B. S. Vicetto
2011-06-01 15:39             ` Andreas K. Huettel
     [not found]               ` <BANLkTimgHYKnfbeQJpq829YBeE-5Yz=aEg@mail.gmail.com>
2011-06-01 16:24                 ` Andreas K. Huettel
2011-06-01 19:50                   ` Nirbheek Chauhan
2011-06-01 23:29                     ` Jorge Manuel B. S. Vicetto
2011-06-01 23:37                       ` Matt Turner
2011-06-02  5:09                         ` Peter Volkov
2011-06-02  7:29                           ` Duncan
2011-06-02  7:40                           ` Eray Aslan
2011-06-02 11:20                             ` Patrick Lauer
2011-06-02 11:05                       ` Nirbheek Chauhan
2011-06-02 11:10                         ` Ciaran McCreesh
2011-06-02 14:43                         ` Rich Freeman
2011-06-01 15:30           ` Nathan Phillip Brink
2011-06-01 16:44             ` Duncan
2011-06-01 22:59               ` Rich Freeman [this message]
2011-06-01 23:21                 ` [gentoo-dev] " Diego Elio Pettenò
2011-06-01 23:29                 ` [gentoo-dev] " Dale
2011-06-01 23:40                 ` Jorge Manuel B. S. Vicetto

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='BANLkTi=NqFKx_5eo-JVL_2+K5jKYWYCvjw@mail.gmail.com' \
    --to=rich0@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