All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <jdurgin@redhat.com>
To: Loic Dachary <loic@dachary.org>,
	Abhishek Varshney <abhishek.varshney@flipkart.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Hammer backport and bypassing procedure
Date: Fri, 28 Aug 2015 13:43:47 -0700	[thread overview]
Message-ID: <55E0C803.8020402@redhat.com> (raw)
In-Reply-To: <55E0B396.2090602@dachary.org>

On 08/28/2015 12:16 PM, Loic Dachary wrote:
> Hi Abhishek,
>
> We've just had an example of a backport merged into hammer although it did not follow the procedure : https://github.com/ceph/ceph/pull/5691
>
> It's a key aspect of backports : we're bound to follow procedure, but developers are allowed to bypass it entirely. It may seem like something leading to chaos and frustration but it turns out to be exactly the opposite. In a nutshell, it would be constant source of frustration for developers to learn and obey the rules documented at http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO because it would not benefit them significantly. It would also be a problem for us, backporters, because developers would not be as interested in backporting and our workload would significantly increase.
>
> When a developer prepares a backport on his / her own, we update the pull request and the issues to obey the procedure so the (s)he does not have to. Sure, it's a little tedious but it's a small price to pay for the benefit of having a backport being dealt with. That's what I did for https://github.com/ceph/ceph/pull/5691 : updaging the corresponding issues, adding cross references to the pull request.
>
> Samuel Just felt confident enough about the backport that it did not need a rados run to verify it does the right thing. Since it's ultimately Sam's responsibility, that's also ok. The only thing we need to keep in mind when analyzing the next rados run is that this backport did not pass yet. We don't have a way to mark commits that bypassed tests just yet, if you have ideas let us know :-)

That was me merging it based on my local testing. I'll keep an eye out
for any fallout in the hammer runs.

Thanks for keeping everything updated Loic!
Josh

  reply	other threads:[~2015-08-28 20:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28 19:16 Hammer backport and bypassing procedure Loic Dachary
2015-08-28 20:43 ` Josh Durgin [this message]
     [not found]   ` <CAP3mxSx3E7_1SgwvEfbYftHsWT5_5U0cANiz4Hn7bm9qjjxkew@mail.gmail.com>
2015-08-29  8:03     ` Loic Dachary

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=55E0C803.8020402@redhat.com \
    --to=jdurgin@redhat.com \
    --cc=abhishek.varshney@flipkart.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=loic@dachary.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.