Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Emil Velikov (2018-06-27 01:39:05) > On 26 June 2018 at 16:34, Dylan Baker wrote: > > > I just remembered that you can set two push remotes for a single branch, so > > I > > think I'll add a staging/18.1 branch to master as a second remote and push > > to > > that as well. Do you like that name, or would you prefer something > > different? > > > My initial idea was to use wip/ although staging/ seems clearer and > more obvious. > > Thanks > Emil I'd like to avoid wip/ if possible, since at least Jason and myself use wip/ for our own branches. That's why I thought of using staging. 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] [ANNOUNCE] Mesa 18.1.2 release candidate
On 26 June 2018 at 16:34, Dylan Baker wrote: > I just remembered that you can set two push remotes for a single branch, so I > think I'll add a staging/18.1 branch to master as a second remote and push to > that as well. Do you like that name, or would you prefer something different? > My initial idea was to use wip/ although staging/ seems clearer and more obvious. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Tue, 2018-06-26 at 08:34 -0700, Dylan Baker wrote: > Quoting Juan A. Suarez Romero (2018-06-19 00:08:27) > > On Fri, 2018-06-15 at 09:36 -0700, Dylan Baker wrote: > > > Quoting Juan A. Suarez Romero (2018-06-15 07:26:18) > > > > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > > > > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > > > > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > > > > > Hello list, > > > > > > > > > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we > > > > > > > have: > > > > > > > - 42 queued > > > > > > > - 6 nominated (outstanding) > > > > > > > - and 0 rejected patches > > > > > > > > > > > > > > Notable changes in this release: > > > > > > > - numerous fixes for radv > > > > > > > - libatomic checks for meson, as well as fixing coverage for less > > > > > > > common (not > > > > > > > arm or x86) platforms > > > > > > > - lots of common Intel fixes > > > > > > > - GLX fixes > > > > > > > - tarball fixes for android > > > > > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross > > > > > > > compile > > > > > > > > > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > > > > > > > > > > > > > Testing reports/general approval > > > > > > > > > > > > > > Any testing reports (or general approval of the state of the > > > > > > > branch) will be > > > > > > > greatly appreciated. > > > > > > > > > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or > > > > > > > shortly after 10 > > > > > > > AM PDT. > > > > > > > > > > > > June 15th? > > > > > > > > > > Yes, June 15th. > > > > > > > > > > Apparently being woken up at 5AM does more brain damage than I > > > > > thought. > > > > > > > > Also, we usually wait 48h (two days) between the pre-announcement and > > > > the final > > > > release, to give more time for testing. > > > > > > > > > > > > J.A. > > > > > > > > > > I don't even understand why we make these announcements TBH. I have a > > > public > > > 18.1-proposed branch that I push to *every weekday*. > > > > > > Out of curiosity, any reason to keep the proposed branch in your personal > > repository, instead of in main Mesa repo? > > > > > > I thought the proposal was to have those proposed/wip branches in the main > > repository, so everybody is aware were they are, no matter who is in charge > > of > > the release. > > > > > > J.A. > > > > > Anyone can pull that branch > > > *anytime* to get the latest version. The only thing the announce email > > > really > > > serves AFAICT, is to say "the staging/proposed branch has been merged to > > > the > > > release branch". I don't think that's all that interesting TBH. > > > > > > Dylan > > I just remembered that you can set two push remotes for a single branch, so I > think I'll add a staging/18.1 branch to master as a second remote and push to > that as well. Do you like that name, or would you prefer something different? > I like it. J.A. > Dylan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Juan A. Suarez Romero (2018-06-19 00:08:27) > On Fri, 2018-06-15 at 09:36 -0700, Dylan Baker wrote: > > Quoting Juan A. Suarez Romero (2018-06-15 07:26:18) > > > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > > > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > > > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > > > > Hello list, > > > > > > > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we > > > > > > have: > > > > > > - 42 queued > > > > > > - 6 nominated (outstanding) > > > > > > - and 0 rejected patches > > > > > > > > > > > > Notable changes in this release: > > > > > > - numerous fixes for radv > > > > > > - libatomic checks for meson, as well as fixing coverage for less > > > > > > common (not > > > > > > arm or x86) platforms > > > > > > - lots of common Intel fixes > > > > > > - GLX fixes > > > > > > - tarball fixes for android > > > > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross > > > > > > compile > > > > > > > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > > > > > > > > > > Testing reports/general approval > > > > > > > > > > > > Any testing reports (or general approval of the state of the > > > > > > branch) will be > > > > > > greatly appreciated. > > > > > > > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or > > > > > > shortly after 10 > > > > > > AM PDT. > > > > > > > > > > June 15th? > > > > > > > > Yes, June 15th. > > > > > > > > Apparently being woken up at 5AM does more brain damage than I thought. > > > > > > Also, we usually wait 48h (two days) between the pre-announcement and the > > > final > > > release, to give more time for testing. > > > > > > > > > J.A. > > > > > > > I don't even understand why we make these announcements TBH. I have a public > > 18.1-proposed branch that I push to *every weekday*. > > > Out of curiosity, any reason to keep the proposed branch in your personal > repository, instead of in main Mesa repo? > > > I thought the proposal was to have those proposed/wip branches in the main > repository, so everybody is aware were they are, no matter who is in charge of > the release. > > > J.A. > > > Anyone can pull that branch > > *anytime* to get the latest version. The only thing the announce email > > really > > serves AFAICT, is to say "the staging/proposed branch has been merged to the > > release branch". I don't think that's all that interesting TBH. > > > > Dylan I just remembered that you can set two push remotes for a single branch, so I think I'll add a staging/18.1 branch to master as a second remote and push to that as well. Do you like that name, or would you prefer something different? 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] [ANNOUNCE] Mesa 18.1.2 release candidate
Hi Stuart, On 20 June 2018 at 00:10, Stuart Young wrote: > Whichever way this goes, is it possible to have the pre-announce include a > link to the git repo/branch in question? > > This way, even if it's not part of the main repo, people can easily find it > and check out the pre-release in full. > > FWIW: An advantage of not requiring it to be in the main repo is that if for > whatever reason the main repo isn't available on the day (eg: outage, major > re-org, gitlab down for a few hours, network issues, etc), it can be > uploaded elsewhere and people can still proceed to check things out till the > main repo is available again. > > Personally I think it makes sense to be in the main repo where possible, but > allowing for the possibility of it not being there in certain circumstances, > by explicitly linking to it in the pre-release so it's unambiguous. Of > course, it should be in the main repo for final release. > Since nobody mentioned it - there is a github mirror [1]. If gets updated, automatically, on each push to the official repo. Thus having the wip stable branch as part of the official repo will effectively feature it on github. Your point is good, having a link to the branch in the email will clear any confusion. HTH Emil [1] https://github.com/mesa3d/mesa ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Whichever way this goes, is it possible to have the pre-announce include a link to the git repo/branch in question? This way, even if it's not part of the main repo, people can easily find it and check out the pre-release in full. FWIW: An advantage of not requiring it to be in the main repo is that if for whatever reason the main repo isn't available on the day (eg: outage, major re-org, gitlab down for a few hours, network issues, etc), it can be uploaded elsewhere and people can still proceed to check things out till the main repo is available again. Personally I think it makes sense to be in the main repo where possible, but allowing for the possibility of it not being there in certain circumstances, by explicitly linking to it in the pre-release so it's unambiguous. Of course, it should be in the main repo for final release. On Wed, 20 Jun 2018 at 03:23, Ilia Mirkin wrote: > On Mon, Jun 18, 2018 at 12:56 PM, Dylan Baker wrote: > > Quoting Juan A. Suarez Romero (2018-06-18 00:22:02) > >> On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote: > >> > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker > wrote: > >> > > I don't even understand why we make these announcements TBH. I have > a public > >> > > 18.1-proposed branch that I push to *every weekday*. Anyone can > pull that branch > >> > > *anytime* to get the latest version. The only thing the announce > email really > >> > > serves AFAICT, is to say "the staging/proposed branch has been > merged to the > >> > > release branch". I don't think that's all that interesting TBH. > >> > > >> > "any time" means "no time". The announcement is "speak now or forever > >> > hold your peace". Gives driver teams a chance to review the list and > >> > test things out before they go out into a full release. Should they be > >> > doing this daily/continuously? Probably. But that's not the current > >> > state. > >> > > >> > >> I agree on this. And I think the reason to wait 48h is to give time > enough for > >> teams to do proper testing, specially when there are many timezones > that people > >> get the pre-announcement several hours later. > >> > >> > >> But, I also think that the pre-announcement is too much verbose. It > includes lot > >> of information that can be easily get from the git branch itself. The > only thing > >> I would probably keep is about trivial conflicts, sending an explicit > email to > >> the authors to say "I [slightly] changed your commit; please, take a > look just > >> in case", and the rejected patch list, also mailing the authors. > > > > I follow up with authors about changes immediately. If it was rejected I > reply > > to the original patch letting them know I'm not planning to pull the > commit and > > why. If there's conflicts I ask the original author to look at the > changes I've > > made before pulling them into the staging branch. > > That's really helpful, thanks! > > > It feels much too late to be > > asking someone to do that when the release is happening shortly. > > In order for me to find it useful, the flow has to be: > > 1. Pre-announce saying which patches you're taking > 2. Take feedback from driver maintainers regarding patches to remove or add > 3. Do release (or go to 1 if the requested changes were substantial, > at your discretion) > > I realize you're doing this as part of your job, and since I'm not > your employer, I have little say over how you actually do this ... my > options are whether I opt into the stable process or not. I've been > frustrated with the process for a long time - since the mid 10.x's, as > evidenced by my periodic outbursts on the matter, and I've largely > opted out since around 18.0 - it's not worth the heartache for me. > Which is fine - I just tell people to build from HEAD and all is well. > Perhaps I'm in a unique situation and can be ignored -- like I said, > I'm perfectly fine with the status quo of not caring about stable. > Basically no one uses nouveau anyways. > > -ilia > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Mon, Jun 18, 2018 at 12:56 PM, Dylan Baker wrote: > Quoting Juan A. Suarez Romero (2018-06-18 00:22:02) >> On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote: >> > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote: >> > > I don't even understand why we make these announcements TBH. I have a >> > > public >> > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull >> > > that branch >> > > *anytime* to get the latest version. The only thing the announce email >> > > really >> > > serves AFAICT, is to say "the staging/proposed branch has been merged to >> > > the >> > > release branch". I don't think that's all that interesting TBH. >> > >> > "any time" means "no time". The announcement is "speak now or forever >> > hold your peace". Gives driver teams a chance to review the list and >> > test things out before they go out into a full release. Should they be >> > doing this daily/continuously? Probably. But that's not the current >> > state. >> > >> >> I agree on this. And I think the reason to wait 48h is to give time enough >> for >> teams to do proper testing, specially when there are many timezones that >> people >> get the pre-announcement several hours later. >> >> >> But, I also think that the pre-announcement is too much verbose. It includes >> lot >> of information that can be easily get from the git branch itself. The only >> thing >> I would probably keep is about trivial conflicts, sending an explicit email >> to >> the authors to say "I [slightly] changed your commit; please, take a look >> just >> in case", and the rejected patch list, also mailing the authors. > > I follow up with authors about changes immediately. If it was rejected I reply > to the original patch letting them know I'm not planning to pull the commit > and > why. If there's conflicts I ask the original author to look at the changes > I've > made before pulling them into the staging branch. That's really helpful, thanks! > It feels much too late to be > asking someone to do that when the release is happening shortly. In order for me to find it useful, the flow has to be: 1. Pre-announce saying which patches you're taking 2. Take feedback from driver maintainers regarding patches to remove or add 3. Do release (or go to 1 if the requested changes were substantial, at your discretion) I realize you're doing this as part of your job, and since I'm not your employer, I have little say over how you actually do this ... my options are whether I opt into the stable process or not. I've been frustrated with the process for a long time - since the mid 10.x's, as evidenced by my periodic outbursts on the matter, and I've largely opted out since around 18.0 - it's not worth the heartache for me. Which is fine - I just tell people to build from HEAD and all is well. Perhaps I'm in a unique situation and can be ignored -- like I said, I'm perfectly fine with the status quo of not caring about stable. Basically no one uses nouveau anyways. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Daniel Stone (2018-06-19 08:47:13) > Hi Dylan, > On Tue, 19 Jun 2018 at 16:42, Dylan Baker wrote: > > Historical artifact. When I created the proposed branch we didn't have a > > policy > > of putting it on master instead of a personal repo, and we were discussing a > > transition to gitlab. I also seem to remember that the gitlab doesn't allow > > force pushes (unless you're a repo owner?), which are a requirement for a > > staging/proposed branch. I'd rather not move it at this point since that > > would > > require changing all of our CI automation to match that new repo, but if we > > can > > force-push I'd be happy to put future staging branches in the main mesa > > repo. > > Force-pushes are a repo-by-repo policy thing. GitLab currently > disallows force-pushes on master and release (e.g. '18.0') branches, > but allows them on everything else. So as long as it's tucked away > under another namespace (e.g. 'testing/18.1.2-candidate' or whatever) > then you should be good. > > Cheers, > Daniel That sounds like maybe moving to something like "staging/18.1" would be a good thing to do for future releases. I can move my branch to the gitlab master if the consensus is that's a better place for it, I was just being grumpy this morning :) 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] [ANNOUNCE] Mesa 18.1.2 release candidate
Hi Dylan, On Tue, 19 Jun 2018 at 16:42, Dylan Baker wrote: > Historical artifact. When I created the proposed branch we didn't have a > policy > of putting it on master instead of a personal repo, and we were discussing a > transition to gitlab. I also seem to remember that the gitlab doesn't allow > force pushes (unless you're a repo owner?), which are a requirement for a > staging/proposed branch. I'd rather not move it at this point since that would > require changing all of our CI automation to match that new repo, but if we > can > force-push I'd be happy to put future staging branches in the main mesa repo. Force-pushes are a repo-by-repo policy thing. GitLab currently disallows force-pushes on master and release (e.g. '18.0') branches, but allows them on everything else. So as long as it's tucked away under another namespace (e.g. 'testing/18.1.2-candidate' or whatever) then you should be good. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Juan A. Suarez Romero (2018-06-19 00:08:27) > On Fri, 2018-06-15 at 09:36 -0700, Dylan Baker wrote: > > Quoting Juan A. Suarez Romero (2018-06-15 07:26:18) > > > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > > > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > > > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > > > > Hello list, > > > > > > > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we > > > > > > have: > > > > > > - 42 queued > > > > > > - 6 nominated (outstanding) > > > > > > - and 0 rejected patches > > > > > > > > > > > > Notable changes in this release: > > > > > > - numerous fixes for radv > > > > > > - libatomic checks for meson, as well as fixing coverage for less > > > > > > common (not > > > > > > arm or x86) platforms > > > > > > - lots of common Intel fixes > > > > > > - GLX fixes > > > > > > - tarball fixes for android > > > > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross > > > > > > compile > > > > > > > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > > > > > > > > > > Testing reports/general approval > > > > > > > > > > > > Any testing reports (or general approval of the state of the > > > > > > branch) will be > > > > > > greatly appreciated. > > > > > > > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or > > > > > > shortly after 10 > > > > > > AM PDT. > > > > > > > > > > June 15th? > > > > > > > > Yes, June 15th. > > > > > > > > Apparently being woken up at 5AM does more brain damage than I thought. > > > > > > Also, we usually wait 48h (two days) between the pre-announcement and the > > > final > > > release, to give more time for testing. > > > > > > > > > J.A. > > > > > > > I don't even understand why we make these announcements TBH. I have a public > > 18.1-proposed branch that I push to *every weekday*. > > > Out of curiosity, any reason to keep the proposed branch in your personal > repository, instead of in main Mesa repo? > > > I thought the proposal was to have those proposed/wip branches in the main > repository, so everybody is aware were they are, no matter who is in charge of > the release. > > > J.A. Historical artifact. When I created the proposed branch we didn't have a policy of putting it on master instead of a personal repo, and we were discussing a transition to gitlab. I also seem to remember that the gitlab doesn't allow force pushes (unless you're a repo owner?), which are a requirement for a staging/proposed branch. I'd rather not move it at this point since that would require changing all of our CI automation to match that new repo, but if we can force-push I'd be happy to put future staging branches in the main mesa repo. 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] [ANNOUNCE] Mesa 18.1.2 release candidate
On Fri, 2018-06-15 at 09:36 -0700, Dylan Baker wrote: > Quoting Juan A. Suarez Romero (2018-06-15 07:26:18) > > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > > > Hello list, > > > > > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > > > > > - 42 queued > > > > > - 6 nominated (outstanding) > > > > > - and 0 rejected patches > > > > > > > > > > Notable changes in this release: > > > > > - numerous fixes for radv > > > > > - libatomic checks for meson, as well as fixing coverage for less > > > > > common (not > > > > > arm or x86) platforms > > > > > - lots of common Intel fixes > > > > > - GLX fixes > > > > > - tarball fixes for android > > > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > > > > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > > > > > > > Testing reports/general approval > > > > > > > > > > Any testing reports (or general approval of the state of the branch) > > > > > will be > > > > > greatly appreciated. > > > > > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly > > > > > after 10 > > > > > AM PDT. > > > > > > > > June 15th? > > > > > > Yes, June 15th. > > > > > > Apparently being woken up at 5AM does more brain damage than I thought. > > > > Also, we usually wait 48h (two days) between the pre-announcement and the > > final > > release, to give more time for testing. > > > > > > J.A. > > > > I don't even understand why we make these announcements TBH. I have a public > 18.1-proposed branch that I push to *every weekday*. Out of curiosity, any reason to keep the proposed branch in your personal repository, instead of in main Mesa repo? I thought the proposal was to have those proposed/wip branches in the main repository, so everybody is aware were they are, no matter who is in charge of the release. J.A. > Anyone can pull that branch > *anytime* to get the latest version. The only thing the announce email really > serves AFAICT, is to say "the staging/proposed branch has been merged to the > release branch". I don't think that's all that interesting TBH. > > Dylan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Mon, 2018-06-18 at 09:56 -0700, Dylan Baker wrote: > Quoting Juan A. Suarez Romero (2018-06-18 00:22:02) > > On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote: > > > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote: > > > > I don't even understand why we make these announcements TBH. I have a > > > > public > > > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull > > > > that branch > > > > *anytime* to get the latest version. The only thing the announce email > > > > really > > > > serves AFAICT, is to say "the staging/proposed branch has been merged > > > > to the > > > > release branch". I don't think that's all that interesting TBH. > > > > > > "any time" means "no time". The announcement is "speak now or forever > > > hold your peace". Gives driver teams a chance to review the list and > > > test things out before they go out into a full release. Should they be > > > doing this daily/continuously? Probably. But that's not the current > > > state. > > > > > > > I agree on this. And I think the reason to wait 48h is to give time enough > > for > > teams to do proper testing, specially when there are many timezones that > > people > > get the pre-announcement several hours later. > > > > > > But, I also think that the pre-announcement is too much verbose. It > > includes lot > > of information that can be easily get from the git branch itself. The only > > thing > > I would probably keep is about trivial conflicts, sending an explicit email > > to > > the authors to say "I [slightly] changed your commit; please, take a look > > just > > in case", and the rejected patch list, also mailing the authors. > > I follow up with authors about changes immediately. If it was rejected I reply > to the original patch letting them know I'm not planning to pull the commit > and > why. If there's conflicts I ask the original author to look at the changes > I've > made before pulling them into the staging branch. It feels much too late to be > asking someone to do that when the release is happening shortly. > Yeah, you're right. Actually I do exactly the same, that's why I said "would probably keep". But as you said, once the affected authors are notified, everyone else can know about rejected/fixed conflicts just taking a look at the list of commits. So we could remove that from the pre-announcement. J.A. > Dylan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Juan A. Suarez Romero (2018-06-18 00:22:02) > On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote: > > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote: > > > I don't even understand why we make these announcements TBH. I have a > > > public > > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that > > > branch > > > *anytime* to get the latest version. The only thing the announce email > > > really > > > serves AFAICT, is to say "the staging/proposed branch has been merged to > > > the > > > release branch". I don't think that's all that interesting TBH. > > > > "any time" means "no time". The announcement is "speak now or forever > > hold your peace". Gives driver teams a chance to review the list and > > test things out before they go out into a full release. Should they be > > doing this daily/continuously? Probably. But that's not the current > > state. > > > > I agree on this. And I think the reason to wait 48h is to give time enough for > teams to do proper testing, specially when there are many timezones that > people > get the pre-announcement several hours later. > > > But, I also think that the pre-announcement is too much verbose. It includes > lot > of information that can be easily get from the git branch itself. The only > thing > I would probably keep is about trivial conflicts, sending an explicit email to > the authors to say "I [slightly] changed your commit; please, take a look just > in case", and the rejected patch list, also mailing the authors. I follow up with authors about changes immediately. If it was rejected I reply to the original patch letting them know I'm not planning to pull the commit and why. If there's conflicts I ask the original author to look at the changes I've made before pulling them into the staging branch. It feels much too late to be asking someone to do that when the release is happening shortly. 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] [ANNOUNCE] Mesa 18.1.2 release candidate
On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote: > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote: > > I don't even understand why we make these announcements TBH. I have a public > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that > > branch > > *anytime* to get the latest version. The only thing the announce email > > really > > serves AFAICT, is to say "the staging/proposed branch has been merged to the > > release branch". I don't think that's all that interesting TBH. > > "any time" means "no time". The announcement is "speak now or forever > hold your peace". Gives driver teams a chance to review the list and > test things out before they go out into a full release. Should they be > doing this daily/continuously? Probably. But that's not the current > state. > I agree on this. And I think the reason to wait 48h is to give time enough for teams to do proper testing, specially when there are many timezones that people get the pre-announcement several hours later. But, I also think that the pre-announcement is too much verbose. It includes lot of information that can be easily get from the git branch itself. The only thing I would probably keep is about trivial conflicts, sending an explicit email to the authors to say "I [slightly] changed your commit; please, take a look just in case", and the rejected patch list, also mailing the authors. J.A. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker wrote: > I don't even understand why we make these announcements TBH. I have a public > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that > branch > *anytime* to get the latest version. The only thing the announce email really > serves AFAICT, is to say "the staging/proposed branch has been merged to the > release branch". I don't think that's all that interesting TBH. "any time" means "no time". The announcement is "speak now or forever hold your peace". Gives driver teams a chance to review the list and test things out before they go out into a full release. Should they be doing this daily/continuously? Probably. But that's not the current state. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Juan A. Suarez Romero (2018-06-15 07:26:18) > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > > Hello list, > > > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > > > > - 42 queued > > > > - 6 nominated (outstanding) > > > > - and 0 rejected patches > > > > > > > > Notable changes in this release: > > > > - numerous fixes for radv > > > > - libatomic checks for meson, as well as fixing coverage for less > > > > common (not > > > > arm or x86) platforms > > > > - lots of common Intel fixes > > > > - GLX fixes > > > > - tarball fixes for android > > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > > > > Testing reports/general approval > > > > > > > > Any testing reports (or general approval of the state of the branch) > > > > will be > > > > greatly appreciated. > > > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly > > > > after 10 > > > > AM PDT. > > > > > > June 15th? > > > > Yes, June 15th. > > > > Apparently being woken up at 5AM does more brain damage than I thought. > > Also, we usually wait 48h (two days) between the pre-announcement and the > final > release, to give more time for testing. > > > J.A. > I don't even understand why we make these announcements TBH. I have a public 18.1-proposed branch that I push to *every weekday*. Anyone can pull that branch *anytime* to get the latest version. The only thing the announce email really serves AFAICT, is to say "the staging/proposed branch has been merged to the release branch". I don't think that's all that interesting TBH. 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] [ANNOUNCE] Mesa 18.1.2 release candidate
On 15 June 2018 at 15:26, Juan A. Suarez Romero wrote: > On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: >> Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) >> > On Thu, Jun 14, 2018 at 6:13 PM, wrote: >> > > Hello list, >> > > >> > > The candidate for the Mesa 18.1.2 is now available. Currently we have: >> > > - 42 queued >> > > - 6 nominated (outstanding) >> > > - and 0 rejected patches >> > > >> > > Notable changes in this release: >> > > - numerous fixes for radv >> > > - libatomic checks for meson, as well as fixing coverage for less common >> > > (not >> > > arm or x86) platforms >> > > - lots of common Intel fixes >> > > - GLX fixes >> > > - tarball fixes for android >> > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile >> > > >> > > Take a look at section "Mesa stable queue" for more information. >> > > >> > > >> > > Testing reports/general approval >> > > >> > > Any testing reports (or general approval of the state of the branch) >> > > will be >> > > greatly appreciated. >> > > >> > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly >> > > after 10 >> > > AM PDT. >> > >> > June 15th? >> >> Yes, June 15th. >> >> Apparently being woken up at 5AM does more brain damage than I thought. > > Also, we usually wait 48h (two days) between the pre-announcement and the > final > release, to give more time for testing. > Agreed. Sadly some people don't have the automation the Intel team does, so things may take some time. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [ANNOUNCE] Mesa 18.1.2 release candidate
On Thu, 2018-06-14 at 10:16 -0700, Dylan Baker wrote: > Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > > Hello list, > > > > > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > > > - 42 queued > > > - 6 nominated (outstanding) > > > - and 0 rejected patches > > > > > > Notable changes in this release: > > > - numerous fixes for radv > > > - libatomic checks for meson, as well as fixing coverage for less common > > > (not > > > arm or x86) platforms > > > - lots of common Intel fixes > > > - GLX fixes > > > - tarball fixes for android > > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > > > > Testing reports/general approval > > > > > > Any testing reports (or general approval of the state of the branch) will > > > be > > > greatly appreciated. > > > > > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly > > > after 10 > > > AM PDT. > > > > June 15th? > > Yes, June 15th. > > Apparently being woken up at 5AM does more brain damage than I thought. Also, we usually wait 48h (two days) between the pre-announcement and the final release, to give more time for testing. J.A. > > Dylan > ___ > 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] [ANNOUNCE] Mesa 18.1.2 release candidate
Quoting Bas Nieuwenhuizen (2018-06-14 09:21:49) > On Thu, Jun 14, 2018 at 6:13 PM, wrote: > > Hello list, > > > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > > - 42 queued > > - 6 nominated (outstanding) > > - and 0 rejected patches > > > > Notable changes in this release: > > - numerous fixes for radv > > - libatomic checks for meson, as well as fixing coverage for less common > > (not > > arm or x86) platforms > > - lots of common Intel fixes > > - GLX fixes > > - tarball fixes for android > > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > > > Take a look at section "Mesa stable queue" for more information. > > > > > > Testing reports/general approval > > > > Any testing reports (or general approval of the state of the branch) will be > > greatly appreciated. > > > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly after > > 10 > > AM PDT. > > June 15th? Yes, June 15th. Apparently being woken up at 5AM does more brain damage than I thought. 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] [ANNOUNCE] Mesa 18.1.2 release candidate
On Thu, Jun 14, 2018 at 6:13 PM, wrote: > Hello list, > > The candidate for the Mesa 18.1.2 is now available. Currently we have: > - 42 queued > - 6 nominated (outstanding) > - and 0 rejected patches > > Notable changes in this release: > - numerous fixes for radv > - libatomic checks for meson, as well as fixing coverage for less common (not > arm or x86) platforms > - lots of common Intel fixes > - GLX fixes > - tarball fixes for android > - meson assembly fixes for x86 when doing an x86 -> x86 cross compile > > Take a look at section "Mesa stable queue" for more information. > > > Testing reports/general approval > > Any testing reports (or general approval of the state of the branch) will be > greatly appreciated. > > The plan is to have 18.1.2 this Friday (June 13th), around or shortly after 10 > AM PDT. June 15th? > > If you have any questions or suggestions - be that about the current patch > queue or otherwise, please go ahead. > > > Mesa stable queue > - > > Nominated (6) > == > > Bas Nieuwenhuizen (1): > radv: Fix output for sparse MRTs. > > Dave Airlie (1): > glsl: allow standalone semicolons outside main() > > Marek Olšák (2): > radeonsi/gfx9: fix si_get_buffer_from_descriptors for 48-bit pointers > ac/gpu_info: report real total memory sizes > > Samuel Pitoiset (2): > radv: don't fast clear HTILE for 16-bit depth surfaces on GFX8 > radv: update the ZRANGE_PRECISION value for the TC-compat bug > > > Queued (42) > === > > Alex Smith (4): > radv: Consolidate GFX9 merged shader lookup logic > radv: Handle GFX9 merged shaders in radv_flush_constants() > radeonsi: Fix crash on shaders using MSAA image load/store > radv: Set active_stages the same whether or not shaders were cached > > Andrew Galante (2): > meson: Test for __atomic_add_fetch in atomic checks > configure.ac: Test for __atomic_add_fetch in atomic checks > > Bas Nieuwenhuizen (1): > radv: Don't pass a TESS_EVAL shader when tesselation is not enabled. > > Cameron Kumar (1): > vulkan/wsi: Destroy swapchain images after terminating FIFO queues > > Dylan Baker (5): > docs/relnotes: Add sha256 sums for mesa 18.1.1 > cherry-ignore: add commits not to pull > cherry-ignore: Add patches from Jason that he rebased on 18.1 > meson: work around gentoo applying -m32 to host compiler in cross builds > cherry-ignore: Add another patch > > Eric Engestrom (3): > autotools: add missing android file to package > configure: radv depends on mako > i965: fix resource leak > > Jason Ekstrand (10): > intel/eu: Add some brw_get_default_ helpers > intel/eu: Copy fields manually in brw_next_insn > intel/eu: Set flag [sub]register number differently for 3src > intel/blorp: Don't vertex fetch directly from clear values > intel/isl: Add bounds-checking assertions in isl_format_get_layout > intel/isl: Add bounds-checking assertions for the format_info table > i965/screen: Refactor query_dma_buf_formats > i965/screen: Use RGBA non-sRGB formats for images > anv: Set fence/semaphore types to NONE in impl_cleanup > i965/screen: Return false for unsupported formats in query_modifiers > > Jordan Justen (1): > mesa/program_binary: add implicit UseProgram after successful > ProgramBinary > > Juan A. Suarez Romero (1): > glsl: Add ir_binop_vector_extract in NIR > > Kenneth Graunke (2): > i965: Fix batch-last mode to properly swap BOs. > anv: Disable __gen_validate_value if NDEBUG is set. > > Marek Olšák (1): > r300g/swtcl: make pipe_context uploaders use malloc'd memory as before > > Matt Turner (1): > meson: Fix -latomic check > > Michel Dänzer (1): > glx: Fix number of property values to read in glXImportContextEXT > > Nicolas Boichat (1): > configure.ac/meson.build: Fix -latomic test > > Philip Rebohle (1): > radv: Use correct color format for fast clears > > Samuel Pitoiset (3): > radv: fix a GPU hang when MRTs are sparse > radv: fix missing ZRANGE_PRECISION(1) for GFX9+ > radv: add a workaround for DXVK hangs by setting amdgpu-skip-threshold > > Scott D Phillips (1): > intel/tools: add intel_sanitize_gpu to EXTRA_DIST > > Thomas Petazzoni (1): > configure.ac: rework -latomic check > > Timothy Arceri (2): > ac: fix possible truncation of intrinsic name > radeonsi: fix possible truncation on renderer string > > ___ > 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] [ANNOUNCE] Mesa 18.1.2 release candidate
Hello list, The candidate for the Mesa 18.1.2 is now available. Currently we have: - 42 queued - 6 nominated (outstanding) - and 0 rejected patches Notable changes in this release: - numerous fixes for radv - libatomic checks for meson, as well as fixing coverage for less common (not arm or x86) platforms - lots of common Intel fixes - GLX fixes - tarball fixes for android - meson assembly fixes for x86 when doing an x86 -> x86 cross compile Take a look at section "Mesa stable queue" for more information. Testing reports/general approval Any testing reports (or general approval of the state of the branch) will be greatly appreciated. The plan is to have 18.1.2 this Friday (June 13th), around or shortly after 10 AM PDT. If you have any questions or suggestions - be that about the current patch queue or otherwise, please go ahead. Mesa stable queue - Nominated (6) == Bas Nieuwenhuizen (1): radv: Fix output for sparse MRTs. Dave Airlie (1): glsl: allow standalone semicolons outside main() Marek Olšák (2): radeonsi/gfx9: fix si_get_buffer_from_descriptors for 48-bit pointers ac/gpu_info: report real total memory sizes Samuel Pitoiset (2): radv: don't fast clear HTILE for 16-bit depth surfaces on GFX8 radv: update the ZRANGE_PRECISION value for the TC-compat bug Queued (42) === Alex Smith (4): radv: Consolidate GFX9 merged shader lookup logic radv: Handle GFX9 merged shaders in radv_flush_constants() radeonsi: Fix crash on shaders using MSAA image load/store radv: Set active_stages the same whether or not shaders were cached Andrew Galante (2): meson: Test for __atomic_add_fetch in atomic checks configure.ac: Test for __atomic_add_fetch in atomic checks Bas Nieuwenhuizen (1): radv: Don't pass a TESS_EVAL shader when tesselation is not enabled. Cameron Kumar (1): vulkan/wsi: Destroy swapchain images after terminating FIFO queues Dylan Baker (5): docs/relnotes: Add sha256 sums for mesa 18.1.1 cherry-ignore: add commits not to pull cherry-ignore: Add patches from Jason that he rebased on 18.1 meson: work around gentoo applying -m32 to host compiler in cross builds cherry-ignore: Add another patch Eric Engestrom (3): autotools: add missing android file to package configure: radv depends on mako i965: fix resource leak Jason Ekstrand (10): intel/eu: Add some brw_get_default_ helpers intel/eu: Copy fields manually in brw_next_insn intel/eu: Set flag [sub]register number differently for 3src intel/blorp: Don't vertex fetch directly from clear values intel/isl: Add bounds-checking assertions in isl_format_get_layout intel/isl: Add bounds-checking assertions for the format_info table i965/screen: Refactor query_dma_buf_formats i965/screen: Use RGBA non-sRGB formats for images anv: Set fence/semaphore types to NONE in impl_cleanup i965/screen: Return false for unsupported formats in query_modifiers Jordan Justen (1): mesa/program_binary: add implicit UseProgram after successful ProgramBinary Juan A. Suarez Romero (1): glsl: Add ir_binop_vector_extract in NIR Kenneth Graunke (2): i965: Fix batch-last mode to properly swap BOs. anv: Disable __gen_validate_value if NDEBUG is set. Marek Olšák (1): r300g/swtcl: make pipe_context uploaders use malloc'd memory as before Matt Turner (1): meson: Fix -latomic check Michel Dänzer (1): glx: Fix number of property values to read in glXImportContextEXT Nicolas Boichat (1): configure.ac/meson.build: Fix -latomic test Philip Rebohle (1): radv: Use correct color format for fast clears Samuel Pitoiset (3): radv: fix a GPU hang when MRTs are sparse radv: fix missing ZRANGE_PRECISION(1) for GFX9+ radv: add a workaround for DXVK hangs by setting amdgpu-skip-threshold Scott D Phillips (1): intel/tools: add intel_sanitize_gpu to EXTRA_DIST Thomas Petazzoni (1): configure.ac: rework -latomic check Timothy Arceri (2): ac: fix possible truncation of intrinsic name radeonsi: fix possible truncation on renderer string signature.asc Description: signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
