On Fri, Nov 30, 2018 at 11:27 AM Jason Ekstrand
wrote:
> On Fri, Nov 30, 2018 at 10:55 AM Michel Dänzer wrote:
>
>> On 2018-11-30 4:57 p.m., Daniel Stone wrote:
>> > On Wed, 28 Nov 2018 at 17:23, Dylan Baker wrote:
>> >
>> >> Personally speaking, I think that better next steps for gitlab
>>
On Fri, Nov 30, 2018 at 10:55 AM Michel Dänzer wrote:
> On 2018-11-30 4:57 p.m., Daniel Stone wrote:
> > On Wed, 28 Nov 2018 at 17:23, Dylan Baker wrote:
> >
> >> Personally speaking, I think that better next steps for gitlab
> integration are:
> >> - migrate from bugzilla to gitlab issues
> >
On 2018-11-30 4:57 p.m., Daniel Stone wrote:
> On Wed, 28 Nov 2018 at 17:23, Dylan Baker wrote:
>
>> Personally speaking, I think that better next steps for gitlab integration
>> are:
>> - migrate from bugzilla to gitlab issues
>
> This is currently held up by a mutual death grip: both AMD and
Hi all,
Thanks for the CC. I'm on a sabbatical until mid-January; I'll be
around but not following the lists/etc as actively as before. Please
feel free to liberally CC me (on this address, not work) or poke me on
IRC if there's something I should see or could contribute to. I'll
have limited time
Eric Engestrom writes:
> On Wednesday, 2018-11-28 13:36:29 -0800, Eric Anholt wrote:
>> Jordan Justen writes:
>>
>> > This documents a mechanism for using GitLab Merge Requests as an
>> > optional, secondary way to get code reviews for patchsets.
>> >
>> > We still require all patches to be
On Thu, Nov 29, 2018 at 11:37 AM Matt Turner wrote:
> On Wed, Nov 28, 2018 at 11:30 AM Jason Ekstrand
> wrote:
> > We have enough stubborn people on the list that MRs are going to
> constantly get pulled back to the list just because someone doesn't want to
> use the web interface.
>
> A couple
On Wed, Nov 28, 2018 at 11:30 AM Jason Ekstrand wrote:
> We have enough stubborn people on the list that MRs are going to constantly
> get pulled back to the list just because someone doesn't want to use the web
> interface.
A couple of people in this thread have now made similar claims, but
On Thu, Nov 29, 2018 at 3:11 AM Erik Faye-Lund
wrote:
> On Tue, 2018-11-27 at 17:13 -0800, Jordan Justen wrote:
> > This documents a mechanism for using GitLab Merge Requests as an
> > optional, secondary way to get code reviews for patchsets.
> >
> > We still require all patches to be emailed.
On Wednesday, 2018-11-28 13:36:29 -0800, Eric Anholt wrote:
> Jordan Justen writes:
>
> > This documents a mechanism for using GitLab Merge Requests as an
> > optional, secondary way to get code reviews for patchsets.
> >
> > We still require all patches to be emailed.
> >
> > Aside from the
On Thursday, 2018-11-29 10:11:22 +0100, Erik Faye-Lund wrote:
> On Tue, 2018-11-27 at 17:13 -0800, Jordan Justen wrote:
> > This documents a mechanism for using GitLab Merge Requests as an
> > optional, secondary way to get code reviews for patchsets.
> >
> > We still require all patches to be
On Tue, 2018-11-27 at 17:13 -0800, Jordan Justen wrote:
> This documents a mechanism for using GitLab Merge Requests as an
> optional, secondary way to get code reviews for patchsets.
>
> We still require all patches to be emailed.
>
> Aside from the potential usage for code review comments, it
Quoting Jason Ekstrand (2018-11-28 11:30:32)
> Yes, but the point is that we (the reviewers) know that we're conflicting.
> That's very different from what I could easily see happening *a lot* were ML
> reviewer A is perfectly happy with some bit of code but MR reviewer B asks for
> it to be
Quoting Jordan Justen (2018-11-28 10:21:13)
> On 2018-11-28 09:22:35, Dylan Baker wrote:
> > Quoting Matt Turner (2018-11-27 19:20:09)
> > > On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen
> > > wrote:
> > > >
> > > > This documents a mechanism for using GitLab Merge Requests as an
> > > >
Jordan Justen writes:
> This documents a mechanism for using GitLab Merge Requests as an
> optional, secondary way to get code reviews for patchsets.
>
> We still require all patches to be emailed.
>
> Aside from the potential usage for code review comments, it might also
> help reviewers to
On Wed, Nov 28, 2018 at 2:16 PM Jordan Justen wrote:
>
> On 2018-11-28 10:14:49, Jason Ekstrand wrote:
> > On Wed, Nov 28, 2018 at 11:35 AM Jordan Justen
> > wrote:
> > > On 2018-11-28 06:59:42, Eric Engestrom wrote:
> > > > On Tuesday, 2018-11-27 19:45:50 -0800, Jordan Justen wrote:
> > > > >
On Wed, Nov 28, 2018 at 1:16 PM Jordan Justen
wrote:
> On 2018-11-28 10:14:49, Jason Ekstrand wrote:
> > On Wed, Nov 28, 2018 at 11:35 AM Jordan Justen <
> jordan.l.jus...@intel.com>
> > wrote:
> > > On 2018-11-28 06:59:42, Eric Engestrom wrote:
> > > > On Tuesday, 2018-11-27 19:45:50 -0800,
On 2018-11-28 10:14:49, Jason Ekstrand wrote:
> On Wed, Nov 28, 2018 at 11:35 AM Jordan Justen
> wrote:
> > On 2018-11-28 06:59:42, Eric Engestrom wrote:
> > > On Tuesday, 2018-11-27 19:45:50 -0800, Jordan Justen wrote:
> > > > On 2018-11-27 19:20:09, Matt Turner wrote:
> > > > >
> > > > >
On 2018-11-28 09:22:35, Dylan Baker wrote:
> Quoting Matt Turner (2018-11-27 19:20:09)
> > On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen
> > wrote:
> > >
> > > This documents a mechanism for using GitLab Merge Requests as an
> > > optional, secondary way to get code reviews for patchsets.
> > >
First off, +1 to experimenting with MRs. I've been working with GitLab MRs
in another context for some time and I think the process actually works out
really pretty well. There are issues, of course, but I don't think there's
any real show-stoppers as long as we have a bit of process around it
On 2018-11-28 06:59:42, Eric Engestrom wrote:
> On Tuesday, 2018-11-27 19:45:50 -0800, Jordan Justen wrote:
> > On 2018-11-27 19:20:09, Matt Turner wrote:
> > >
> > > Discussion point: I think attempting to have simultaneous review in
> > > two places is a recipe for wasted time.
> >
> > That's
Quoting Matt Turner (2018-11-27 19:20:09)
> On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen
> wrote:
> >
> > This documents a mechanism for using GitLab Merge Requests as an
> > optional, secondary way to get code reviews for patchsets.
> >
> > We still require all patches to be emailed.
> >
> >
On Tuesday, 2018-11-27 19:45:50 -0800, Jordan Justen wrote:
> On 2018-11-27 19:20:09, Matt Turner wrote:
> > On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen
> > wrote:
> > >
> > > This documents a mechanism for using GitLab Merge Requests as an
> > > optional, secondary way to get code reviews for
On Tue, Nov 27, 2018 at 7:45 PM Jordan Justen wrote:
>
> On 2018-11-27 19:20:09, Matt Turner wrote:
> > On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen
> > wrote:
> > >
> > > This documents a mechanism for using GitLab Merge Requests as an
> > > optional, secondary way to get code reviews for
On 2018-11-27 19:20:09, Matt Turner wrote:
> On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen
> wrote:
> >
> > This documents a mechanism for using GitLab Merge Requests as an
> > optional, secondary way to get code reviews for patchsets.
> >
> > We still require all patches to be emailed.
> >
> >
On Tue, Nov 27, 2018 at 5:13 PM Jordan Justen wrote:
>
> This documents a mechanism for using GitLab Merge Requests as an
> optional, secondary way to get code reviews for patchsets.
>
> We still require all patches to be emailed.
>
> Aside from the potential usage for code review comments, it
This documents a mechanism for using GitLab Merge Requests as an
optional, secondary way to get code reviews for patchsets.
We still require all patches to be emailed.
Aside from the potential usage for code review comments, it might also
help reviewers to find unmerged patchsets which need
26 matches
Mail list logo
