From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>, linux-ide@vger.kernel.org
Subject: Re: [PATCH 1/2] libata: add CFA specific identify data words
Date: Mon, 13 Apr 2009 23:32:10 +0200 [thread overview]
Message-ID: <200904132332.10246.bzolnier@gmail.com> (raw)
In-Reply-To: <49E3A061.7070400@pobox.com>
On Monday 13 April 2009 22:28:17 Jeff Garzik wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > As I see it, there was absolutely no need to rush things -- I simply didn't
> > get to processing newer submissions yet and I would just push Sergei's patch
> > in the next IDE pull request (which happened on March 13th).
>
> That is an IDE-centric perspective. It was a cross-tree depedency, and
> _I_ should not need to wait for you, particularly when you are
> constantly complaining about lacking time for IDE maintenance.
The patch had _zero_ IDE specific changes, you didn't have to wait for me.
You could have simply pushed the whole Sergei's patch yourself and indeed
this will make things more efficient for everybody.
> > Simple reminder/query about the patch status would be more than enough but
> > instead you wasted time for everybody by splitting libata part from Sergei's
> > patch (without updating patch summary+description which I had to fix) and
> > later forgotting about it. Moreover instead of simply pushing forgotten
> > part yourself you requested Sergei to resubmit it and at the same time you
> > tried to put the blame about the whole situation on me.
>
> The onus is always on the submittor to monitor their patches, resubmit,
> etc. It is simply not scalable to constantly ping submittors, keep
> track of their individual development schedules, etc.
In the end it is your responsibility as the Maintainer to get their patches
merged (== keep the project flourishing). Plus keeping in touch with people
submitting you patches and knowing (more-or-less) their individual schedules
is a key into properly planning merges or large scale changes. Though YMMV
as there is no one perfect way of doing things befitting all people.
Thanks,
Bart
prev parent reply other threads:[~2009-04-13 21:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-03 17:29 [PATCH 1/2] libata: add CFA specific identify data words Sergei Shtylyov
2009-03-04 4:56 ` Jeff Garzik
2009-03-04 7:03 ` Jeff Garzik
2009-04-08 11:46 ` Sergei Shtylyov
2009-04-08 13:24 ` Jeff Garzik
2009-04-13 16:48 ` Sergei Shtylyov
2009-04-13 16:51 ` Jeff Garzik
2009-04-13 16:58 ` Sergei Shtylyov
2009-04-13 17:16 ` Jeff Garzik
2009-04-13 19:42 ` Bartlomiej Zolnierkiewicz
2009-04-13 20:28 ` Jeff Garzik
2009-04-13 21:32 ` Bartlomiej Zolnierkiewicz [this message]
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=200904132332.10246.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=sshtylyov@ru.mvista.com \
/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;
as well as URLs for NNTP newsgroup(s).