[Nix-dev] Re: deepOverride

[Marc Weber]

Excerpts from ludo's message of Sun Jul 11 01:01:53 +0200 2010:
> Hi Marc,
> 
> Marc Weber <marco-oweber at gmx.de> writes:
> 
> > Does someone disagree on removing deepOverrides - reimplementing its
> > usages using the new style?
> 
> What’s the “new style”?  What’s the rationale?

First of all:
- I am interested in this community
- I am interested in collaboration / cooperation (Whatever you call it)
- I am interested in continuing using this project
- I don't want to fork which means building up a new community,
  but I will if I don't see a choice.
- I'd like to discuss these things once and forever - because I'm going to
  use a Nix based Linux forever - because I think its best.
- And I want behaviour which results in fast iteration of patch series
  so that patches can go in or keep out. But I then want to know why.

Let me try to reply to your message - let me also try to explain which
impression I got (This is partially related to this thread - and partially to others).
Sorry for being verbose one last time. Redundancy can
sometimes help to communicate an idea or feeling.

Now replying to your request as short as possible:

=== > What’s the “new style”?  What’s the rationale? as possible:

Shouldn't you know because your mail caused this all?

1) Eelco said he dislikes the commit. (http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=4469)
That's how it started.

By following another leaf of this thread you could have find out yourself easily:

  http://article.gmane.org/gmane.linux.distributions.nixos/4479 [1]
  It points to commit messages and the wiki which contains a very short summary
  telling people that we found a better way to solve this issue - so that its
  less likely to come up again

Let me continue writing a log based on my view about this commit and thread.
I hope that I can put you into the picture fast this way:

http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=4469
  I tried getting more feedaback. Because I want to turn bad commits into
  better commits. However I saw the pattern "I dislike" but no
  alternative a way too often on this list for my taste.

  You interpreted Eelco Dolstra's mail as "should be reverted" (?)
  (http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=4469)
  which is what I critize - because you do no longer talk about the
  commit or the intention of it.
  There is the chance that others see this request for revert thinking
  that you know about the commit.

Looking at the mails only it looks like that:
   
  > > > [ I dislike because .. ] << Eelco (words changed)
  > > revert ?   << me / how to cope with Eelco reply? This was one option
  > yes          << your interpretation

What is your yes based on? Its not based on the commit. You showed it by asking
what it is about in the previous mail. So I ask you for being bore
careful about this.

I'm thankful that Eelco Dolstra proposed an alternative:
http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=4469

On irc I, Eelco and Michael Raskin talked about the alternative.
Michael still had a case he didn't know to solve. Me and Eelco posted
replies:
http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=4469

Now I want to quote one very important line of Michael Raskin:
> Simple and answers my question completely.
> I support this change.  [2]
(http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=4469)

He clearly updates his current thinking about the commit and
communicates it. So you clearly know what you have to work on to improve
a patch.  This way the issue showed by Eelco Dolstra (weekening
the function interface) can be solved.

That's why I sent the patch series actually doing so [1] (see above)
Now I pod Eelco (and you?) to give feedback again. Because the
combination of the mail of Eelco and your reply could make someone think
that the patch was not ready enough. So its your responsibility to
acknowledge it - or ask for yet another iteration.

Post again if my pointers are not enough to make you understand what the thread
and patch is about. A one sentence summary could look like this:
" They allow both gimpGit and apps like webkit to replace dependenies in the
dependency chain - eg make everything depend on a newer glib. "

> Please do not take lack of reply as an OK.
Reading this one sentence can cause others imagine this - you didn't write it.
But you can cause this feeling:
  - I know about the patch - because I'm talking about it
  - something is wrong with it - Because I don't give an OK

Please note that you didn't say it. But it could be read that way.

============================================================================

What do I want from people on the list:

  - I want them to review (important) patches and yell - or be silent and accept
    them

    If they yell - I highly appreciate them giving pointers about alternatives
    (That's what Eelco Dolstra did - thanks again!) I usually put much
    effort into implementing the alternative then.

  - If they yell / bark (whatsoever) I want them to follow all iterations of a
    commits and finally acknowledge them / or reject them - but if they do so they
    should should write some lines which clearly show that they understood the
    ideas behind a patch. That's what you didn't do asking for reverts
    in 2-3 cases.

    Then I gladly accept the decision.


  Examples of feedback:

    Feedback like this should result in improving the patch;
      "I'm still unhappy because .. "
      "Have you thought about solving your problem this way: ..."

    This feedback can result in a commit:
      "I support the change" [2]
      "I'm happy now" or
      "I'm still unhappy but not unhappy enough to stop this effort"

    This should result in keeping a private branch:
      "I see your benefits (a).. b)..). I still dislike it because its causing more
      damage than value [ .. short list of damage should be listed here .. ] "

  Then its up to the committed to find a different proposal.



============================================================================

Let me apply the rules above and apply them to the discussion NUM_CORES - because
it had an impact on me. The impact was:
  - thinking about forking
  - loosing time
  - feeling bad and depressed


I pushed patch series to stdenv-updates.

- Eelco felt unhappy about the naming. I asked how to improve it -> no reply

- You asked for a revert because you didn't like runMake.
  While doing so you din't talk about the overall idea.
  That one commit was only preparing the following commits which were important
  to me. So I expected you to talk about the overall patch series.

- others on the list said they dislike "opt-out" (which was what I cared
  about).

  I tried to find out what are the reasons - and whether I can do something
  against it. One of the efforts can be seen here:
  http://thread.gmane.org/gmane.linux.distributions.nixos/4367

  Here taking repsonsibility should have taken place. I would have like seeing
  people reply to it.

- Lluís Batlle said that after discussing the topic with you he'd vote for a
  revert as well. Later on irc he told me that he didn't feel strongly about
  it. 
  http://thread.gmane.org/gmane.linux.distributions.nixos.scm/130/focus=4338


Let me summarize how I saw impacts (and how I still see them)

opt-in per package (which you have to enable)

imapacts on me:
- I save many hours
- I'm happy

impacts on others:
- they can enable it if they want.
- I took down hydra (sorry again)
- setup.sh got more complicated
  (in your eyes. In my eyes I simplified the code)
- all hashes change once (which is why I wanted to get it in - if I keep a
  private branch this means no hydra binaries => major impact on me)


What is the result of the story?
- I feel unhappy ( I now feel that I should never have reverted the patch )
- we have three versions:
  - branch by Viric
  - my reverted changes
  - The implementation made by Peter - who clearly illustrated that he missed
    part of the discussion - he still fixed the first flaws by following
    commits
    Still there is one: it doesn't echo -j -l parameters to the log which is
    very important if you notice that builds are broken later.
    (The criticized cmd command would have prevented this once and forever)

Do we have consensus? I don't think so. That's why I'm going to enhance
Peters patch and send a patch series soon.
Ludo, you asked for a revert. Your messages caused the illusion in my mind
that this is collaborative. But it doesn't solve the problem. It surpresses it
(It did so in that case). So the result is (IMHO): We have 3 (maybe somewhat broken)
implementations.

But I'm going to implement a solution based on what Peter did - which
could possibly satisfy everyone. However I want feedback then which
implies replying to questions like "Is there a chance to minimize the
impact of broken builds - eg by detecting them making a build fail?"

============================================================================

I also have written a reply to this comment - maybe now is the time to send it.

You:
> Committing is close to forcing.

I agree. You can look at a commit in many different ways:

- shows interest in a project
- shows interest to improve a situation
- is very natural in software development
- for nixpkgs I think this applies as well:
  * is the easiest way to get feedback (sad but true)
    (git would change this ?)
  * is a way to minimize your own work - because you don't
    have to keep many local branches and keep them up to date.


============================================================================

Let me also explain what I mean by saying "taking responsibility":
Of course I can't force anyone to behave the way I like. I write this
because I think that this results in a healthy productive community.

Of course everything I wrote in this mail is my point of view only.

Maybe this all just means that I'm kind of ignorant - help me to change
then, please. If I criticize the behaviour of others you may criticize mine as
well. I hope that we all can be more successful and happier in the future this
way.
Suppressing features is no the way to go - if someone thinks that way I
have two choices: fork - or ignore. Forking could result in splitting
communities. I don't want this. That's why I'm asking for an official
git mirror.
I hope that I talked clearly about my interests

Yours
Marc Weber