Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Juan A. Suarez Romero]

On Fri, 2019-01-25 at 13:26 -0800, Eric Anholt wrote:
> Rob Clark  writes:
> 
> > I guess as discovered with
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
> > should wait to turn on merging MRs via web until we have at least some
> > basic build-test CI wired up.. the downside is slower 'maintainer'
> > response (if I am working on some long running branch I tend to
> > postpone pushing changes from others until I am in a good state to
> > rebase, but at least when I merge things via cmdline I do a build test
> > and sanity test on at at least one driver ;-))
> 
> We should be days, not weeks, away from having build-test CI wired up.
> I actually thought Igalia was supposed to be working on it again
> already, but then Eric Engestrom started working on a new variation, so
> I'm not sure what's going on.
> 

Yes, I had the plan to update and create a MR with the GitLab CI proposal that I
had sent to mailing list at the beginning of the month, but for personal issues
I completely forgot about it. I'm really really sorry about it.

I don't know how much late I'm are to propose it. In any case, I've everything
ready to create a MR. But as it would be impolite impolite to do it after Eric
created one, I've left a comment in Eric's MR#146 with the proposal, explaining
it.

If Eric and others are fine, I can create a MR too.

J.A.

> I'm skeptical that we need to do an MR policy change given that
> build-breakage and especially unit-test-breakage has been a recurring
> issue in the absence of CI, even before MRs.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Pekka Paalanen]

On Sat, 12 Jan 2019 12:10:42 +0100
apinheiro  wrote:

> 
> On 11/1/19 18:05, Jason Ekstrand wrote:
> >  5. There's no way with gitlab for Reviewed-by tags to get
> > automatically applied as part of the merging process.  This makes
> > merging a bit more manual than it needs to be but is really no worse
> > than it was before.  
> 
> 
> Well, I would say that it slightly worse. For small series, it is true
> that I manually added the Rb when I got a review. But for big series,
> when it got reviewed, I used patchwork to get back the series, but with
> the Rb in place.

Hi,

I thought I'd share a couple of scripts I tend to use:

$ git append-message origin/master..HEAD

will open an editor and add anything you write to the end of all the
commits in the given range on the current branch. Nice for adding R-b
tags in a batch to the whole branch.


$ git fetch-mr 77
$ git fetch-mr origin 77

both will fetch the MR number 77 from the remote "origin" as a new
local branch "mr-origin-77", and if such named branch already exists,
the old one gets renamed to "mr-origin-77-old". It will abort if the
-old branch already exists as well.

I do much of my patch review in gitk and my editor, so fetching the MR
branch is useful. Since I have the -old branch, I can very easily see
what changed compared to the last time I reviewed it.


HTH,
pq


git-append-message
Description: Binary data


git-fetch-mr
Description: Binary data


pgpmeMh3lXVzL.pgp
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Eric Engestrom]

On Monday, 2019-01-28 14:29:00 -0500, Ilia Mirkin wrote:
> 2. I've seen a bunch of things land where I would have had comments
> beforehand. Once the patch is in, I don't really have an easy way to
> provide feedback. In the past if such a thing would happen, I just
> take the subject of the patch, pop it into the search in gmail, and
> reply to the email. It's unclear what I should do now -- for most
> things thus far, just pinging on IRC has worked out, but there's
> nowhere to either see the discussion that led to the change nor to
> provide post-commit feedback. In most places where I've done "tracked"
> reviews, there's linkage in the commit message to be able to find the
> reviews in the review system.

Others have mentioned how to find the MR for a commit, so I'll just add
that you can reply to an MR after it has been merged, which has been
done in the past when an MR broke something, but you can also go to any
commit page (https://gitlab.freedesktop.org/mesa/mesa/commit/$COMMIT_HASH)
and click on the "Add a comment to this line" speech bubble and write
your comment there (works for non-MR commits as well). This comment will
be sent to anyone who has at least the "new note" notification enabled.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Kenneth Graunke]

On Monday, January 28, 2019 11:29:00 AM PST Ilia Mirkin wrote:
> A few thoughts. Given past experience, I don't really expect these to
> have any serious impact on the direction taken, but I also don't want
> to just sit brooding in silence. Please note that full time/paid
> contributors probably have a different view of things than volunteer
> contributors. There's not a ton of the latter left.
> 
> 1. Emailed patches allow me to quickly and easily keep track of what's
> going on, and provide feedback where necessary. In under 5 seconds, I
> can evaluate whether a patch is of interest to me (usually much faster
> than that), and it ends up in my email which I already look at. Going
> to gitlab to look at this stuff is just not going to happen for me. If
> reviews all move to gitlab, I just won't do reviews, and will know a
> lot less about what's going on across the repository.

Hey Ilia,

Have you tried turning on notifications?

1. Go to https://gitlab.freedesktop.org/mesa
2. Log in (if you haven't already)
3. Click the alarm icon in the center of the page, hit "Custom",
   and check all the boxes for merge requests.

Then you'll start receiving emails from git...@gitlab.freedesktop.org
(under the submitter's name), with X-GitLab-* headers you can filter on,
if you want them filtered into a different email folder like mesa-dev.

This way, I can see all merge requests, and discussion activity, all
in email threads in my inbox.  I don't see every patch, but I do see
every series, and only need to "go to gitlab" if a series passes my
"I should think about reviewing this" threshold.  (And then, there's
a link in the email to take me directly to the thing I want to see.)

One nice improvement over the old approach, IMO, is that it sends an
email when a MR is merged or closed.  So, I can quickly look at the last
email in a thread, and see "oh, this is done" and mark the whole thread
as read.  (In the past, I'd have to look at git to see if any commits
matching the subject landed to know whether patches were still awaiting
review or had landed.)

Ideally I hope to have a maildir filter I can run which detects "this
has been merged / closed" and marks threads as read for me, so I can
more quickly tidy my inbox, but I haven't written that yet.

I agree with you that having to "go to gitlab" and poll every day for
new activity would be pretty prohibitive.  But I've been pretty happy
with the notification mechanism and keeping an eye on things via email.

> 2. I've seen a bunch of things land where I would have had comments
> beforehand. Once the patch is in, I don't really have an easy way to
> provide feedback. In the past if such a thing would happen, I just
> take the subject of the patch, pop it into the search in gmail, and
> reply to the email. It's unclear what I should do now -- for most
> things thus far, just pinging on IRC has worked out, but there's
> nowhere to either see the discussion that led to the change nor to
> provide post-commit feedback. In most places where I've done "tracked"
> reviews, there's linkage in the commit message to be able to find the
> reviews in the review system.

That's fair.  In the past, I've seen some of the VMware folks reply to
emails on the mesa-commits list, CC'ing mesa-dev.  That's not a bad
plan still, though it requires subscribing to another firehose list.

I think just emailing mesa-dev and CC'ing the author is reasonable.
We can and should still have email discussions.

>From reading Caio's email here...
https://lists.freedesktop.org/archives/mesa-dev/2019-January/214014.html
...it sounds we've basically got a git script we can use to get from a
commit back to the MR discussion page, in case you want to see any
review that happened.

> 3. Given the present state, where not everyone looks at gitlab,
> patches going through it are getting less review than they would on
> the ML. If entire subsystems agree to exclusively go through gitlab --
> fine. However at this point, core mesa, st/mesa, and gallium patches
> are sneaking through without being seen pre-commit by the people who
> normally review such things.

Yeah...that's not good.  I'm hopeful this is a temporary problem...

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Mon, 2019-01-28 at 17:20 -0500, Rob Clark wrote:
> On Mon, Jan 28, 2019 at 2:29 PM Ilia Mirkin 
> wrote:
> > 2. I've seen a bunch of things land where I would have had comments
> > beforehand. Once the patch is in, I don't really have an easy way
> > to
> > provide feedback. In the past if such a thing would happen, I just
> > take the subject of the patch, pop it into the search in gmail, and
> > reply to the email. It's unclear what I should do now -- for most
> > things thus far, just pinging on IRC has worked out, but there's
> > nowhere to either see the discussion that led to the change nor to
> > provide post-commit feedback. In most places where I've done
> > "tracked"
> > reviews, there's linkage in the commit message to be able to find
> > the
> > reviews in the review system.
> 
> it would be nice to see gitlab injecting some tags (not just r-b, but
> also a link back to the MR) into the git commit msg
> 

They kinda do, just not in the commit message:

https://gitlab.freedesktop.org/mesa/mesa/commit/3cb65cf8aa090c39b520ae26fa32097ad18fd067

Notice there's a "1 merge request !75"-link in there. That takes you
back to the MR. This should be present for all commits in a merge
request.

If you want to access this information from the command-line, you can
setup a fetch-spec for the merge-requests, like so:

git config --add remote.origin.fetch +refs/merge-
requests/*/head:refs/remotes/origin/merge-requests/*

Make sure you've fetched the remote first, and do this:

$ git describe --all --contains 3cb65cf
remotes/origin/merge-requests/75


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

On Mon, Jan 28, 2019 at 2:29 PM Ilia Mirkin  wrote:
>
> A few thoughts. Given past experience, I don't really expect these to
> have any serious impact on the direction taken, but I also don't want
> to just sit brooding in silence. Please note that full time/paid
> contributors probably have a different view of things than volunteer
> contributors. There's not a ton of the latter left.

There is a desire to make it easier for drive-by contributors (which
are generally taken to mean volunteer contributors but that shouldn't
mean to make it harder for long term volunteer contributors).  Ideally
it is not an either/or but something that could be fixed in the tools.
(At least that is my rough opinion.. I haven't contributed any patches
to gitlab itself and probably wouldn't know where to start.)

>
> 1. Emailed patches allow me to quickly and easily keep track of what's
> going on, and provide feedback where necessary. In under 5 seconds, I
> can evaluate whether a patch is of interest to me (usually much faster
> than that), and it ends up in my email which I already look at. Going
> to gitlab to look at this stuff is just not going to happen for me. If
> reviews all move to gitlab, I just won't do reviews, and will know a
> lot less about what's going on across the repository.

this seems like a solvable problem

> 2. I've seen a bunch of things land where I would have had comments
> beforehand. Once the patch is in, I don't really have an easy way to
> provide feedback. In the past if such a thing would happen, I just
> take the subject of the patch, pop it into the search in gmail, and
> reply to the email. It's unclear what I should do now -- for most
> things thus far, just pinging on IRC has worked out, but there's
> nowhere to either see the discussion that led to the change nor to
> provide post-commit feedback. In most places where I've done "tracked"
> reviews, there's linkage in the commit message to be able to find the
> reviews in the review system.

it would be nice to see gitlab injecting some tags (not just r-b, but
also a link back to the MR) into the git commit msg

> 3. Given the present state, where not everyone looks at gitlab,
> patches going through it are getting less review than they would on
> the ML. If entire subsystems agree to exclusively go through gitlab --
> fine. However at this point, core mesa, st/mesa, and gallium patches
> are sneaking through without being seen pre-commit by the people who
> normally review such things.

I think some way to automagically apply path based labels to gitlab
MRs would solve at least some of this..  I was told that it should be
possible to do something like this on top of the gitlab API but
haven't had time to translate sugestion into patch.

Or maybe more useful would be a way to subscribe to path based
notifications without requiring a label..

It would be at least nice to get cover-letters CC'd to list so at
least mesa-dev has a sort of executive summary of what is going on.

BR,
-R


>
> Cheers,
>
>   -ilia
>
> On Fri, Jan 11, 2019 at 11:57 AM Jason Ekstrand  wrote:
> >
> > All,
> >
> > The mesa project has now hit 100 merge requests (36 are still open).  I 
> > (and I'm sure others) would be curious to hear people's initial thoughts on 
> > the process.  What's working well?  What's not working?  Is it total fail 
> > and should we go back to mailing lists?
> >
> > --Jason
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Ilia Mirkin]

A few thoughts. Given past experience, I don't really expect these to
have any serious impact on the direction taken, but I also don't want
to just sit brooding in silence. Please note that full time/paid
contributors probably have a different view of things than volunteer
contributors. There's not a ton of the latter left.

1. Emailed patches allow me to quickly and easily keep track of what's
going on, and provide feedback where necessary. In under 5 seconds, I
can evaluate whether a patch is of interest to me (usually much faster
than that), and it ends up in my email which I already look at. Going
to gitlab to look at this stuff is just not going to happen for me. If
reviews all move to gitlab, I just won't do reviews, and will know a
lot less about what's going on across the repository.

2. I've seen a bunch of things land where I would have had comments
beforehand. Once the patch is in, I don't really have an easy way to
provide feedback. In the past if such a thing would happen, I just
take the subject of the patch, pop it into the search in gmail, and
reply to the email. It's unclear what I should do now -- for most
things thus far, just pinging on IRC has worked out, but there's
nowhere to either see the discussion that led to the change nor to
provide post-commit feedback. In most places where I've done "tracked"
reviews, there's linkage in the commit message to be able to find the
reviews in the review system.

3. Given the present state, where not everyone looks at gitlab,
patches going through it are getting less review than they would on
the ML. If entire subsystems agree to exclusively go through gitlab --
fine. However at this point, core mesa, st/mesa, and gallium patches
are sneaking through without being seen pre-commit by the people who
normally review such things.

Cheers,

  -ilia

On Fri, Jan 11, 2019 at 11:57 AM Jason Ekstrand  wrote:
>
> All,
>
> The mesa project has now hit 100 merge requests (36 are still open).  I (and 
> I'm sure others) would be curious to hear people's initial thoughts on the 
> process.  What's working well?  What's not working?  Is it total fail and 
> should we go back to mailing lists?
>
> --Jason
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

On Sun, Jan 27, 2019 at 1:33 PM Daniel Stone  wrote:
>
> Hi,
>
> On Fri, 25 Jan 2019 at 23:24, Rob Clark  wrote:
> > (Hmm, I guess I should take a look at what sort of API gitlab offers,
> > but that will probably have to wait until after the branchpoint.. tbh
> > I'd actually be pretty happy w/ a gitlab equiv of 'git pw as -s' for
> > merging things from cmdline.)
>
> Add this to your Git remote specification:
> fetch = +refs/merge-requests/*:refs/heads/mr/*
>
> And then the actual branch submitted for an MR will be present as mr/100/head.
>

oh, nice.. I didn't manage to quite get that to work as is, but ended up with:

[remote "origin"]
url = https://gitlab.freedesktop.org/mesa/mesa.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

(based on an example from
https://docs.gitlab.com/ee/user/project/merge_requests/ )

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Fri, 25 Jan 2019 at 23:24, Rob Clark  wrote:
> (Hmm, I guess I should take a look at what sort of API gitlab offers,
> but that will probably have to wait until after the branchpoint.. tbh
> I'd actually be pretty happy w/ a gitlab equiv of 'git pw as -s' for
> merging things from cmdline.)

Add this to your Git remote specification:
fetch = +refs/merge-requests/*:refs/heads/mr/*

And then the actual branch submitted for an MR will be present as mr/100/head.

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

On Fri, Jan 25, 2019 at 4:26 PM Eric Anholt  wrote:
>
> Rob Clark  writes:
>
> > I guess as discovered with
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
> > should wait to turn on merging MRs via web until we have at least some
> > basic build-test CI wired up.. the downside is slower 'maintainer'
> > response (if I am working on some long running branch I tend to
> > postpone pushing changes from others until I am in a good state to
> > rebase, but at least when I merge things via cmdline I do a build test
> > and sanity test on at at least one driver ;-))
>
> We should be days, not weeks, away from having build-test CI wired up.
> I actually thought Igalia was supposed to be working on it again
> already, but then Eric Engestrom started working on a new variation, so
> I'm not sure what's going on.
>
> I'm skeptical that we need to do an MR policy change given that
> build-breakage and especially unit-test-breakage has been a recurring
> issue in the absence of CI, even before MRs.

Ok, that is good news that it is close, I think if it is just a matter
of days (or even a week or two), we shouldn't change the process.  If
it would be more of a longer term thing I'd worry about breaking the
build too frequently compared to the less convenient cmdline process..

(Hmm, I guess I should take a look at what sort of API gitlab offers,
but that will probably have to wait until after the branchpoint.. tbh
I'd actually be pretty happy w/ a gitlab equiv of 'git pw as -s' for
merging things from cmdline.)

BR,
-R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Eric Anholt]

Rob Clark  writes:

> I guess as discovered with
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
> should wait to turn on merging MRs via web until we have at least some
> basic build-test CI wired up.. the downside is slower 'maintainer'
> response (if I am working on some long running branch I tend to
> postpone pushing changes from others until I am in a good state to
> rebase, but at least when I merge things via cmdline I do a build test
> and sanity test on at at least one driver ;-))

We should be days, not weeks, away from having build-test CI wired up.
I actually thought Igalia was supposed to be working on it again
already, but then Eric Engestrom started working on a new variation, so
I'm not sure what's going on.

I'm skeptical that we need to do an MR policy change given that
build-breakage and especially unit-test-breakage has been a recurring
issue in the absence of CI, even before MRs.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Wed, 2019-01-23 at 14:47 +, Eric Engestrom wrote:
> On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote:
> > It could have been made obvious for instance by showing the commit-
> > graph next to the commit-list, decorating it with the branch head
> > in
> > one end and clear continuation in the other.
> 
> I'd love that, it would really help a lot!
> 
> Care to raise an issue at gitlab asking for this? :)
> https://gitlab.com/gitlab-org/gitlab-ce/issues/new
> 

Done:
https://gitlab.com/gitlab-org/gitlab-ce/issues/56799

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

I guess as discovered with
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
should wait to turn on merging MRs via web until we have at least some
basic build-test CI wired up.. the downside is slower 'maintainer'
response (if I am working on some long running branch I tend to
postpone pushing changes from others until I am in a good state to
rebase, but at least when I merge things via cmdline I do a build test
and sanity test on at at least one driver ;-))

BR,
-R

On Fri, Jan 11, 2019 at 11:57 AM Jason Ekstrand  wrote:
>
> All,
>
> The mesa project has now hit 100 merge requests (36 are still open).  I (and 
> I'm sure others) would be curious to hear people's initial thoughts on the 
> process.  What's working well?  What's not working?  Is it total fail and 
> should we go back to mailing lists?
>
> --Jason
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Caio Marcelo de Oliveira Filho]

On Wed, Jan 23, 2019 at 11:01:46AM +, Eric Engestrom wrote:
> On Friday, 2019-01-11 09:50:25 -0800, Caio Marcelo de Oliveira Filho wrote:
> [snip]
> > - To find the discussion associated with a commit in master, I'd
> >   search the title in the mailing list archives.  With MRs, the usual
> >   way that this connection is made would be the reference to the MR as
> >   part of the merge commit message, but in Mesa we don't currently use
> >   merge commits.  I've tried to search for commit titles in MR
> >   interface but it doesn't find them.
> 
> If you go on the gitlab page for a commit that comes from an MR, eg.
> https://gitlab.freedesktop.org/mesa/mesa/commit/41a0c0039225753b26f2ce61b49fef8d45c616ad
> 
> In the gray box between the commit message and the diff, you can see
> a "merge" logo followed by:
> >  1 merge request !135 travis: fix autotools builds after --enable-autotools 
> > switch addition

Thanks, Daniel Stone pointed that out earlier in the thread.  I'm also
using the "web API" to script this interaction.

commit=$(git rev-parse $1)
curl -s 
https://gitlab.freedesktop.org/api/v4/projects/mesa%2fmesa/repository/commits/${commit}/merge_requests
 | jq -r '.[0].title, .[0].web_url'


Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Eric Engestrom]

On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote:
> It could have been made obvious for instance by showing the commit-
> graph next to the commit-list, decorating it with the branch head in
> one end and clear continuation in the other.

I'd love that, it would really help a lot!

Care to raise an issue at gitlab asking for this? :)
https://gitlab.com/gitlab-org/gitlab-ce/issues/new
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Eric Engestrom]

On Friday, 2019-01-11 09:50:25 -0800, Caio Marcelo de Oliveira Filho wrote:
[snip]
> - To find the discussion associated with a commit in master, I'd
>   search the title in the mailing list archives.  With MRs, the usual
>   way that this connection is made would be the reference to the MR as
>   part of the merge commit message, but in Mesa we don't currently use
>   merge commits.  I've tried to search for commit titles in MR
>   interface but it doesn't find them.

If you go on the gitlab page for a commit that comes from an MR, eg.
https://gitlab.freedesktop.org/mesa/mesa/commit/41a0c0039225753b26f2ce61b49fef8d45c616ad

In the gray box between the commit message and the diff, you can see
a "merge" logo followed by:
>  1 merge request !135 travis: fix autotools builds after --enable-autotools 
> switch addition
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Thu, 2019-01-17 at 08:38 +0100, Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> > 
> > The mesa project has now hit 100 merge requests (36 are still
> > open). 
> > I (and I'm sure others) would be curious to hear people's initial
> > thoughts on the process.  What's working well?  What's not
> > working? 
> > Is it total fail and should we go back to mailing lists?
> > 
> 
> So, overall I think it works pretty well. I have some things I think
> maybe we could do better, some of which has already been pointed out:
> 
> 1. New MRs should probably get their cover-letter automatically sent
> to
> the mailing list for incrased visibility.

OK, I think that after having enabled e-mail notifications and spent
some time setting up mail filters, this is much less of a pressing
issue for me personally. I'm not even sure I think this is worth the
time any more, as the notification support in GitLab is *really* good,
and allows nice and finely-grained control, much better than what an
automatic mail-bot could do.

This doesn't mean that I would opose it, though. Just that I think I
would strike this from *my* personal list of things to improve.

> 2. Perhaps we should ban sending MRs from the main mesa repo? With
> gitlab, it's trivial to make your own fork, and you can delegate
> permissions to other users for collaborators. I don't think there's
> any
> reason to clutter up the main mesa repo with all kinds of branches.
> But
> it seems some people send their MRs from the main-repo anyway.
> Perhaps
> we should document that this isn't how to send MRs?

I've sent out a patch to add a note about this.

> 3. There's some browsing-pain with the commit list. For instance, I
> always second-guess if the latest commit is at the top or bottom.
> Some
> times this is not a problem due to timestamps, but sometimes this
> isn't
> clear from that either. I also tend to get a bit lost in context.
> Some
> of this is probably habit, though.
> 

And I don't really think this is a big deal, especially after the
discussion on this point below; GitHub is the oddball here, and that's
not GitLab's fault.

So all in all, I think all of my issues with the process has been
resolved (assuming we land the patch with the MR-note in some form, and
if we don't that's probably also for a good reason).

So from my point of view, I would love to see us move to a MR-only
workflow as soon as possible. Doing both is a little bit messy (as was
anticipated).

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Jason Ekstrand]

On Thu, Jan 17, 2019 at 1:07 PM Daniel Stone  wrote:

> Hi,
>
> On Thu, 17 Jan 2019 at 16:35, Jason Ekstrand  wrote:
> > On January 17, 2019 08:58:03 Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > > Whoops! I meant to say something like "we'd need to be able to
> > > distinguis between CI steps that are triggered due to new MRs versus
> > > updated MRs, or pushes to existing branches".
> > >
> > >> Anyway, Jason did actually write that hook, and it's something I'm
> > >> happy to host on existing fd.o machines. I just haven't got to doing
> > >> it, since I ended up taking my sabbatical a lot more seriously than I
> > >> expected, and now I'm back to work I've got a bit of a backlog. But
> > >> we
> > >> can definitely do it, and pretty soon.
> > >
> > > Cool, then I won't worry about it, and just assume it'll appear
> > > magically soon :)
> >
> > My script was a total hack. It's probably massively insecure and doesn't
> > include any code to provide a diffstat which has been requested by
> several
> > people. Someone taking it a bit more seriously would probably be good
> > before we deploy anything.
>
> With the caveat that I can no longer see the script because it's been
> expired out of the pastebin (why not make a GitLab repo or at least
> upload it to a snippet?) ...
>

https://gitlab.freedesktop.org/jekstrand/gitlab-mailbot


> I had the same assumption when you posted it, but came to the
> conclusion it was actually OK, or at least would be with very minimal
> work. We can configure Apache and GitLab pretty easily so it can only
> be triggered with a secret token which is buried in the repo config
> and/or accessible only to admins. It calls back into GitLab to get the
> changes, so there's no danger of it sending completely arbitrary
> content even if someone does figure out how to trigger it when they
> shouldn't. It also has GitLab project -> email destination hardcoded
> in the script, so there's no danger of it being used to spam arbitrary
> addresses either.
>

That makes me feel a tiny bit better.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Juan A. Suarez Romero]

On Tue, 2019-01-15 at 07:21 -0500, Rob Clark wrote:
> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli  wrote:
> > 
> > 
> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> > > Hi,
> > > 
> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
> > > >   5. There's no way with gitlab for Reviewed-by tags to get 
> > > > automatically applied as part of the merging process.  This makes 
> > > > merging a bit more manual than it needs to be but is really no worse 
> > > > than it was before.
> > > 
> > > I'm still on the side of not seeing the value in them. Most of the
> > > time when I go to pursue someone who reviewed a commit, I'll go to see
> > > what came up in review anyway. Maybe someone had the same comment
> > > which was found to be not applicable or otherwise explained away.
> > > Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
> > > text descriptors in a comment can much better capture the intent (e.g.
> > > 'I'm strongly OK with the driver changes and weakly OK with the core
> > > changes as it's not really my area of expertise').
> > > 
> > > In other projects, we looked for ways to apply the tags and ended up
> > > concluding that they didn't bring enough value to make it worthwhile.
> > > I don't know if that holds for Mesa, but it would be better to start
> > > with an actual problem statement - what value does R-b bring and how?
> > > - then look at ways to solve that problem, rather than just very
> > > directly finding a way to insert that literal text string into every
> > > commit message.
> > 
> > IMO it brings some 'shared responsibility' for correctness of the patch
> > and quickly accessible information on who were looking at the change. So
> > ideally later when filing bug against commit/series there would be more
> > people than just the committer that should take a look at the possible
> > regressions. At least in my experience people filing bugs tend to often
> > also CC the reviewer.
> 
> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
> without having to go search somewhere else (ie. outside of git/tig)
> 

Maybe something like this could be useful:

https://github.com/smarkets/marge-bot


> (ofc it would be pretty awesome incentive to switch to gitlab issues
> if gitlab could automate adding Reported-by tags for MR's associated
> with an issue.. but I guess checkbox to add Reviewed-by tag would
> already make my day)
> 
> BR,
> -R
> 
> > > FWIW, if you go to
> > > https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
> > > hyperlink from the web UI which points you to the MR. The API to do
> > > this is pretty straightforward and amenable to piping through jq:
> > > https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit
> > 
> > I guess if we would move issue tracking to gitlab then we could possibly
> > automate the CC list generation based on commit?
> > 
> > // Tapani
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Thu, 17 Jan 2019 at 16:35, Jason Ekstrand  wrote:
> On January 17, 2019 08:58:03 Erik Faye-Lund  
> wrote:
> > Whoops! I meant to say something like "we'd need to be able to
> > distinguis between CI steps that are triggered due to new MRs versus
> > updated MRs, or pushes to existing branches".
> >
> >> Anyway, Jason did actually write that hook, and it's something I'm
> >> happy to host on existing fd.o machines. I just haven't got to doing
> >> it, since I ended up taking my sabbatical a lot more seriously than I
> >> expected, and now I'm back to work I've got a bit of a backlog. But
> >> we
> >> can definitely do it, and pretty soon.
> >
> > Cool, then I won't worry about it, and just assume it'll appear
> > magically soon :)
>
> My script was a total hack. It's probably massively insecure and doesn't
> include any code to provide a diffstat which has been requested by several
> people. Someone taking it a bit more seriously would probably be good
> before we deploy anything.

With the caveat that I can no longer see the script because it's been
expired out of the pastebin (why not make a GitLab repo or at least
upload it to a snippet?) ...

I had the same assumption when you posted it, but came to the
conclusion it was actually OK, or at least would be with very minimal
work. We can configure Apache and GitLab pretty easily so it can only
be triggered with a secret token which is buried in the repo config
and/or accessible only to admins. It calls back into GitLab to get the
changes, so there's no danger of it sending completely arbitrary
content even if someone does figure out how to trigger it when they
shouldn't. It also has GitLab project -> email destination hardcoded
in the script, so there's no danger of it being used to spam arbitrary
addresses either.

Even without that, given that people currently only need to sign up to
Bugzilla (without a captcha) in order to send email with arbitrary
content to mesa-dev@, 'less spam-prone than the status quo' is an
embarrassingly low bar anyway.

Whoever wants to see this happen should ping Jason to get the script
and his suggested changes, get it in a GitLab repo, then file an issue
on https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new/
and I'll get it deployed.

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Jason Ekstrand]

On January 17, 2019 08:58:03 Erik Faye-Lund  
wrote:



On Thu, 2019-01-17 at 14:37 +, Daniel Stone wrote:

Hi,

On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
 wrote:

1. New MRs should probably get their cover-letter automatically
sent to
the mailing list for incrased visibility.

[...]

I don't think any of these issues are show-stoppers from moving
entirely to MRs, though. Perhaps issue #1 here should be fixed
first,
dunno...

Issue #1 is of course "just" a matter of writing some script that
gets
triggered by a hook. It's just work that needs to be done; any of
us
that complain about it could take up the work, I suppose.

The only question is where to host such a service... perhaps it's
just
a gitlab CI step? That way we'd get some "automatic" cloud
computing
power to do the work, but it doesn't really seem like a perfect
fit;
we'd need to be able to distinguis between CI steps that are
triggered
due to new


Unfinished sentence?


Whoops! I meant to say something like "we'd need to be able to
distinguis between CI steps that are triggered due to new MRs versus
updated MRs, or pushes to existing branches".


Anyway, Jason did actually write that hook, and it's something I'm
happy to host on existing fd.o machines. I just haven't got to doing
it, since I ended up taking my sabbatical a lot more seriously than I
expected, and now I'm back to work I've got a bit of a backlog. But
we
can definitely do it, and pretty soon.


Cool, then I won't worry about it, and just assume it'll appear
magically soon :)


My script was a total hack. It's probably massively insecure and doesn't 
include any code to provide a diffstat which has been requested by several 
people. Someone taking it a bit more seriously would probably be good 
before we deploy anything.


--Jason



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Thu, 2019-01-17 at 14:37 +, Daniel Stone wrote:
> Hi,
> 
> On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
>  wrote:
> > 1. New MRs should probably get their cover-letter automatically
> > sent to
> > the mailing list for incrased visibility.
> > 
> > [...]
> > 
> > I don't think any of these issues are show-stoppers from moving
> > entirely to MRs, though. Perhaps issue #1 here should be fixed
> > first,
> > dunno...
> > 
> > Issue #1 is of course "just" a matter of writing some script that
> > gets
> > triggered by a hook. It's just work that needs to be done; any of
> > us
> > that complain about it could take up the work, I suppose.
> > 
> > The only question is where to host such a service... perhaps it's
> > just
> > a gitlab CI step? That way we'd get some "automatic" cloud
> > computing
> > power to do the work, but it doesn't really seem like a perfect
> > fit;
> > we'd need to be able to distinguis between CI steps that are
> > triggered
> > due to new
> 
> Unfinished sentence?

Whoops! I meant to say something like "we'd need to be able to
distinguis between CI steps that are triggered due to new MRs versus
updated MRs, or pushes to existing branches".

> Anyway, Jason did actually write that hook, and it's something I'm
> happy to host on existing fd.o machines. I just haven't got to doing
> it, since I ended up taking my sabbatical a lot more seriously than I
> expected, and now I'm back to work I've got a bit of a backlog. But
> we
> can definitely do it, and pretty soon.
> 

Cool, then I won't worry about it, and just assume it'll appear
magically soon :)

Thanks!

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Thu, 2019-01-17 at 10:00 +0100, Michel Dänzer wrote:
> On 2019-01-17 8:38 a.m., Erik Faye-Lund wrote:
> > 3. There's some browsing-pain with the commit list. For instance, I
> > always second-guess if the latest commit is at the top or bottom.
> 
> At the top, same as in all Git related tools I've seen.
> 

One would think all tools would have the sense to do this, but sadly
this isn't the case. One major player decided to do this differently;
GitHub. Since I use both Github and Gitlab, this difference keeps
confusing me.

It could have been made obvious for instance by showing the commit-
graph next to the commit-list, decorating it with the branch head in
one end and clear continuation in the other.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
 wrote:
> 1. New MRs should probably get their cover-letter automatically sent to
> the mailing list for incrased visibility.
>
> [...]
>
> I don't think any of these issues are show-stoppers from moving
> entirely to MRs, though. Perhaps issue #1 here should be fixed first,
> dunno...
>
> Issue #1 is of course "just" a matter of writing some script that gets
> triggered by a hook. It's just work that needs to be done; any of us
> that complain about it could take up the work, I suppose.
>
> The only question is where to host such a service... perhaps it's just
> a gitlab CI step? That way we'd get some "automatic" cloud computing
> power to do the work, but it doesn't really seem like a perfect fit;
> we'd need to be able to distinguis between CI steps that are triggered
> due to new

Unfinished sentence?

Anyway, Jason did actually write that hook, and it's something I'm
happy to host on existing fd.o machines. I just haven't got to doing
it, since I ended up taking my sabbatical a lot more seriously than I
expected, and now I'm back to work I've got a bit of a backlog. But we
can definitely do it, and pretty soon.

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Tapani Pälli]

On 1/17/19 12:32 PM, apinheiro wrote:


On 17/1/19 9:39, Kenneth Graunke wrote:

On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:

On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).
I (and I'm sure others) would be curious to hear people's initial
thoughts on the process.  What's working well?  What's not working?
Is it total fail and should we go back to mailing lists?


So, overall I think it works pretty well. I have some things I think
maybe we could do better, some of which has already been pointed out:

1. New MRs should probably get their cover-letter automatically sent to
the mailing list for incrased visibility.

2. Perhaps we should ban sending MRs from the main mesa repo? With
gitlab, it's trivial to make your own fork, and you can delegate
permissions to other users for collaborators. I don't think there's any
reason to clutter up the main mesa repo with all kinds of branches. But
it seems some people send their MRs from the main-repo anyway. Perhaps
we should document that this isn't how to send MRs?

I agree, I would much rather see MRs sent from personal forks.
That's what I've been doing, and it works well.  If you see people
doing that, feel free to say something - I assume they just don't
realize they can do that.



As one of the people doing it wrongly (using a branch of the main repo, 
instead of a personal fork): yes please, let's document that, as I was 
unaware that was a problem.


What Im not sure if it is possible to update a existing MR in order to 
use a different repo/branch. If that is not possible, should I close my 
MR and reopen it with a fork?




I guess it's not a big deal (?) if we just take care of proper cleanup 
(can be done via checkbox while merging). For me this happened by 
accident (with recent ahw-fix branch), I just happen to have remote 
names 'gitlab' and 'gitlab-tpalli' so it got pushed to the wrong one.


// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[apinheiro]

On 17/1/19 9:39, Kenneth Graunke wrote:

On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:

On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).
I (and I'm sure others) would be curious to hear people's initial
thoughts on the process.  What's working well?  What's not working?
Is it total fail and should we go back to mailing lists?


So, overall I think it works pretty well. I have some things I think
maybe we could do better, some of which has already been pointed out:

1. New MRs should probably get their cover-letter automatically sent to
the mailing list for incrased visibility.

2. Perhaps we should ban sending MRs from the main mesa repo? With
gitlab, it's trivial to make your own fork, and you can delegate
permissions to other users for collaborators. I don't think there's any
reason to clutter up the main mesa repo with all kinds of branches. But
it seems some people send their MRs from the main-repo anyway. Perhaps
we should document that this isn't how to send MRs?

I agree, I would much rather see MRs sent from personal forks.
That's what I've been doing, and it works well.  If you see people
doing that, feel free to say something - I assume they just don't
realize they can do that.



As one of the people doing it wrongly (using a branch of the main repo, 
instead of a personal fork): yes please, let's document that, as I was 
unaware that was a problem.


What Im not sure if it is possible to update a existing MR in order to 
use a different repo/branch. If that is not possible, should I close my 
MR and reopen it with a fork?





--Ken

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Michel Dänzer]

On 2019-01-17 8:38 a.m., Erik Faye-Lund wrote:
>
> 3. There's some browsing-pain with the commit list. For instance, I
> always second-guess if the latest commit is at the top or bottom.

At the top, same as in all Git related tools I've seen.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Kenneth Graunke]

On Wednesday, January 16, 2019 11:38:05 PM PST Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> > 
> > The mesa project has now hit 100 merge requests (36 are still open). 
> > I (and I'm sure others) would be curious to hear people's initial
> > thoughts on the process.  What's working well?  What's not working? 
> > Is it total fail and should we go back to mailing lists?
> > 
> 
> So, overall I think it works pretty well. I have some things I think
> maybe we could do better, some of which has already been pointed out:
> 
> 1. New MRs should probably get their cover-letter automatically sent to
> the mailing list for incrased visibility.
> 
> 2. Perhaps we should ban sending MRs from the main mesa repo? With
> gitlab, it's trivial to make your own fork, and you can delegate
> permissions to other users for collaborators. I don't think there's any
> reason to clutter up the main mesa repo with all kinds of branches. But
> it seems some people send their MRs from the main-repo anyway. Perhaps
> we should document that this isn't how to send MRs?

I agree, I would much rather see MRs sent from personal forks.
That's what I've been doing, and it works well.  If you see people
doing that, feel free to say something - I assume they just don't
realize they can do that.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Erik Faye-Lund]

On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> All,
> 
> The mesa project has now hit 100 merge requests (36 are still open). 
> I (and I'm sure others) would be curious to hear people's initial
> thoughts on the process.  What's working well?  What's not working? 
> Is it total fail and should we go back to mailing lists?
> 

So, overall I think it works pretty well. I have some things I think
maybe we could do better, some of which has already been pointed out:

1. New MRs should probably get their cover-letter automatically sent to
the mailing list for incrased visibility.

2. Perhaps we should ban sending MRs from the main mesa repo? With
gitlab, it's trivial to make your own fork, and you can delegate
permissions to other users for collaborators. I don't think there's any
reason to clutter up the main mesa repo with all kinds of branches. But
it seems some people send their MRs from the main-repo anyway. Perhaps
we should document that this isn't how to send MRs?

3. There's some browsing-pain with the commit list. For instance, I
always second-guess if the latest commit is at the top or bottom. Some
times this is not a problem due to timestamps, but sometimes this isn't
clear from that either. I also tend to get a bit lost in context. Some
of this is probably habit, though.

I don't think any of these issues are show-stoppers from moving
entirely to MRs, though. Perhaps issue #1 here should be fixed first,
dunno...

Issue #1 is of course "just" a matter of writing some script that gets
triggered by a hook. It's just work that needs to be done; any of us
that complain about it could take up the work, I suppose.

The only question is where to host such a service... perhaps it's just
a gitlab CI step? That way we'd get some "automatic" cloud computing
power to do the work, but it doesn't really seem like a perfect fit;
we'd need to be able to distinguis between CI steps that are triggered
due to new 

Related to issue #2 here, think there's a lot of "historical" branches
that we can move from the repo, into some sort of "historical-branches" 
fork or something... Would that be worthwile?

It seems easier for end-users if they only find "official" branches
(release-branches, really) in the repo.

Similarly, I also think release-branches can be deleted at some point
after they are EOL, which makes it a bit easier to see what's going on.
At this point they should be pointing to the same commit as the most
recent tag of that minor-version series anyway, so nothing would be
lost...

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Lionel Landwerlin]

On 16/01/2019 14:01, Daniel Stone wrote:

Hi,

On Wed, 16 Jan 2019 at 13:01, Lionel Landwerlin
 wrote:

- It seems we only get notifications when adding to an MR, I could like to 
subscribe to particular tags

If you go to https://gitlab.freedesktop.org/mesa/mesa/labels/ then you
can subscribe to things per-label. That applies to both issues and
MRs, but might help.

Cheers,
Daniel


Duh, I think I was pointed to this at some point...

Awesome, thanks for the reminder!


-

Lionel

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Wed, 16 Jan 2019 at 13:01, Lionel Landwerlin
 wrote:
> - It seems we only get notifications when adding to an MR, I could like to 
> subscribe to particular tags

If you go to https://gitlab.freedesktop.org/mesa/mesa/labels/ then you
can subscribe to things per-label. That applies to both issues and
MRs, but might help.

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

On Tue, Jan 15, 2019 at 5:51 PM Daniel Stone  wrote:
>
> Hey,
>
> On Tue, 15 Jan 2019 at 20:22, Rob Clark  wrote:
> > On Tue, Jan 15, 2019 at 7:40 AM Daniel Stone  wrote:
> > > My question would again be what value that brings you. Do you just
> > > like seeing the name there, or do you go poke the people on IRC, or
> > > follow up via email, or ... ? Again I personally go look through the
> > > original review to see what came up during that first, but everyone's
> > > different, so I'm just trying to understand what you actually do with
> > > that information, so we can figure out if there's a better way to do
> > > things for everyone rather than just blindly imitating what came
> > > before.
> >
> > If I am curious or have some questions about why some code is the way
> > it is I frequently use tig-blame, which makes it easy to step into the
> > commit that made the change and see the commit msg and r-b tags..  I
> > guess the most important part if I need to ping someone on IRC w/
> > questions is the author, but it seems like having the other tags handy
> > without context-switching to browser/gitlab is useful.
> >
> > I guess I don't as frequently dig into the history of the original
> > patchset and it's review comments.. mostly because that isn't as easy
> > with the email based review process.  Making this easier would defn be
> > a win.  But in cases where I don't have to leave the comfort of tig,
> > it would be nice not to have to start doing so..
> >
> > This is not an argument for sticking to email based process, just
> > defence of what I think would be a useful feature for gitlab to gain
> > ;-)
>
> Thanks, that helps. How about this? It technically even fits in one
> line, though you might wish it didn't.
>
> ~/mesa/mesa master ← → * % export
> GITLAB_TOKEN=secret-api-token-you-get-from-web-UI
> ~/mesa/mesa master ← → * % export
> GITLAB_COMMIT=f967273fb442de8281f8248e8c8bff5b13ab89e4
> ~/mesa/mesa master ← → * % curl --silent --header "PRIVATE-TOKEN:
> $GITLAB_TOKEN" 
> https://gitlab.freedesktop.org/api/v4/projects/mesa%2Fmesa/merge_requests/$(curl
> --silent --header "PRIVATE-TOKEN: $GITLAB_TOKEN"
> https://gitlab.freedesktop.org/api/v4/projects/mesa%2Fmesa/repository/commits/${GITLAB_COMMIT}/merge_requests
> | jq -r '.[] | .iid')/participants | jq -r '.[] | { username:
> .username, realname: .name }'
> {
>   "username": "sroland",
>   "realname": "Roland Scheidegger"
> }
> {
>   "username": "kwg",
>   "realname": "Kenneth Graunke"
> }
> {
>   "username": "mareko",
>   "realname": "Marek Olšák"
> }
> {
>   "username": "tpalli",
>   "realname": "Tapani Pälli"
> }

Hmm, a bit clunky, to say the least..

>
> > (Also, I suppose preserving those artifacts of "the old process" is
> > probably useful for folks who run git statistics, although personally
> > that does not effect me.)
>
> [mumbles something about GDPR]
>

hmm, opt-in for exposing name/email in gitlab account settings, I
suppose.. I guess I don't think about that much because my name and
email are already already in a bunch of git trees ;-)

BR,
-R

> Cheers,
> Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Lionel Landwerlin]

- I'm pretty happy with the discussion on a particular point/location of 
a change.

  A lot more readable than a long chain of email.

- Having issues with the comments not always showing up on a particular 
commit of an MR (but it looks like gitlab is aware of that issue)


- The Rb/Ab tags were nice to have with patchwork but did not always 
work and also I tended to add them manually.
  So not really a problem, it's just so tempting to press the merge 
button without adding them first :)


- It seems we only get notifications when adding to an MR, I could like 
to subscribe to particular tags


Overall pretty happy :)

-
Lionel

On 11/01/2019 17:23, Danylo Piliaiev wrote:

My small thoughts/questions:

- First of all discussions are really much more convenient.
- Several (mine) merge requests were "Closed" and merged (not just 
merged, they are under "Closed" category), am I missing something?
- Is there a way to grant rights to creator of merge request to 
add/change tags if he doesn't have "Developer" role?

- Maybe adding more tags/more granular tags would be a good idea.
- Could Intel CI be integrated in some way with gitlab?

Overall as someone who didn't interact with mailing lists workflow 
much Gitlab is definitely a win.


On 1/11/19 6:57 PM, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).  I
(and I'm sure others) would be curious to hear people's initial thoughts on
the process.  What's working well?  What's not working?  Is it total fail
and should we go back to mailing lists?

--Jason


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Tue, 15 Jan 2019 at 23:47, Matt Turner  wrote:
> On Mon, Jan 14, 2019 at 4:36 AM Daniel Stone  wrote:
> > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
> > >  5. There's no way with gitlab for Reviewed-by tags to get automatically 
> > > applied as part of the merging process.  This makes merging a bit more 
> > > manual than it needs to be but is really no worse than it was before.
> >
> > I'm still on the side of not seeing the value in them.
>
> Reviewed-by tags are useful for measuring the quantity of patch review
> people do (which is useful in a corporate environment...). It's often
> a thankless task that's valued much lower than first order
> contributions, so having a way to at least quantify patch reviews
> shows that people are spending their time to help others contribute.
>
> The number of R-b tags is not a 100% accurate picture of the
> situation, but it gives at least a good overview of who is doing the
> tedious work of patch review. For instance, in 2018 the top reviewers
> are
>
> 620 Bas Nieuwenhuizen 
> 530 Marek Olšák 
> 505 Jason Ekstrand 
> 452 Kenneth Graunke 
>
> If my name were in there, it would definitely be something I put on my
> yearly review.

Obviously shell scripting will not do in the advanced enterprise
environment, so we're into the realm of Python. Nevertheless, I've
attached a script which will let you prove your individual worth to
the company, as well as producing a leaderboard for team morale
purposes:

~/tmp % ./kwg-gitlab-rb.py
kwg participated in 10 merged MRs this year (61 total):
MR  105: gallium: Add a PIPE_CAP_QUERY_PIPELINE_STATISTICS_SINGLE
capability and query type
MR   96: st/mesa: Optionally override RGB/RGBX dst alpha blend factors
MR   95: st/nir: Lower TES gl_PatchVerticesIn to a constant if
linked with a TCS.
MR   92: nir: Allow a non-existent sampler deref in
nir_lower_samplers_as_deref
MR   62: i965: fix VF cache issue workaround
MR   39: i965: Enable software support for
ARB_gpu_shader_fp64/ARB_gpu_shader_int64
MR   26: Revert "nir/lower_indirect: Bail early if modes == 0"
MR   12: Add preemption support to i965 on gen9+
MR9: Misc optimizations
MR4: mesa/st: Expose compute shaders when NIR support is advertised.

Top 10 MR participants:
 29 jekstrand
 16 anholt
 14 bnieuwenhuizen
 10 jljusten
 10 kwg
 10 idr
  9 dbaker
  9 eric
  8 llandwerlin
  6 cmarcelo

Cheers,
Daniel
#!/usr/bin/python3

from collections import Counter
import datetime
from itertools import chain
import gitlab
import os
import sys

MY_USERNAME="kwg"
LEADERBOARD_LEN=10

# Look back over the past year
end_of_year = datetime.datetime.now()
start_of_year = end_of_year - datetime.timedelta(days=365)

# ... or calendar years are available
#start_of_year = datetime.datetime(year=2017, month=12, day=31)
#end_of_year = datetime.datetime(year=2019, month=1, day=1)

gl = gitlab.Gitlab("https://gitlab.freedesktop.org;, os.environ["GITLAB_TOKEN"], api_version=4)
project = gl.projects.get(id="mesa/mesa")

merged_mrs = project.mergerequests.list(state="merged", updated_after=start_of_year, updated_before=end_of_year, all=True, as_list=False)
my_mrs = list(filter(lambda mr: MY_USERNAME in [p["username"] for p in mr.participants()], merged_mrs))
print("{user} participated in {me} merged MRs this year ({all} total):".format(user=MY_USERNAME, me=len(my_mrs), all=len(list(merged_mrs
for mr in my_mrs:
print("MR {:4d}: {}".format(mr.iid, mr.title))

print()
print("Top {} MR participants:".format(LEADERBOARD_LEN))

leaderboard = Counter(chain.from_iterable(map(lambda mr: [p["username"] for p in mr.participants()], merged_mrs)))
for hero, count in leaderboard.most_common(LEADERBOARD_LEN):
print("{:3d} {}".format(count, hero))
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Matt Turner]

On Mon, Jan 14, 2019 at 4:36 AM Daniel Stone  wrote:
>
> Hi,
>
> On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
> >  5. There's no way with gitlab for Reviewed-by tags to get automatically 
> > applied as part of the merging process.  This makes merging a bit more 
> > manual than it needs to be but is really no worse than it was before.
>
> I'm still on the side of not seeing the value in them.

Reviewed-by tags are useful for measuring the quantity of patch review
people do (which is useful in a corporate environment...). It's often
a thankless task that's valued much lower than first order
contributions, so having a way to at least quantify patch reviews
shows that people are spending their time to help others contribute.

The number of R-b tags is not a 100% accurate picture of the
situation, but it gives at least a good overview of who is doing the
tedious work of patch review. For instance, in 2018 the top reviewers
are

620 Bas Nieuwenhuizen 
530 Marek Olšák 
505 Jason Ekstrand 
452 Kenneth Graunke 

If my name were in there, it would definitely be something I put on my
yearly review.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hey,

On Tue, 15 Jan 2019 at 20:22, Rob Clark  wrote:
> On Tue, Jan 15, 2019 at 7:40 AM Daniel Stone  wrote:
> > My question would again be what value that brings you. Do you just
> > like seeing the name there, or do you go poke the people on IRC, or
> > follow up via email, or ... ? Again I personally go look through the
> > original review to see what came up during that first, but everyone's
> > different, so I'm just trying to understand what you actually do with
> > that information, so we can figure out if there's a better way to do
> > things for everyone rather than just blindly imitating what came
> > before.
>
> If I am curious or have some questions about why some code is the way
> it is I frequently use tig-blame, which makes it easy to step into the
> commit that made the change and see the commit msg and r-b tags..  I
> guess the most important part if I need to ping someone on IRC w/
> questions is the author, but it seems like having the other tags handy
> without context-switching to browser/gitlab is useful.
>
> I guess I don't as frequently dig into the history of the original
> patchset and it's review comments.. mostly because that isn't as easy
> with the email based review process.  Making this easier would defn be
> a win.  But in cases where I don't have to leave the comfort of tig,
> it would be nice not to have to start doing so..
>
> This is not an argument for sticking to email based process, just
> defence of what I think would be a useful feature for gitlab to gain
> ;-)

Thanks, that helps. How about this? It technically even fits in one
line, though you might wish it didn't.

~/mesa/mesa master ← → * % export
GITLAB_TOKEN=secret-api-token-you-get-from-web-UI
~/mesa/mesa master ← → * % export
GITLAB_COMMIT=f967273fb442de8281f8248e8c8bff5b13ab89e4
~/mesa/mesa master ← → * % curl --silent --header "PRIVATE-TOKEN:
$GITLAB_TOKEN" 
https://gitlab.freedesktop.org/api/v4/projects/mesa%2Fmesa/merge_requests/$(curl
--silent --header "PRIVATE-TOKEN: $GITLAB_TOKEN"
https://gitlab.freedesktop.org/api/v4/projects/mesa%2Fmesa/repository/commits/${GITLAB_COMMIT}/merge_requests
| jq -r '.[] | .iid')/participants | jq -r '.[] | { username:
.username, realname: .name }'
{
  "username": "sroland",
  "realname": "Roland Scheidegger"
}
{
  "username": "kwg",
  "realname": "Kenneth Graunke"
}
{
  "username": "mareko",
  "realname": "Marek Olšák"
}
{
  "username": "tpalli",
  "realname": "Tapani Pälli"
}

> (Also, I suppose preserving those artifacts of "the old process" is
> probably useful for folks who run git statistics, although personally
> that does not effect me.)

[mumbles something about GDPR]

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

On Tue, Jan 15, 2019 at 7:40 AM Daniel Stone  wrote:
>
> Hi,
>
> On Tue, 15 Jan 2019 at 12:21, Rob Clark  wrote:
> > On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli  wrote:
> > > On 1/14/19 2:36 PM, Daniel Stone wrote:
> > > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  
> > > > wrote:
> > > > In other projects, we looked for ways to apply the tags and ended up
> > > > concluding that they didn't bring enough value to make it worthwhile.
> > > > I don't know if that holds for Mesa, but it would be better to start
> > > > with an actual problem statement - what value does R-b bring and how?
> > > > - then look at ways to solve that problem, rather than just very
> > > > directly finding a way to insert that literal text string into every
> > > > commit message.
> > >
> > > IMO it brings some 'shared responsibility' for correctness of the patch
>
> Oh, no doubt - we certainly haven't abandoned thorough review! So far
> we haven't seen that compromised by not having a name in the commit
> message.
>
> > > and quickly accessible information on who were looking at the change. So
> > > ideally later when filing bug against commit/series there would be more
> > > people than just the committer that should take a look at the possible
> > > regressions. At least in my experience people filing bugs tend to often
> > > also CC the reviewer.
>
> Yeah, that's really helpful. So maybe a useful flow - assuming we
> eventually switch to GitLab issues - would be the ability to associate
> an issue with a commit, which could then automatically drag in people
> who commented on the MR which landed that commit, as well as (at
> least) the reporter of the issue(s) fixed by that MR. That would need
> some kind of clever - probably at least semi-manual - filtering to
> make sure it wasn't just spamming the world, but it's at least a
> starting point.
>
> > +1 .. and also it is nice to see things like Reported-by/Reviewed-by
> > without having to go search somewhere else (ie. outside of git/tig)
>
> My question would again be what value that brings you. Do you just
> like seeing the name there, or do you go poke the people on IRC, or
> follow up via email, or ... ? Again I personally go look through the
> original review to see what came up during that first, but everyone's
> different, so I'm just trying to understand what you actually do with
> that information, so we can figure out if there's a better way to do
> things for everyone rather than just blindly imitating what came
> before.

If I am curious or have some questions about why some code is the way
it is I frequently use tig-blame, which makes it easy to step into the
commit that made the change and see the commit msg and r-b tags..  I
guess the most important part if I need to ping someone on IRC w/
questions is the author, but it seems like having the other tags handy
without context-switching to browser/gitlab is useful.

I guess I don't as frequently dig into the history of the original
patchset and it's review comments.. mostly because that isn't as easy
with the email based review process.  Making this easier would defn be
a win.  But in cases where I don't have to leave the comfort of tig,
it would be nice not to have to start doing so..

This is not an argument for sticking to email based process, just
defence of what I think would be a useful feature for gitlab to gain
;-)

(Also, I suppose preserving those artifacts of "the old process" is
probably useful for folks who run git statistics, although personally
that does not effect me.)

BR,
-R

> > (ofc it would be pretty awesome incentive to switch to gitlab issues
> > if gitlab could automate adding Reported-by tags for MR's associated
> > with an issue.. but I guess checkbox to add Reviewed-by tag would
> > already make my day)
>
> I saw this the other day, which might be more incentive:
> https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/
>
> Cheers,
> Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Dylan Baker]

Quoting Jason Ekstrand (2019-01-15 11:57:01)
> On Tue, Jan 15, 2019 at 12:52 PM Eric Anholt  wrote:
> 
> Daniel Stone  writes:
> 
> > Hi,
> >
> > On Tue, 15 Jan 2019 at 12:21, Rob Clark  wrote:
> >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli 
> wrote:
> >> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> >> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand 
> wrote:
> >> > > In other projects, we looked for ways to apply the tags and ended 
> up
> >> > > concluding that they didn't bring enough value to make it
> worthwhile.
> >> > > I don't know if that holds for Mesa, but it would be better to 
> start
> >> > > with an actual problem statement - what value does R-b bring and
> how?
> >> > > - then look at ways to solve that problem, rather than just very
> >> > > directly finding a way to insert that literal text string into 
> every
> >> > > commit message.
> >> >
> >> > IMO it brings some 'shared responsibility' for correctness of the
> patch
> >
> > Oh, no doubt - we certainly haven't abandoned thorough review! So far
> > we haven't seen that compromised by not having a name in the commit
> > message.
> >
> >> > and quickly accessible information on who were looking at the change.
> So
> >> > ideally later when filing bug against commit/series there would be
> more
> >> > people than just the committer that should take a look at the 
> possible
> >> > regressions. At least in my experience people filing bugs tend to
> often
> >> > also CC the reviewer.
> >
> > Yeah, that's really helpful. So maybe a useful flow - assuming we
> > eventually switch to GitLab issues - would be the ability to associate
> > an issue with a commit, which could then automatically drag in people
> > who commented on the MR which landed that commit, as well as (at
> > least) the reporter of the issue(s) fixed by that MR. That would need
> > some kind of clever - probably at least semi-manual - filtering to
> > make sure it wasn't just spamming the world, but it's at least a
> > starting point.
> >
> >> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
> >> without having to go search somewhere else (ie. outside of git/tig)
> >
> > My question would again be what value that brings you. Do you just
> > like seeing the name there, or do you go poke the people on IRC, or
> > follow up via email, or ... ? Again I personally go look through the
> > original review to see what came up during that first, but everyone's
> > different, so I'm just trying to understand what you actually do with
> > that information, so we can figure out if there's a better way to do
> > things for everyone rather than just blindly imitating what came
> > before.
> 
> I've participated in adding Reported-bys, but I've never seen the use.
> It felt like "we could record this information, so we should!" rather
> than solving a problem.
> 
> 
> To me, the Reported-by tag is more for giving credit than anything else.  
> Maybe
> it doesn't matter but some people appreciate it when their contributions, even
> if it's just a good bug report, are recorded in the project's permanent
> record.  It's also a good way to make sure the reporter gets CCd on the patch
> so they can verify it fixes the bug for them.  That said, bugzilla is a
> permanent record and the information would be even more accessible if we just
> used GitLab MRs...

If we used gitlab issues with a Fixes #123 tag the reporter and all subscribers
would be notified and there would still be a permanent record.

Dylan

> I've found little use in ccing reviewers on followups, except for
> trivial stuff like compiler warnings.  I propose that the solution for
> compiler warnings should be CI that prevents you from merging new
> compiler warnings anyway.
> 
> Basically, I feel like the pain points in the MR process (amending and
> re-pushing before clicking "merge") are pre-existing pain points in our
> process, slightly amplified.
> 
> >> (ofc it would be pretty awesome incentive to switch to gitlab issues
> >> if gitlab could automate adding Reported-by tags for MR's associated
> >> with an issue.. but I guess checkbox to add Reviewed-by tag would
> >> already make my day)
> >
> > I saw this the other day, which might be more incentive:
> > https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/
> 2019-01-07-issue-handling-automation/
> 
> Automatic needinfo closing?  Sign me up.

Yes please!


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Jason Ekstrand]

On Tue, Jan 15, 2019 at 12:52 PM Eric Anholt  wrote:

> Daniel Stone  writes:
>
> > Hi,
> >
> > On Tue, 15 Jan 2019 at 12:21, Rob Clark  wrote:
> >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli 
> wrote:
> >> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> >> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand 
> wrote:
> >> > > In other projects, we looked for ways to apply the tags and ended up
> >> > > concluding that they didn't bring enough value to make it
> worthwhile.
> >> > > I don't know if that holds for Mesa, but it would be better to start
> >> > > with an actual problem statement - what value does R-b bring and
> how?
> >> > > - then look at ways to solve that problem, rather than just very
> >> > > directly finding a way to insert that literal text string into every
> >> > > commit message.
> >> >
> >> > IMO it brings some 'shared responsibility' for correctness of the
> patch
> >
> > Oh, no doubt - we certainly haven't abandoned thorough review! So far
> > we haven't seen that compromised by not having a name in the commit
> > message.
> >
> >> > and quickly accessible information on who were looking at the change.
> So
> >> > ideally later when filing bug against commit/series there would be
> more
> >> > people than just the committer that should take a look at the possible
> >> > regressions. At least in my experience people filing bugs tend to
> often
> >> > also CC the reviewer.
> >
> > Yeah, that's really helpful. So maybe a useful flow - assuming we
> > eventually switch to GitLab issues - would be the ability to associate
> > an issue with a commit, which could then automatically drag in people
> > who commented on the MR which landed that commit, as well as (at
> > least) the reporter of the issue(s) fixed by that MR. That would need
> > some kind of clever - probably at least semi-manual - filtering to
> > make sure it wasn't just spamming the world, but it's at least a
> > starting point.
> >
> >> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
> >> without having to go search somewhere else (ie. outside of git/tig)
> >
> > My question would again be what value that brings you. Do you just
> > like seeing the name there, or do you go poke the people on IRC, or
> > follow up via email, or ... ? Again I personally go look through the
> > original review to see what came up during that first, but everyone's
> > different, so I'm just trying to understand what you actually do with
> > that information, so we can figure out if there's a better way to do
> > things for everyone rather than just blindly imitating what came
> > before.
>
> I've participated in adding Reported-bys, but I've never seen the use.
> It felt like "we could record this information, so we should!" rather
> than solving a problem.
>

To me, the Reported-by tag is more for giving credit than anything else.
Maybe it doesn't matter but some people appreciate it when their
contributions, even if it's just a good bug report, are recorded in the
project's permanent record.  It's also a good way to make sure the reporter
gets CCd on the patch so they can verify it fixes the bug for them.  That
said, bugzilla is a permanent record and the information would be even more
accessible if we just used GitLab MRs...


> I've found little use in ccing reviewers on followups, except for
> trivial stuff like compiler warnings.  I propose that the solution for
> compiler warnings should be CI that prevents you from merging new
> compiler warnings anyway.
>
> Basically, I feel like the pain points in the MR process (amending and
> re-pushing before clicking "merge") are pre-existing pain points in our
> process, slightly amplified.
>
> >> (ofc it would be pretty awesome incentive to switch to gitlab issues
> >> if gitlab could automate adding Reported-by tags for MR's associated
> >> with an issue.. but I guess checkbox to add Reviewed-by tag would
> >> already make my day)
> >
> > I saw this the other day, which might be more incentive:
> >
> https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/
>
> Automatic needinfo closing?  Sign me up.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Marek Olšák]

I noticed that gitlab breaks formatting of . It
removes < and >, and converts the address to a hyperlink. I can preserve
the formatting by enclosing the comment in ` ... `.

Marek

On Tue, Jan 15, 2019 at 1:52 PM Eric Anholt  wrote:

> Daniel Stone  writes:
>
> > Hi,
> >
> > On Tue, 15 Jan 2019 at 12:21, Rob Clark  wrote:
> >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli 
> wrote:
> >> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> >> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand 
> wrote:
> >> > > In other projects, we looked for ways to apply the tags and ended up
> >> > > concluding that they didn't bring enough value to make it
> worthwhile.
> >> > > I don't know if that holds for Mesa, but it would be better to start
> >> > > with an actual problem statement - what value does R-b bring and
> how?
> >> > > - then look at ways to solve that problem, rather than just very
> >> > > directly finding a way to insert that literal text string into every
> >> > > commit message.
> >> >
> >> > IMO it brings some 'shared responsibility' for correctness of the
> patch
> >
> > Oh, no doubt - we certainly haven't abandoned thorough review! So far
> > we haven't seen that compromised by not having a name in the commit
> > message.
> >
> >> > and quickly accessible information on who were looking at the change.
> So
> >> > ideally later when filing bug against commit/series there would be
> more
> >> > people than just the committer that should take a look at the possible
> >> > regressions. At least in my experience people filing bugs tend to
> often
> >> > also CC the reviewer.
> >
> > Yeah, that's really helpful. So maybe a useful flow - assuming we
> > eventually switch to GitLab issues - would be the ability to associate
> > an issue with a commit, which could then automatically drag in people
> > who commented on the MR which landed that commit, as well as (at
> > least) the reporter of the issue(s) fixed by that MR. That would need
> > some kind of clever - probably at least semi-manual - filtering to
> > make sure it wasn't just spamming the world, but it's at least a
> > starting point.
> >
> >> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
> >> without having to go search somewhere else (ie. outside of git/tig)
> >
> > My question would again be what value that brings you. Do you just
> > like seeing the name there, or do you go poke the people on IRC, or
> > follow up via email, or ... ? Again I personally go look through the
> > original review to see what came up during that first, but everyone's
> > different, so I'm just trying to understand what you actually do with
> > that information, so we can figure out if there's a better way to do
> > things for everyone rather than just blindly imitating what came
> > before.
>
> I've participated in adding Reported-bys, but I've never seen the use.
> It felt like "we could record this information, so we should!" rather
> than solving a problem.
>
> I've found little use in ccing reviewers on followups, except for
> trivial stuff like compiler warnings.  I propose that the solution for
> compiler warnings should be CI that prevents you from merging new
> compiler warnings anyway.
>
> Basically, I feel like the pain points in the MR process (amending and
> re-pushing before clicking "merge") are pre-existing pain points in our
> process, slightly amplified.
>
> >> (ofc it would be pretty awesome incentive to switch to gitlab issues
> >> if gitlab could automate adding Reported-by tags for MR's associated
> >> with an issue.. but I guess checkbox to add Reviewed-by tag would
> >> already make my day)
> >
> > I saw this the other day, which might be more incentive:
> >
> https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/
>
> Automatic needinfo closing?  Sign me up.
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Eric Anholt]

Daniel Stone  writes:

> Hi,
>
> On Tue, 15 Jan 2019 at 12:21, Rob Clark  wrote:
>> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli  wrote:
>> > On 1/14/19 2:36 PM, Daniel Stone wrote:
>> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  
>> > > wrote:
>> > > In other projects, we looked for ways to apply the tags and ended up
>> > > concluding that they didn't bring enough value to make it worthwhile.
>> > > I don't know if that holds for Mesa, but it would be better to start
>> > > with an actual problem statement - what value does R-b bring and how?
>> > > - then look at ways to solve that problem, rather than just very
>> > > directly finding a way to insert that literal text string into every
>> > > commit message.
>> >
>> > IMO it brings some 'shared responsibility' for correctness of the patch
>
> Oh, no doubt - we certainly haven't abandoned thorough review! So far
> we haven't seen that compromised by not having a name in the commit
> message.
>
>> > and quickly accessible information on who were looking at the change. So
>> > ideally later when filing bug against commit/series there would be more
>> > people than just the committer that should take a look at the possible
>> > regressions. At least in my experience people filing bugs tend to often
>> > also CC the reviewer.
>
> Yeah, that's really helpful. So maybe a useful flow - assuming we
> eventually switch to GitLab issues - would be the ability to associate
> an issue with a commit, which could then automatically drag in people
> who commented on the MR which landed that commit, as well as (at
> least) the reporter of the issue(s) fixed by that MR. That would need
> some kind of clever - probably at least semi-manual - filtering to
> make sure it wasn't just spamming the world, but it's at least a
> starting point.
>
>> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
>> without having to go search somewhere else (ie. outside of git/tig)
>
> My question would again be what value that brings you. Do you just
> like seeing the name there, or do you go poke the people on IRC, or
> follow up via email, or ... ? Again I personally go look through the
> original review to see what came up during that first, but everyone's
> different, so I'm just trying to understand what you actually do with
> that information, so we can figure out if there's a better way to do
> things for everyone rather than just blindly imitating what came
> before.

I've participated in adding Reported-bys, but I've never seen the use.
It felt like "we could record this information, so we should!" rather
than solving a problem.

I've found little use in ccing reviewers on followups, except for
trivial stuff like compiler warnings.  I propose that the solution for
compiler warnings should be CI that prevents you from merging new
compiler warnings anyway.

Basically, I feel like the pain points in the MR process (amending and
re-pushing before clicking "merge") are pre-existing pain points in our
process, slightly amplified.

>> (ofc it would be pretty awesome incentive to switch to gitlab issues
>> if gitlab could automate adding Reported-by tags for MR's associated
>> with an issue.. but I guess checkbox to add Reviewed-by tag would
>> already make my day)
>
> I saw this the other day, which might be more incentive:
> https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/

Automatic needinfo closing?  Sign me up.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Tue, 15 Jan 2019 at 12:21, Rob Clark  wrote:
> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli  wrote:
> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
> > > In other projects, we looked for ways to apply the tags and ended up
> > > concluding that they didn't bring enough value to make it worthwhile.
> > > I don't know if that holds for Mesa, but it would be better to start
> > > with an actual problem statement - what value does R-b bring and how?
> > > - then look at ways to solve that problem, rather than just very
> > > directly finding a way to insert that literal text string into every
> > > commit message.
> >
> > IMO it brings some 'shared responsibility' for correctness of the patch

Oh, no doubt - we certainly haven't abandoned thorough review! So far
we haven't seen that compromised by not having a name in the commit
message.

> > and quickly accessible information on who were looking at the change. So
> > ideally later when filing bug against commit/series there would be more
> > people than just the committer that should take a look at the possible
> > regressions. At least in my experience people filing bugs tend to often
> > also CC the reviewer.

Yeah, that's really helpful. So maybe a useful flow - assuming we
eventually switch to GitLab issues - would be the ability to associate
an issue with a commit, which could then automatically drag in people
who commented on the MR which landed that commit, as well as (at
least) the reporter of the issue(s) fixed by that MR. That would need
some kind of clever - probably at least semi-manual - filtering to
make sure it wasn't just spamming the world, but it's at least a
starting point.

> +1 .. and also it is nice to see things like Reported-by/Reviewed-by
> without having to go search somewhere else (ie. outside of git/tig)

My question would again be what value that brings you. Do you just
like seeing the name there, or do you go poke the people on IRC, or
follow up via email, or ... ? Again I personally go look through the
original review to see what came up during that first, but everyone's
different, so I'm just trying to understand what you actually do with
that information, so we can figure out if there's a better way to do
things for everyone rather than just blindly imitating what came
before.

> (ofc it would be pretty awesome incentive to switch to gitlab issues
> if gitlab could automate adding Reported-by tags for MR's associated
> with an issue.. but I guess checkbox to add Reviewed-by tag would
> already make my day)

I saw this the other day, which might be more incentive:
https://csoriano.pages.gitlab.gnome.org/csoriano-blog/post/2019-01-07-issue-handling-automation/

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Rob Clark]

On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli  wrote:
>
>
>
> On 1/14/19 2:36 PM, Daniel Stone wrote:
> > Hi,
> >
> > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
> >>   5. There's no way with gitlab for Reviewed-by tags to get automatically 
> >> applied as part of the merging process.  This makes merging a bit more 
> >> manual than it needs to be but is really no worse than it was before.
> >
> > I'm still on the side of not seeing the value in them. Most of the
> > time when I go to pursue someone who reviewed a commit, I'll go to see
> > what came up in review anyway. Maybe someone had the same comment
> > which was found to be not applicable or otherwise explained away.
> > Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
> > text descriptors in a comment can much better capture the intent (e.g.
> > 'I'm strongly OK with the driver changes and weakly OK with the core
> > changes as it's not really my area of expertise').
> >
> > In other projects, we looked for ways to apply the tags and ended up
> > concluding that they didn't bring enough value to make it worthwhile.
> > I don't know if that holds for Mesa, but it would be better to start
> > with an actual problem statement - what value does R-b bring and how?
> > - then look at ways to solve that problem, rather than just very
> > directly finding a way to insert that literal text string into every
> > commit message.
>
> IMO it brings some 'shared responsibility' for correctness of the patch
> and quickly accessible information on who were looking at the change. So
> ideally later when filing bug against commit/series there would be more
> people than just the committer that should take a look at the possible
> regressions. At least in my experience people filing bugs tend to often
> also CC the reviewer.

+1 .. and also it is nice to see things like Reported-by/Reviewed-by
without having to go search somewhere else (ie. outside of git/tig)

(ofc it would be pretty awesome incentive to switch to gitlab issues
if gitlab could automate adding Reported-by tags for MR's associated
with an issue.. but I guess checkbox to add Reviewed-by tag would
already make my day)

BR,
-R

> > FWIW, if you go to
> > https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
> > hyperlink from the web UI which points you to the MR. The API to do
> > this is pretty straightforward and amenable to piping through jq:
> > https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit
>
> I guess if we would move issue tracking to gitlab then we could possibly
> automate the CC list generation based on commit?
>
> // Tapani
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[apinheiro]

On 15/1/19 7:01, Tapani Pälli wrote:
>
>
> On 1/14/19 2:36 PM, Daniel Stone wrote:
>> Hi,
>>
>> On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand 
>> wrote:
>>>   5. There's no way with gitlab for Reviewed-by tags to get
>>> automatically applied as part of the merging process.  This makes
>>> merging a bit more manual than it needs to be but is really no worse
>>> than it was before.
>>
>> I'm still on the side of not seeing the value in them. Most of the
>> time when I go to pursue someone who reviewed a commit, I'll go to see
>> what came up in review anyway. Maybe someone had the same comment
>> which was found to be not applicable or otherwise explained away.
>> Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
>> text descriptors in a comment can much better capture the intent (e.g.
>> 'I'm strongly OK with the driver changes and weakly OK with the core
>> changes as it's not really my area of expertise').
>>
>> In other projects, we looked for ways to apply the tags and ended up
>> concluding that they didn't bring enough value to make it worthwhile.
>> I don't know if that holds for Mesa, but it would be better to start
>> with an actual problem statement - what value does R-b bring and how?
>> - then look at ways to solve that problem, rather than just very
>> directly finding a way to insert that literal text string into every
>> commit message.
>
> IMO it brings some 'shared responsibility' for correctness of the
> patch and quickly accessible information on who were looking at the
> change. So ideally later when filing bug against commit/series there
> would be more people than just the committer that should take a look
> at the possible regressions. At least in my experience people filing
> bugs tend to often also CC the reviewer.


In addition to that, it is also useful for big series that are updated
several times, as is a way to know which patches were already reviewed
and which not, so reviewer can focus on the latter.


>
>> FWIW, if you go to
>> https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
>> hyperlink from the web UI which points you to the MR. The API to do
>> this is pretty straightforward and amenable to piping through jq:
>> https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit
>>
>
> I guess if we would move issue tracking to gitlab then we could
> possibly automate the CC list generation based on commit?
>
> // Tapani
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


pEpkey.asc
Description: application/pgp-keys
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Tapani Pälli]

On 1/14/19 2:36 PM, Daniel Stone wrote:

Hi,

On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:

  5. There's no way with gitlab for Reviewed-by tags to get automatically 
applied as part of the merging process.  This makes merging a bit more manual 
than it needs to be but is really no worse than it was before.


I'm still on the side of not seeing the value in them. Most of the
time when I go to pursue someone who reviewed a commit, I'll go to see
what came up in review anyway. Maybe someone had the same comment
which was found to be not applicable or otherwise explained away.
Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
text descriptors in a comment can much better capture the intent (e.g.
'I'm strongly OK with the driver changes and weakly OK with the core
changes as it's not really my area of expertise').

In other projects, we looked for ways to apply the tags and ended up
concluding that they didn't bring enough value to make it worthwhile.
I don't know if that holds for Mesa, but it would be better to start
with an actual problem statement - what value does R-b bring and how?
- then look at ways to solve that problem, rather than just very
directly finding a way to insert that literal text string into every
commit message.


IMO it brings some 'shared responsibility' for correctness of the patch 
and quickly accessible information on who were looking at the change. So 
ideally later when filing bug against commit/series there would be more 
people than just the committer that should take a look at the possible 
regressions. At least in my experience people filing bugs tend to often 
also CC the reviewer.



FWIW, if you go to
https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
hyperlink from the web UI which points you to the MR. The API to do
this is pretty straightforward and amenable to piping through jq:
https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit


I guess if we would move issue tracking to gitlab then we could possibly 
automate the CC list generation based on commit?


// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Marek Olšák]

There are still people who don't look at the merge requests in gitlab yet,
like me. :) I've noticed there are fewer emails... I'll switch after you
guys figure out whether MRs are better.

Marek

On Mon, Jan 14, 2019 at 7:36 AM Daniel Stone  wrote:

> Hi,
>
> On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
> >  5. There's no way with gitlab for Reviewed-by tags to get automatically
> applied as part of the merging process.  This makes merging a bit more
> manual than it needs to be but is really no worse than it was before.
>
> I'm still on the side of not seeing the value in them. Most of the
> time when I go to pursue someone who reviewed a commit, I'll go to see
> what came up in review anyway. Maybe someone had the same comment
> which was found to be not applicable or otherwise explained away.
> Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
> text descriptors in a comment can much better capture the intent (e.g.
> 'I'm strongly OK with the driver changes and weakly OK with the core
> changes as it's not really my area of expertise').
>
> In other projects, we looked for ways to apply the tags and ended up
> concluding that they didn't bring enough value to make it worthwhile.
> I don't know if that holds for Mesa, but it would be better to start
> with an actual problem statement - what value does R-b bring and how?
> - then look at ways to solve that problem, rather than just very
> directly finding a way to insert that literal text string into every
> commit message.
>
> FWIW, if you go to
> https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
> hyperlink from the web UI which points you to the MR. The API to do
> this is pretty straightforward and amenable to piping through jq:
>
> https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit
>
> Cheers,
> Daniel
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Dylan Baker]

Quoting Axel Davy (2019-01-12 09:40:40)
> Hi,
> 
> I'm not sure the promise "1 mail per pull request" is working well.
> For example, taking one recent pull request
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/105
> 
> I didn't receive anything, nor
> https://lists.freedesktop.org/archives/mesa-dev/2019-January/thread.html
> yet.
> 
> I received some mails with [MR] in the title with two lines indicating merge
> requests, but that seems to be for a minority of the requests.
> 
> I guess the system is not automated right now.
> 
> I think there needs to be an automated system, and that it should look pretty
> close to what a cover-letter for a mail serie should look like, that is:
> . The global stat diffs of the merge requests (which files are affected, how
> many modifications, etc)
> . The summary of the request
> . All the patch titles
> 
> I don't want to go open all merge requests in my browser to get that
> information.
> So far I only went check the list of gitlab merge requests 3 times, whereas I
> go through my mails several times a day.
> 
> 
> Yours,
> 
> Axel Davy
> 
> 
> 
> 
> On 11/01/2019 17:57, Jason Ekstrand wrote:
> 
> All,
> 
> The mesa project has now hit 100 merge requests (36 are still open).  I
> (and I'm sure others) would be curious to hear people's initial thoughts 
> on
> the process.  What's working well?  What's not working?  Is it total fail
> and should we go back to mailing lists?
> 
> --Jason
> 
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 

Another option, which I find much better, is to just subscribe to the MRs for
all of mesa in gitlab. I've then set up my mail client to sort all of those
mails and all of mesa-dev into the view so there is zero gap between the mailing
list and gitlab.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Caio Marcelo de Oliveira Filho]

On Mon, Jan 14, 2019 at 12:36:26PM +, Daniel Stone wrote:
> FWIW, if you go to
> https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
> hyperlink from the web UI which points you to the MR. The API to do
> this is pretty straightforward and amenable to piping through jq:
> https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit

That works great and solves one of the issues I had.  Thanks!

Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Daniel Stone]

Hi,

On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand  wrote:
>  5. There's no way with gitlab for Reviewed-by tags to get automatically 
> applied as part of the merging process.  This makes merging a bit more manual 
> than it needs to be but is really no worse than it was before.

I'm still on the side of not seeing the value in them. Most of the
time when I go to pursue someone who reviewed a commit, I'll go to see
what came up in review anyway. Maybe someone had the same comment
which was found to be not applicable or otherwise explained away.
Reviewed-by and Acked-by are also pretty lossy anyway, and freeform
text descriptors in a comment can much better capture the intent (e.g.
'I'm strongly OK with the driver changes and weakly OK with the core
changes as it's not really my area of expertise').

In other projects, we looked for ways to apply the tags and ended up
concluding that they didn't bring enough value to make it worthwhile.
I don't know if that holds for Mesa, but it would be better to start
with an actual problem statement - what value does R-b bring and how?
- then look at ways to solve that problem, rather than just very
directly finding a way to insert that literal text string into every
commit message.

FWIW, if you go to
https://gitlab.freedesktop.org/mesa/mesa/commit/SHA1 then you get a
hyperlink from the web UI which points you to the MR. The API to do
this is pretty straightforward and amenable to piping through jq:
https://docs.gitlab.com/ce/api/commits.html#list-merge-requests-associated-with-a-commit

Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Timothy Arceri]

To be honest I have mixed feelings about using Gitlab merge requests. As 
Jason mentions bellow the discussions feature is a nice way to avoid the 
mess that can happen with mailings list replys.


However I seem to find myself fighting with the interface more that 
should be necessary. Most of this is probably just that it takes time to 
get used too. But the single most annoying thing is having to expand the 
code comment when looking at a commit. Especially during review you 
always want to view the comment. It would be s much nicer if these 
were always expanded by default. Is there a setting for this somewhere?


Tim

On 12/1/19 4:05 am, Jason Ekstrand wrote:
I'm putting my own thoughts in a reply for some reason.  Here's what 
I've seen.


  1. I really like GitLab "discussions".  It provides a very good way 
for both the author and the reviewers to keep track of what review 
comments have been dealt with and what comments are still outstanding.


  2. GitLab is currently missing a good way to comment on commit 
messages which makes giving review tags rather painful.  There is a 
GitLab issue opened about this: 
https://gitlab.com/gitlab-org/gitlab-ce/issues/38602


  3. GitLab has a bug regarding per-commit comments where they tend to 
get lost while you're looking at the commit itself: 
https://gitlab.com/gitlab-org/gitlab-ce/issues/53175


  4. At least two of those merge requests were small bug fixes by brand 
new contributors who I've never seen on the mailing list.


  5. There's no way with gitlab for Reviewed-by tags to get 
automatically applied as part of the merging process.  This makes 
merging a bit more manual than it needs to be but is really no worse 
than it was before.


Ok, there you have my thoughts.  I'd be happy to hear others.

--Jason

On Fri, Jan 11, 2019 at 10:57 AM Jason Ekstrand > wrote:


All,

The mesa project has now hit 100 merge requests (36 are still
open).  I (and I'm sure others) would be curious to hear people's
initial thoughts on the process.  What's working well?  What's not
working?  Is it total fail and should we go back to mailing lists?

--Jason


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Axel Davy]

Hi,

I'm not sure the promise "1 mail per pull request" is working well.
For example, taking one recent pull request
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/105

I didn't receive anything, nor
https://lists.freedesktop.org/archives/mesa-dev/2019-January/thread.html
yet.

I received some mails with [MR] in the title with two lines indicating 
merge requests, but that seems to be for a minority of the requests.


I guess the system is not automated right now.

I think there needs to be an automated system, and that it should look 
pretty close to what a cover-letter for a mail serie should look like, 
that is:
. The global stat diffs of the merge requests (which files are affected, 
how many modifications, etc)

. The summary of the request
. All the patch titles

I don't want to go open all merge requests in my browser to get that 
information.
So far I only went check the list of gitlab merge requests 3 times, 
whereas I go through my mails several times a day.



Yours,

Axel Davy




On 11/01/2019 17:57, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).  
I (and I'm sure others) would be curious to hear people's initial 
thoughts on the process.  What's working well?  What's not working?  
Is it total fail and should we go back to mailing lists?


--Jason

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[apinheiro]

I mostly agree with your thoughts below. Will add some additional
comments inline.

On 11/1/19 18:05, Jason Ekstrand wrote:
> I'm putting my own thoughts in a reply for some reason.  Here's what
> I've seen.
>
>  1. I really like GitLab "discussions".  It provides a very good way
> for both the author and the reviewers to keep track of what review
> comments have been dealt with and what comments are still outstanding.


Yes, I agree that the general discussion for a series has improved. But ...

>
>  2. GitLab is currently missing a good way to comment on commit
> messages which makes giving review tags rather painful.  There is a
> GitLab issue opened about this:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/38602
>
>  3. GitLab has a bug regarding per-commit comments where they tend to
> get lost while you're looking at the commit itself:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/53175


... as you mention here, there are some per-commit bugs. This makes
per-commit discussion and tagging (as you mention below) harder, so the
general discussion gets somewhat messy with individual commit messages.
And in addition to what your comment here, I miss the possibility to add
an annotate section on individual commits. For example, the usual
annotate section "I have this, but I'm not happy of X due Y, what do you
think", or in other words, a placeholder for starting a
discussion/debate for such commit. I guess that if those bugs are fixed,
it would be just doing the push, and then adding those "annotate
sections" on the commits.

>
>  4. At least two of those merge requests were small bug fixes by brand
> new contributors who I've never seen on the mailing list.
>
>  5. There's no way with gitlab for Reviewed-by tags to get
> automatically applied as part of the merging process.  This makes
> merging a bit more manual than it needs to be but is really no worse
> than it was before.


Well, I would say that it slightly worse. For small series, it is true
that I manually added the Rb when I got a review. But for big series,
when it got reviewed, I used patchwork to get back the series, but with
the Rb in place.

>
> Ok, there you have my thoughts.  I'd be happy to hear others.
>
> --Jason
>
> On Fri, Jan 11, 2019 at 10:57 AM Jason Ekstrand  > wrote:
>
> All,
>
> The mesa project has now hit 100 merge requests (36 are still
> open).  I (and I'm sure others) would be curious to hear people's
> initial thoughts on the process.  What's working well?  What's not
> working?  Is it total fail and should we go back to mailing lists?
>
> --Jason
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


pEpkey.asc
Description: application/pgp-keys
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Caio Marcelo de Oliveira Filho]

On Fri, Jan 11, 2019 at 10:57:16AM -0600, Jason Ekstrand wrote:
> All,
> 
> The mesa project has now hit 100 merge requests (36 are still open).  I
> (and I'm sure others) would be curious to hear people's initial thoughts on
> the process.  What's working well?  What's not working?  Is it total fail
> and should we go back to mailing lists?

Here are my findings after interacting with it for a few patches (both
in Mesa and other repositories)

+ It is way easier to keep track of patches that are still open/being-reviewed.
  + Labels on the MRs work well to filter out patches.

+ Because MRs git references are published in the repo, it is easy to
  "checkout" a MR.

- Reviewing patch series with lots of patches is very inconvenient:
  - Can't make comments on individual patches.  Which forces us to view
all the changes together.  Which then makes UI hide some files that
are too big (you need to manually expand).
Upstream issue https://gitlab.com/gitlab-org/gitlab-ce/issues/53175.
  - Can't make comments on the commit message.
Upstream issue https://gitlab.com/gitlab-org/gitlab-ce/issues/38602.

- Having to send the "Hey, here's a new MR" email to the mailing list
  for a small patch made me just go ahead and send the patch directly
  to the list instead.  Making those announcements automatic would be
  very helpful.

- To find the discussion associated with a commit in master, I'd
  search the title in the mailing list archives.  With MRs, the usual
  way that this connection is made would be the reference to the MR as
  part of the merge commit message, but in Mesa we don't currently use
  merge commits.  I've tried to search for commit titles in MR
  interface but it doesn't find them.


Thanks,
Caio
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Samuel Pitoiset]

I haven't played with merge requests yet, except for reviewing some 
small RADV patches from Bas.


From my point of view, the main problem now is that we have to look 
both at the mailing list and at the merge requests page and that's quite 
annoying.


I don't think it's really a win to have two different workflows for the 
same project.


I think I would still prefer the mailing list approach because it looks 
faster than open a browser, click, click and re-click (all my emails are 
well sorted in Thunderbird).


On 1/11/19 5:57 PM, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).  
I (and I'm sure others) would be curious to hear people's initial 
thoughts on the process.  What's working well?  What's not working?  
Is it total fail and should we go back to mailing lists?


--Jason

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Jason Ekstrand]

On Fri, Jan 11, 2019 at 11:23 AM Danylo Piliaiev 
wrote:

> My small thoughts/questions:
>
> - First of all discussions are really much more convenient.
> - Several (mine) merge requests were "Closed" and merged (not just merged,
> they are under "Closed" category), am I missing something?
>

It depends on how it's merged.  My preference (and I would recommend this
to others) is to have the submitter check the "Allow commits from members
who can merge to the target branch." check box and then use the web UI to
rebase and merge.  Then the merge request shows up under "merged" instead
of "closed".  What some other people have taken to doing is to just push
the changes to master and then close the MR.  It also works but I think
it's probably more confusing to submitters.


> - Is there a way to grant rights to creator of merge request to add/change
> tags if he doesn't have "Developer" role?
>

I'm not sure.


> - Maybe adding more tags/more granular tags would be a good idea.
> - Could Intel CI be integrated in some way with gitlab?
>
> Overall as someone who didn't interact with mailing lists workflow much
> Gitlab is definitely a win.
>
> On 1/11/19 6:57 PM, Jason Ekstrand wrote:
>
> All,
>
> The mesa project has now hit 100 merge requests (36 are still open).  I
> (and I'm sure others) would be curious to hear people's initial thoughts on
> the process.  What's working well?  What's not working?  Is it total fail
> and should we go back to mailing lists?
>
> --Jason
>
>
>
> ___
> mesa-dev mailing 
> listmesa-dev@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Dylan Baker]

Quoting Jason Ekstrand (2019-01-11 09:05:21)
> I'm putting my own thoughts in a reply for some reason.  Here's what I've 
> seen.
> 
>  1. I really like GitLab "discussions".  It provides a very good way for both
> the author and the reviewers to keep track of what review comments have been
> dealt with and what comments are still outstanding.
> 
>  2. GitLab is currently missing a good way to comment on commit messages which
> makes giving review tags rather painful.  There is a GitLab issue opened about
> this: https://gitlab.com/gitlab-org/gitlab-ce/issues/38602
> 
>  3. GitLab has a bug regarding per-commit comments where they tend to get lost
> while you're looking at the commit itself: https://gitlab.com/gitlab-org/
> gitlab-ce/issues/53175
> 
>  4. At least two of those merge requests were small bug fixes by brand new
> contributors who I've never seen on the mailing list.
> 
>  5. There's no way with gitlab for Reviewed-by tags to get automatically
> applied as part of the merging process.  This makes merging a bit more manual
> than it needs to be but is really no worse than it was before.
> 
> Ok, there you have my thoughts.  I'd be happy to hear others.
> 
> --Jason
> 
> On Fri, Jan 11, 2019 at 10:57 AM Jason Ekstrand  wrote:
> 
> All,
> 
> The mesa project has now hit 100 merge requests (36 are still open).  I
> (and I'm sure others) would be curious to hear people's initial thoughts 
> on
> the process.  What's working well?  What's not working?  Is it total fail
> and should we go back to mailing lists?
> 
> --Jason
> 

Your assessment matches pretty closely with mine.

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Danylo Piliaiev]

My small thoughts/questions:

- First of all discussions are really much more convenient.
- Several (mine) merge requests were "Closed" and merged (not just 
merged, they are under "Closed" category), am I missing something?
- Is there a way to grant rights to creator of merge request to 
add/change tags if he doesn't have "Developer" role?

- Maybe adding more tags/more granular tags would be a good idea.
- Could Intel CI be integrated in some way with gitlab?

Overall as someone who didn't interact with mailing lists workflow much 
Gitlab is definitely a win.


On 1/11/19 6:57 PM, Jason Ekstrand wrote:

All,

The mesa project has now hit 100 merge requests (36 are still open).  I
(and I'm sure others) would be curious to hear people's initial thoughts on
the process.  What's working well?  What's not working?  Is it total fail
and should we go back to mailing lists?

--Jason


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Jason Ekstrand]

I'm putting my own thoughts in a reply for some reason.  Here's what I've
seen.

 1. I really like GitLab "discussions".  It provides a very good way for
both the author and the reviewers to keep track of what review comments
have been dealt with and what comments are still outstanding.

 2. GitLab is currently missing a good way to comment on commit messages
which makes giving review tags rather painful.  There is a GitLab issue
opened about this: https://gitlab.com/gitlab-org/gitlab-ce/issues/38602

 3. GitLab has a bug regarding per-commit comments where they tend to get
lost while you're looking at the commit itself:
https://gitlab.com/gitlab-org/gitlab-ce/issues/53175

 4. At least two of those merge requests were small bug fixes by brand new
contributors who I've never seen on the mailing list.

 5. There's no way with gitlab for Reviewed-by tags to get automatically
applied as part of the merging process.  This makes merging a bit more
manual than it needs to be but is really no worse than it was before.

Ok, there you have my thoughts.  I'd be happy to hear others.

--Jason

On Fri, Jan 11, 2019 at 10:57 AM Jason Ekstrand 
wrote:

> All,
>
> The mesa project has now hit 100 merge requests (36 are still open).  I
> (and I'm sure others) would be curious to hear people's initial thoughts on
> the process.  What's working well?  What's not working?  Is it total fail
> and should we go back to mailing lists?
>
> --Jason
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Thoughts after hitting 100 merge requests?

[Jason Ekstrand]

All,

The mesa project has now hit 100 merge requests (36 are still open).  I
(and I'm sure others) would be curious to hear people's initial thoughts on
the process.  What's working well?  What's not working?  Is it total fail
and should we go back to mailing lists?

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev