public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: IGT contributions and reviews
Date: Wed, 19 Oct 2016 14:26:38 +0300	[thread overview]
Message-ID: <877f94mvf5.fsf@intel.com> (raw)
In-Reply-To: <20161019075015.GH20761@phenom.ffwll.local>

On Wed, 19 Oct 2016, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
>> On Tue, 18 Oct 2016, Petri Latvala <petri.latvala@intel.com> wrote:
>> > The current contributing docs for IGT state:
>> >
>> > <<
>> >   There is no formal review requirement and regular contributors with
>> >   commit access can push patches right after submitting them to the
>> >   mailing lists. But invasive changes, new helper libraries and
>> >   contributions from newcomers should go through a proper review to
>> >   ensure overall consistency in the codebase.
>> >>>
>> >
>> >
>> > While not requiring reviews or acks has definitely increased the
>> > speed of development, I feel the time for slowing down a bit has
>> > come.
>> 
>> Agreed. (Though a more rigorous review requirement doesn't necessarily
>> slow things down in the big picture.)
>> 
>> > At the very least I would like to see all commits have a visit to the
>> > mailing list before pushing, as the current docs already ask for. The
>> > "right after" part would be changed to a $period of quarantine, maybe
>> > 24 hours?
>> 
>> Sounds good to me.
>
> We've already had this, and people stopped bothering. What will be
> different this time around? I feel a bit like we do need to be a bit more
> formal here, to really make this stick ...
>
> Also, who's going to be the annoying maintainer who reminds everyone every
> time they break the rules? It'll take some serious effort here to get
> folks off their well-trodded paths onto a new one I think.

What's your concrete proposal?

BR,
Jani.


> -Daniel
>
>> > As for requiring reviews or acks before pushing, how do the developers
>> > at large feel about that? Different rules for different parts of IGT?
>> > (Benchmarks, tools, tests, CI test sets, lib....)
>> 
>> I think there are two big buckets here:
>> 
>> * Tests in BAT and the BAT set list. I think we need r-b/ack on the
>>   mailing list on these changes before pushing. (In the long run, I'd
>>   like to have these go through a CI run with everything else unchanged
>>   too.)
>> 
>> * Everything else. Other tests and tools. I'd be happy with requiring
>>   the patches are sent to the list, and either receiving r-b/ack or 24
>>   hrs during weekdays without negative feedback.
>> 
>> > The goal with this discussion is to reach a suitable tradeoff between
>> > stability from CI point of view and fruitful use of programmer time.
>> 
>> Thanks for starting the discussion.
>> 
>> BR,
>> Jani.
>> 
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-10-19 11:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-18 15:15 IGT contributions and reviews Petri Latvala
2016-10-18 16:33 ` Jani Nikula
2016-10-19  7:50   ` Daniel Vetter
2016-10-19 11:26     ` Jani Nikula [this message]
2016-10-19 13:19       ` Daniel Vetter
2016-10-19 13:06     ` Paulo Zanoni
2016-10-19 13:17       ` Daniel Vetter
2016-10-19 13:18       ` Jani Nikula

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=877f94mvf5.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.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