From: Jani Nikula <jani.nikula@linux.intel.com>
To: Petri Latvala <petri.latvala@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: IGT contributions and reviews
Date: Tue, 18 Oct 2016 19:33:10 +0300 [thread overview]
Message-ID: <87bmyhvcqh.fsf@intel.com> (raw)
In-Reply-To: <20161018151520.5zb4hjuwmidu6yy7@platvala-desk.ger.corp.intel.com>
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.
> 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
next prev parent reply other threads:[~2016-10-18 16:33 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 [this message]
2016-10-19 7:50 ` Daniel Vetter
2016-10-19 11:26 ` Jani Nikula
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=87bmyhvcqh.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=petri.latvala@intel.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