Re: [Mesa-dev] Stable release process

[Daniel Stone]

Hey Marek,

On 18 November 2016 at 19:09, Marek Olšák  wrote:
> On Fri, Nov 18, 2016 at 7:45 PM, Kai Wasserbäch
>  wrote:
>> wouldn't a tool like Phabricator be much better for reviewing and reliably
>> tracking whether a patch has landed or not? Especially if you use it in
>> combination with Arcanist? While I'm certainly not a core developer, I find
>> patchwork clunky. Sometimes it doesn't pick up R-bs or doesn't recognise 
>> series,
>> which makes seeing the actual state of a patch a bit tricky from time to 
>> time.
>>
>> In addition you would get things like automatically closure of bugs, nice
>> referencing features and lots of other nice features. And AFAIK 
>> freedesktop.org
>> already has a Phabricator instance, which could be used.
>
> OK, off topic we go.
>
> I have some experience with Phabricator and Arcanist from LLVM and
> it's not very good.
>
> Phabricator (or Arcanist) doesn't support patch series. You can only
> submit one patch, or a range of commits as one patch (which is pretty
> bad - why would anyone on Earth want to do that). It also doesn't
> support downloading patches in the mbox format (only plain diffs).
> Based on that, I don't recommend it.

Off-topic indeed. Arcanist is crippled, as you say, and I don't like
its UI. But git-phab does exist to let you attach patch series, e.g.
https://phabricator.freedesktop.org/T7573 contains a load.

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

Re: [Mesa-dev] Stable release process

[Marek Olšák]

On Fri, Nov 18, 2016 at 7:45 PM, Kai Wasserbäch
 wrote:
> Hi everybody,
> Nicolai Hähnle wrote on 18.11.2016 17:48:
>> On 18.11.2016 16:56, Emil Velikov wrote:
>>> On 18 November 2016 at 12:34, Marek Olšák  wrote:
 On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov  
 wrote:
 [...]
> Speaking of patchwork, mostly I'm fine with it. There are some
> "drawbacks" though:
>  - some duplicated time will be spent tagging "self-rejected" patches.
> I already track these based from the mailing list.
>  - it doesn't parse "Pick commit $sha, it addresses $issue"
> nominations, so it cannot substitute/replace the mailing list.
> In case my first point brought some "don't bother with the ML" type of
> thoughts.
>  - you don't seem to be using it [1] so I'm not sure of the sudden 
> interest.

 Patchwork can't clear any of my patches on git push. That's normal. I
 do use Patchwork for reviewing patches though.

>>> Seems to work fairly well here. Admittedly I have way less (and
>>> smaller) patches...
>>
>> Patchwork is pretty dumb about how it compares patches. If you have 
>> non-standard
>> git diff settings (e.g. more lines of context), it will never recognize a 
>> patch.
>
> wouldn't a tool like Phabricator be much better for reviewing and reliably
> tracking whether a patch has landed or not? Especially if you use it in
> combination with Arcanist? While I'm certainly not a core developer, I find
> patchwork clunky. Sometimes it doesn't pick up R-bs or doesn't recognise 
> series,
> which makes seeing the actual state of a patch a bit tricky from time to time.
>
> In addition you would get things like automatically closure of bugs, nice
> referencing features and lots of other nice features. And AFAIK 
> freedesktop.org
> already has a Phabricator instance, which could be used.

OK, off topic we go.

I have some experience with Phabricator and Arcanist from LLVM and
it's not very good.

Phabricator (or Arcanist) doesn't support patch series. You can only
submit one patch, or a range of commits as one patch (which is pretty
bad - why would anyone on Earth want to do that). It also doesn't
support downloading patches in the mbox format (only plain diffs).
Based on that, I don't recommend it.

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

Re: [Mesa-dev] Stable release process

[Marek Olšák]

On Fri, Nov 18, 2016 at 4:56 PM, Emil Velikov  wrote:
> On 18 November 2016 at 12:34, Marek Olšák  wrote:
>> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov  
>> wrote:
>>> On 17 November 2016 at 23:42, Marek Olšák  wrote:
 On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov  
 wrote:
> On 15 November 2016 at 16:57, Marek Olšák  wrote:
>> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  
>> wrote:
>>> On 15 November 2016 at 16:13, Marek Olšák  wrote:
 I think that if people add the Cc stable tag to patches that are going
 to land in master first, they shouldn't send it to the stable ML,
 because that is redundant. Yet, many people do that. I would go even
 further and say that any unreviewed patches shouldn't be sent to the
 stable ML. At least that would be my policy I were the release
 manager.

>>> Since I'm no longer tracking nominated-but-not-merged-in-master
>>> patches things are noticeably better.
>>
>> What about patches in mesa-stable that can't be merged to master,
>> because master needs to be fixed differently? Will you then apply the
>> patches from mesa-stable or ignore them?
>>
>> Based on experience, it looks like you ignore them completely, which
>> is why many fixes that I sent for inclusion to stable branches only
>> (not master) have never been applied. This process needs to be fixed.
>>
> Trivial patches are addressed, others are pinged. Trivial dependencies
> are picked, non-trivial ones invalidate the nominated patch.
> Backports are always appreciated - there's been a few from yourself,
> Ilia and others.
>
> One example/snippet from the 12.0.x pre-release announcement.
> "
>   f240ad9 st/mesa: unduplicate st_check_sync code
>   b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>
> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
> fence_finish") which is gallium API change.
> "
> Here the original nominations are invalidated, and from a quick look
> even if we do pick the dependency things won't work [as expected]
> since zero drivers hadnle the pipe_ctx this will need to add support
> (read: not bugfix, but implement).
>
> In all fairness if sounds like things are unclear rather than anything
> else. I believe with the documentation (and above) things are better
> now ?

 That's all nice, but it's mostly irrelevant to what I was saying.

 We need Patchwork for mesa-stable, so that patches don't get lost.

>>> Ok let me be perfectly clear.
>>>
>>> Nearly all the missed patches (many of those sent by you) do _not_
>>> follow the -stable submission rules. I've been polite and picked those
>>> _despite_ that fact and yes some have been missed.
>>> Regardless of patchwork I would _strongly_ suggest that you stay
>>> consistent (you do it right most of the time) and nominate patches
>>> properly!
>>
>> The last one was nominated properly, and ignored.
> As mentioned in private that was due to bug on my end as I was working
> on improving the workflow.
> Please don't everything under the same nominator.

OK.

>
>>>
>>> Speaking of patchwork, mostly I'm fine with it. There are some
>>> "drawbacks" though:
>>>  - some duplicated time will be spent tagging "self-rejected" patches.
>>> I already track these based from the mailing list.
>>>  - it doesn't parse "Pick commit $sha, it addresses $issue"
>>> nominations, so it cannot substitute/replace the mailing list.
>>> In case my first point brought some "don't bother with the ML" type of 
>>> thoughts.
>>>  - you don't seem to be using it [1] so I'm not sure of the sudden interest.
>>
>> Patchwork can't clear any of my patches on git push. That's normal. I
>> do use Patchwork for reviewing patches though.
>>
> Seems to work fairly well here. Admittedly I have way less (and
> smaller) patches...
>
> Please elaborate a bit on "We need Patchwork for mesa-stable, so that
> patches don't get lost."

I thought Patchwork would help us to prevent losing patches. If you
have a different (just as good) process in place already, Patchwork is
not necessary.

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

Re: [Mesa-dev] Stable release process

[Nicolai Hähnle]

On 18.11.2016 16:56, Emil Velikov wrote:

On 18 November 2016 at 12:34, Marek Olšák  wrote:

On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov  wrote:

On 17 November 2016 at 23:42, Marek Olšák  wrote:

On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov  wrote:

On 15 November 2016 at 16:57, Marek Olšák  wrote:

On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  wrote:

On 15 November 2016 at 16:13, Marek Olšák  wrote:

I think that if people add the Cc stable tag to patches that are going
to land in master first, they shouldn't send it to the stable ML,
because that is redundant. Yet, many people do that. I would go even
further and say that any unreviewed patches shouldn't be sent to the
stable ML. At least that would be my policy I were the release
manager.


Since I'm no longer tracking nominated-but-not-merged-in-master
patches things are noticeably better.


What about patches in mesa-stable that can't be merged to master,
because master needs to be fixed differently? Will you then apply the
patches from mesa-stable or ignore them?

Based on experience, it looks like you ignore them completely, which
is why many fixes that I sent for inclusion to stable branches only
(not master) have never been applied. This process needs to be fixed.


Trivial patches are addressed, others are pinged. Trivial dependencies
are picked, non-trivial ones invalidate the nominated patch.
Backports are always appreciated - there's been a few from yourself,
Ilia and others.

One example/snippet from the 12.0.x pre-release announcement.
"
  f240ad9 st/mesa: unduplicate st_check_sync code
  b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync

Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
fence_finish") which is gallium API change.
"
Here the original nominations are invalidated, and from a quick look
even if we do pick the dependency things won't work [as expected]
since zero drivers hadnle the pipe_ctx this will need to add support
(read: not bugfix, but implement).

In all fairness if sounds like things are unclear rather than anything
else. I believe with the documentation (and above) things are better
now ?


That's all nice, but it's mostly irrelevant to what I was saying.

We need Patchwork for mesa-stable, so that patches don't get lost.


Ok let me be perfectly clear.

Nearly all the missed patches (many of those sent by you) do _not_
follow the -stable submission rules. I've been polite and picked those
_despite_ that fact and yes some have been missed.
Regardless of patchwork I would _strongly_ suggest that you stay
consistent (you do it right most of the time) and nominate patches
properly!


The last one was nominated properly, and ignored.

As mentioned in private that was due to bug on my end as I was working
on improving the workflow.
Please don't everything under the same nominator.



Speaking of patchwork, mostly I'm fine with it. There are some
"drawbacks" though:
 - some duplicated time will be spent tagging "self-rejected" patches.
I already track these based from the mailing list.
 - it doesn't parse "Pick commit $sha, it addresses $issue"
nominations, so it cannot substitute/replace the mailing list.
In case my first point brought some "don't bother with the ML" type of thoughts.
 - you don't seem to be using it [1] so I'm not sure of the sudden interest.


Patchwork can't clear any of my patches on git push. That's normal. I
do use Patchwork for reviewing patches though.


Seems to work fairly well here. Admittedly I have way less (and
smaller) patches...


Patchwork is pretty dumb about how it compares patches. If you have 
non-standard git diff settings (e.g. more lines of context), it will 
never recognize a patch.


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

Re: [Mesa-dev] Stable release process

[Emil Velikov]

On 18 November 2016 at 12:34, Marek Olšák  wrote:
> On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov  
> wrote:
>> On 17 November 2016 at 23:42, Marek Olšák  wrote:
>>> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov  
>>> wrote:
 On 15 November 2016 at 16:57, Marek Olšák  wrote:
> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  
> wrote:
>> On 15 November 2016 at 16:13, Marek Olšák  wrote:
>>> I think that if people add the Cc stable tag to patches that are going
>>> to land in master first, they shouldn't send it to the stable ML,
>>> because that is redundant. Yet, many people do that. I would go even
>>> further and say that any unreviewed patches shouldn't be sent to the
>>> stable ML. At least that would be my policy I were the release
>>> manager.
>>>
>> Since I'm no longer tracking nominated-but-not-merged-in-master
>> patches things are noticeably better.
>
> What about patches in mesa-stable that can't be merged to master,
> because master needs to be fixed differently? Will you then apply the
> patches from mesa-stable or ignore them?
>
> Based on experience, it looks like you ignore them completely, which
> is why many fixes that I sent for inclusion to stable branches only
> (not master) have never been applied. This process needs to be fixed.
>
 Trivial patches are addressed, others are pinged. Trivial dependencies
 are picked, non-trivial ones invalidate the nominated patch.
 Backports are always appreciated - there's been a few from yourself,
 Ilia and others.

 One example/snippet from the 12.0.x pre-release announcement.
 "
   f240ad9 st/mesa: unduplicate st_check_sync code
   b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync

 Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
 fence_finish") which is gallium API change.
 "
 Here the original nominations are invalidated, and from a quick look
 even if we do pick the dependency things won't work [as expected]
 since zero drivers hadnle the pipe_ctx this will need to add support
 (read: not bugfix, but implement).

 In all fairness if sounds like things are unclear rather than anything
 else. I believe with the documentation (and above) things are better
 now ?
>>>
>>> That's all nice, but it's mostly irrelevant to what I was saying.
>>>
>>> We need Patchwork for mesa-stable, so that patches don't get lost.
>>>
>> Ok let me be perfectly clear.
>>
>> Nearly all the missed patches (many of those sent by you) do _not_
>> follow the -stable submission rules. I've been polite and picked those
>> _despite_ that fact and yes some have been missed.
>> Regardless of patchwork I would _strongly_ suggest that you stay
>> consistent (you do it right most of the time) and nominate patches
>> properly!
>
> The last one was nominated properly, and ignored.
As mentioned in private that was due to bug on my end as I was working
on improving the workflow.
Please don't everything under the same nominator.

>>
>> Speaking of patchwork, mostly I'm fine with it. There are some
>> "drawbacks" though:
>>  - some duplicated time will be spent tagging "self-rejected" patches.
>> I already track these based from the mailing list.
>>  - it doesn't parse "Pick commit $sha, it addresses $issue"
>> nominations, so it cannot substitute/replace the mailing list.
>> In case my first point brought some "don't bother with the ML" type of 
>> thoughts.
>>  - you don't seem to be using it [1] so I'm not sure of the sudden interest.
>
> Patchwork can't clear any of my patches on git push. That's normal. I
> do use Patchwork for reviewing patches though.
>
Seems to work fairly well here. Admittedly I have way less (and
smaller) patches...

Please elaborate a bit on "We need Patchwork for mesa-stable, so that
patches don't get lost."
How you plan to use it to track/other. Can we get a clear
idea/understanding your workflow/expectations so that things work
better for all of us ?

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

Re: [Mesa-dev] Stable release process

[Marek Olšák]

On Fri, Nov 18, 2016 at 12:49 PM, Emil Velikov  wrote:
> On 17 November 2016 at 23:42, Marek Olšák  wrote:
>> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov  
>> wrote:
>>> On 15 November 2016 at 16:57, Marek Olšák  wrote:
 On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  
 wrote:
> On 15 November 2016 at 16:13, Marek Olšák  wrote:
>> I think that if people add the Cc stable tag to patches that are going
>> to land in master first, they shouldn't send it to the stable ML,
>> because that is redundant. Yet, many people do that. I would go even
>> further and say that any unreviewed patches shouldn't be sent to the
>> stable ML. At least that would be my policy I were the release
>> manager.
>>
> Since I'm no longer tracking nominated-but-not-merged-in-master
> patches things are noticeably better.

 What about patches in mesa-stable that can't be merged to master,
 because master needs to be fixed differently? Will you then apply the
 patches from mesa-stable or ignore them?

 Based on experience, it looks like you ignore them completely, which
 is why many fixes that I sent for inclusion to stable branches only
 (not master) have never been applied. This process needs to be fixed.

>>> Trivial patches are addressed, others are pinged. Trivial dependencies
>>> are picked, non-trivial ones invalidate the nominated patch.
>>> Backports are always appreciated - there's been a few from yourself,
>>> Ilia and others.
>>>
>>> One example/snippet from the 12.0.x pre-release announcement.
>>> "
>>>   f240ad9 st/mesa: unduplicate st_check_sync code
>>>   b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>>>
>>> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
>>> fence_finish") which is gallium API change.
>>> "
>>> Here the original nominations are invalidated, and from a quick look
>>> even if we do pick the dependency things won't work [as expected]
>>> since zero drivers hadnle the pipe_ctx this will need to add support
>>> (read: not bugfix, but implement).
>>>
>>> In all fairness if sounds like things are unclear rather than anything
>>> else. I believe with the documentation (and above) things are better
>>> now ?
>>
>> That's all nice, but it's mostly irrelevant to what I was saying.
>>
>> We need Patchwork for mesa-stable, so that patches don't get lost.
>>
> Ok let me be perfectly clear.
>
> Nearly all the missed patches (many of those sent by you) do _not_
> follow the -stable submission rules. I've been polite and picked those
> _despite_ that fact and yes some have been missed.
> Regardless of patchwork I would _strongly_ suggest that you stay
> consistent (you do it right most of the time) and nominate patches
> properly!

The last one was nominated properly, and ignored. It didn't mention
anything about the app it was fixing, but I couldn't tell you that
anyway - it was for an app that hadn't even been released for Linux.
So yeah, nominations not mentioning fixed apps or bugzilla should be
expected and accepted.

>
> Speaking of patchwork, mostly I'm fine with it. There are some
> "drawbacks" though:
>  - some duplicated time will be spent tagging "self-rejected" patches.
> I already track these based from the mailing list.
>  - it doesn't parse "Pick commit $sha, it addresses $issue"
> nominations, so it cannot substitute/replace the mailing list.
> In case my first point brought some "don't bother with the ML" type of 
> thoughts.
>  - you don't seem to be using it [1] so I'm not sure of the sudden interest.

Patchwork can't clear any of my patches on git push. That's normal. I
do use Patchwork for reviewing patches though.

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

Re: [Mesa-dev] Stable release process

[Emil Velikov]

On 17 November 2016 at 23:42, Marek Olšák  wrote:
> On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov  
> wrote:
>> On 15 November 2016 at 16:57, Marek Olšák  wrote:
>>> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  
>>> wrote:
 On 15 November 2016 at 16:13, Marek Olšák  wrote:
> I think that if people add the Cc stable tag to patches that are going
> to land in master first, they shouldn't send it to the stable ML,
> because that is redundant. Yet, many people do that. I would go even
> further and say that any unreviewed patches shouldn't be sent to the
> stable ML. At least that would be my policy I were the release
> manager.
>
 Since I'm no longer tracking nominated-but-not-merged-in-master
 patches things are noticeably better.
>>>
>>> What about patches in mesa-stable that can't be merged to master,
>>> because master needs to be fixed differently? Will you then apply the
>>> patches from mesa-stable or ignore them?
>>>
>>> Based on experience, it looks like you ignore them completely, which
>>> is why many fixes that I sent for inclusion to stable branches only
>>> (not master) have never been applied. This process needs to be fixed.
>>>
>> Trivial patches are addressed, others are pinged. Trivial dependencies
>> are picked, non-trivial ones invalidate the nominated patch.
>> Backports are always appreciated - there's been a few from yourself,
>> Ilia and others.
>>
>> One example/snippet from the 12.0.x pre-release announcement.
>> "
>>   f240ad9 st/mesa: unduplicate st_check_sync code
>>   b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>>
>> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
>> fence_finish") which is gallium API change.
>> "
>> Here the original nominations are invalidated, and from a quick look
>> even if we do pick the dependency things won't work [as expected]
>> since zero drivers hadnle the pipe_ctx this will need to add support
>> (read: not bugfix, but implement).
>>
>> In all fairness if sounds like things are unclear rather than anything
>> else. I believe with the documentation (and above) things are better
>> now ?
>
> That's all nice, but it's mostly irrelevant to what I was saying.
>
> We need Patchwork for mesa-stable, so that patches don't get lost.
>
Ok let me be perfectly clear.

Nearly all the missed patches (many of those sent by you) do _not_
follow the -stable submission rules. I've been polite and picked those
_despite_ that fact and yes some have been missed.
Regardless of patchwork I would _strongly_ suggest that you stay
consistent (you do it right most of the time) and nominate patches
properly!

Speaking of patchwork, mostly I'm fine with it. There are some
"drawbacks" though:
 - some duplicated time will be spent tagging "self-rejected" patches.
I already track these based from the mailing list.
 - it doesn't parse "Pick commit $sha, it addresses $issue"
nominations, so it cannot substitute/replace the mailing list.
In case my first point brought some "don't bother with the ML" type of thoughts.
 - you don't seem to be using it [1] so I'm not sure of the sudden interest.

Thanks
Emil

[1] The following shows ~800 "New" patches for yours ranging back to 2014.
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=11032
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Stable release process

[Marek Olšák]

On Thu, Nov 17, 2016 at 4:06 PM, Emil Velikov  wrote:
> On 15 November 2016 at 16:57, Marek Olšák  wrote:
>> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  
>> wrote:
>>> On 15 November 2016 at 16:13, Marek Olšák  wrote:
 I think that if people add the Cc stable tag to patches that are going
 to land in master first, they shouldn't send it to the stable ML,
 because that is redundant. Yet, many people do that. I would go even
 further and say that any unreviewed patches shouldn't be sent to the
 stable ML. At least that would be my policy I were the release
 manager.

>>> Since I'm no longer tracking nominated-but-not-merged-in-master
>>> patches things are noticeably better.
>>
>> What about patches in mesa-stable that can't be merged to master,
>> because master needs to be fixed differently? Will you then apply the
>> patches from mesa-stable or ignore them?
>>
>> Based on experience, it looks like you ignore them completely, which
>> is why many fixes that I sent for inclusion to stable branches only
>> (not master) have never been applied. This process needs to be fixed.
>>
> Trivial patches are addressed, others are pinged. Trivial dependencies
> are picked, non-trivial ones invalidate the nominated patch.
> Backports are always appreciated - there's been a few from yourself,
> Ilia and others.
>
> One example/snippet from the 12.0.x pre-release announcement.
> "
>   f240ad9 st/mesa: unduplicate st_check_sync code
>   b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync
>
> Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
> fence_finish") which is gallium API change.
> "
> Here the original nominations are invalidated, and from a quick look
> even if we do pick the dependency things won't work [as expected]
> since zero drivers hadnle the pipe_ctx this will need to add support
> (read: not bugfix, but implement).
>
> In all fairness if sounds like things are unclear rather than anything
> else. I believe with the documentation (and above) things are better
> now ?

That's all nice, but it's mostly irrelevant to what I was saying.

We need Patchwork for mesa-stable, so that patches don't get lost.

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

Re: [Mesa-dev] Stable release process

[Emil Velikov]

On 15 November 2016 at 16:57, Marek Olšák  wrote:
> On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  
> wrote:
>> On 15 November 2016 at 16:13, Marek Olšák  wrote:
>>> I think that if people add the Cc stable tag to patches that are going
>>> to land in master first, they shouldn't send it to the stable ML,
>>> because that is redundant. Yet, many people do that. I would go even
>>> further and say that any unreviewed patches shouldn't be sent to the
>>> stable ML. At least that would be my policy I were the release
>>> manager.
>>>
>> Since I'm no longer tracking nominated-but-not-merged-in-master
>> patches things are noticeably better.
>
> What about patches in mesa-stable that can't be merged to master,
> because master needs to be fixed differently? Will you then apply the
> patches from mesa-stable or ignore them?
>
> Based on experience, it looks like you ignore them completely, which
> is why many fixes that I sent for inclusion to stable branches only
> (not master) have never been applied. This process needs to be fixed.
>
Trivial patches are addressed, others are pinged. Trivial dependencies
are picked, non-trivial ones invalidate the nominated patch.
Backports are always appreciated - there's been a few from yourself,
Ilia and others.

One example/snippet from the 12.0.x pre-release announcement.
"
  f240ad9 st/mesa: unduplicate st_check_sync code
  b687f76 st/mesa: allow multiple concurrent waiters in ClientWaitSync

Reason: Depends on 54272e1 ("gallium: add a pipe_context parameter to
fence_finish") which is gallium API change.
"
Here the original nominations are invalidated, and from a quick look
even if we do pick the dependency things won't work [as expected]
since zero drivers hadnle the pipe_ctx this will need to add support
(read: not bugfix, but implement).

In all fairness if sounds like things are unclear rather than anything
else. I believe with the documentation (and above) things are better
now ?
Flashback - sounds similar to the libdrm <> kernel chat we had a while
back ? Where you wanted to "fix" the kernel, rather than resync
libdrm.

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

Re: [Mesa-dev] Stable release process

[Jason Ekstrand]

On Nov 15, 2016 11:07 AM, "Ian Romanick"  wrote:
>
> On 11/14/2016 02:31 PM, Matt Turner wrote:
> > A long time ago, patch authors were tasked with cherry-picking their
> > patches to stable branches. Today we Cc
> > mesa-sta...@lists.freedesktop.org and Emil rebases those patches onto
> > stable. Cc'ing the list happens even on patches sent for their first
> > review that are ultimately rejected, creating a lot of noise (and
> > presumably makes the mailing list less useful).
>
> When we first came up with the process several years ago, we had a
> couple goals that didn't always align.  The top two were:
>
> - Bug fixes shouldn't be missed from stable releases.
>
> - Individual developers shouldn't have to shepherd patches into stable.
>
> Secondary goals:
>
> - Reviewers should know when a fix is destined for stable.
>
> - Fixes that weren't initially marked for stable could be marked later.
>
> Using a separate mailing list seemed to meet all those goals.  Reviewers
> would know a patch was destined for stable due to the Cc.  Once a patch
> landed on master with the Cc, the developer could "forget" about it.  It
> was now in the hands of the stable maintainer.  It would also be easy to
> nominate a patch for stable after it landed on master by just sending it
> to the stable list.
>
> All the things that make it easy to get a patch in the stable queue also
> make it hard to get a patch out.  If a patch is rejected (never lands on
> master), it is still floating on the stable list.  If a patch lands but,
> after the fact, we decide it shouldn't go to stable, it's still tagged
> in the git log (the .cherry-ignore file helps with this).

This sounds a lot like the one thing patchwork is good for.  Would setting
up patchwork for the stable list solve some of these problems?  Then we
would always know what's on it and the stable maintainer would be
responsible for keeping it tidy.  It's not a lot of patches so the burden
wouldn't be large.  It may even make the cherry picking easier.

> > Initial questions:
> >
> > Is the mesa-stable@ mailing list useful (other than as a tag in a
> > committed patch)?
> >
> > What do "nominated" and "queued" in the stable release candidate
> > announcements actually mean?
> >
> > Should driver maintainers cherry-pick patches to stable on their own?
>
> I think there's value in having a single gatekeeper for stable.  It's
> common for bug fixes to touch common code.  The single gatekeeper has a
> responsibility to ensure that other drivers don't break, etc.
>
> There are some things we could try that are somewhere between the
> current system and multiple pushers.  Other projects have a model where
> subsystem maintainers send branches to the next level up maintainer to
> merge.  Something similar to that might work.  We have to be careful
> that we don't pick a system that only works well for AMD and Intel.
>
> > Regardless of the outcome of that question, I think we would the
> > process would be more transparent and predictable if patches were
> > incorporated into the branch over time rather than all at once a few
> > days before the release.
> > ___
> > 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] Stable release process

[Ian Romanick]

On 11/14/2016 02:31 PM, Matt Turner wrote:
> A long time ago, patch authors were tasked with cherry-picking their
> patches to stable branches. Today we Cc
> mesa-sta...@lists.freedesktop.org and Emil rebases those patches onto
> stable. Cc'ing the list happens even on patches sent for their first
> review that are ultimately rejected, creating a lot of noise (and
> presumably makes the mailing list less useful).

When we first came up with the process several years ago, we had a
couple goals that didn't always align.  The top two were:

- Bug fixes shouldn't be missed from stable releases.

- Individual developers shouldn't have to shepherd patches into stable.

Secondary goals:

- Reviewers should know when a fix is destined for stable.

- Fixes that weren't initially marked for stable could be marked later.

Using a separate mailing list seemed to meet all those goals.  Reviewers
would know a patch was destined for stable due to the Cc.  Once a patch
landed on master with the Cc, the developer could "forget" about it.  It
was now in the hands of the stable maintainer.  It would also be easy to
nominate a patch for stable after it landed on master by just sending it
to the stable list.

All the things that make it easy to get a patch in the stable queue also
make it hard to get a patch out.  If a patch is rejected (never lands on
master), it is still floating on the stable list.  If a patch lands but,
after the fact, we decide it shouldn't go to stable, it's still tagged
in the git log (the .cherry-ignore file helps with this).

> Initial questions:
> 
> Is the mesa-stable@ mailing list useful (other than as a tag in a
> committed patch)?
> 
> What do "nominated" and "queued" in the stable release candidate
> announcements actually mean?
> 
> Should driver maintainers cherry-pick patches to stable on their own?

I think there's value in having a single gatekeeper for stable.  It's
common for bug fixes to touch common code.  The single gatekeeper has a
responsibility to ensure that other drivers don't break, etc.

There are some things we could try that are somewhere between the
current system and multiple pushers.  Other projects have a model where
subsystem maintainers send branches to the next level up maintainer to
merge.  Something similar to that might work.  We have to be careful
that we don't pick a system that only works well for AMD and Intel.

> Regardless of the outcome of that question, I think we would the
> process would be more transparent and predictable if patches were
> incorporated into the branch over time rather than all at once a few
> days before the release.
> ___
> 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] Stable release process

[Marek Olšák]

On Tue, Nov 15, 2016 at 5:30 PM, Emil Velikov  wrote:
> On 15 November 2016 at 16:13, Marek Olšák  wrote:
>> I think that if people add the Cc stable tag to patches that are going
>> to land in master first, they shouldn't send it to the stable ML,
>> because that is redundant. Yet, many people do that. I would go even
>> further and say that any unreviewed patches shouldn't be sent to the
>> stable ML. At least that would be my policy I were the release
>> manager.
>>
> Since I'm no longer tracking nominated-but-not-merged-in-master
> patches things are noticeably better.

What about patches in mesa-stable that can't be merged to master,
because master needs to be fixed differently? Will you then apply the
patches from mesa-stable or ignore them?

Based on experience, it looks like you ignore them completely, which
is why many fixes that I sent for inclusion to stable branches only
(not master) have never been applied. This process needs to be fixed.

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

Re: [Mesa-dev] Stable release process

[Emil Velikov]

On 15 November 2016 at 16:13, Marek Olšák  wrote:
> I think that if people add the Cc stable tag to patches that are going
> to land in master first, they shouldn't send it to the stable ML,
> because that is redundant. Yet, many people do that. I would go even
> further and say that any unreviewed patches shouldn't be sent to the
> stable ML. At least that would be my policy I were the release
> manager.
>
Since I'm no longer tracking nominated-but-not-merged-in-master
patches things are noticeably better.

Fwiw the official policy has been to not merge patches without review.
I've bent that rule (and others) on a number of occasions for pretty
much everyone.
I hope that doesn't happen again, but in all fairness it will.
Otherwise we'll get a lot of upset/angry/alienated developers.

> I don't know how Emil manages that ML, but I guess it's not fun.
>
it's "less fun" when one uses a unofficial way to nominate patches - hint, hint.
Again it's my fault for not having things in a clearer and easier to
parse/understand way.

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

Re: [Mesa-dev] Stable release process

[Marek Olšák]

I think that if people add the Cc stable tag to patches that are going
to land in master first, they shouldn't send it to the stable ML,
because that is redundant. Yet, many people do that. I would go even
further and say that any unreviewed patches shouldn't be sent to the
stable ML. At least that would be my policy I were the release
manager.

I don't know how Emil manages that ML, but I guess it's not fun.

Marek


On Mon, Nov 14, 2016 at 11:31 PM, Matt Turner  wrote:
> A long time ago, patch authors were tasked with cherry-picking their
> patches to stable branches. Today we Cc
> mesa-sta...@lists.freedesktop.org and Emil rebases those patches onto
> stable. Cc'ing the list happens even on patches sent for their first
> review that are ultimately rejected, creating a lot of noise (and
> presumably makes the mailing list less useful).
>
> Initial questions:
>
> Is the mesa-stable@ mailing list useful (other than as a tag in a
> committed patch)?
>
> What do "nominated" and "queued" in the stable release candidate
> announcements actually mean?
>
> Should driver maintainers cherry-pick patches to stable on their own?
>
> Regardless of the outcome of that question, I think we would the
> process would be more transparent and predictable if patches were
> incorporated into the branch over time rather than all at once a few
> days before the release.
> ___
> 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] Stable release process

[Emil Velikov]

Hi Matt,

On 14 November 2016 at 22:31, Matt Turner  wrote:
> A long time ago, patch authors were tasked with cherry-picking their
> patches to stable branches. Today we Cc
> mesa-sta...@lists.freedesktop.org and Emil rebases those patches onto
> stable. Cc'ing the list happens even on patches sent for their first
> review that are ultimately rejected, creating a lot of noise (and
> presumably makes the mailing list less useful).
>
I believe it's the increased volume (overall) and off-list decisions
make things a bit confusing. Then again, the latter happens quite
rare, so I don't believe it's an issue.

In the early stages I was going through the mesa-stable@ list for
patches that have fallen through the cracks.
It seemed quite useful, yet people did not had time or just dropped
the ball on patches. My prodding seems to have caused annoyance, so
I've opted against it.

So my question is:
Do people agree with my prodding, should we revive it ?

> Initial questions:
>
> Is the mesa-stable@ mailing list useful (other than as a tag in a
> committed patch)?
>
Yes, mesa-stable is useful. We had a number of fixes that landed
explicitly thanks to it.

> What do "nominated" and "queued" in the stable release candidate
> announcements actually mean?
>
Those terms originated when Carl was around and seems to be commonly
asked topic:
 - Nominated:
Patch that is nominated but yet to to merged in the patch
queue/branch. There are three* ways to nominate a patch, which I'd
imagine can be causing confusion.
 - Queued:
Patch is in the queue/branch and will feature in the next release.
Barring reported regressions objections from developers.

> Should driver maintainers cherry-pick patches to stable on their own?
>
I'd suggest against that where possible.

> Regardless of the outcome of that question, I think we would the
> process would be more transparent and predictable if patches were
> incorporated into the branch over time rather than all at once a few
> days before the release.
Fully, agree. I'm dusting off a series on the topic and will send to
the list by EOD.

Thanks
Emil
* Official ones and one unofficial that people opt for. Latter of
which being the core/sole reason behind "forgotten" patches.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Stable release process

[Matt Turner]

A long time ago, patch authors were tasked with cherry-picking their
patches to stable branches. Today we Cc
mesa-sta...@lists.freedesktop.org and Emil rebases those patches onto
stable. Cc'ing the list happens even on patches sent for their first
review that are ultimately rejected, creating a lot of noise (and
presumably makes the mailing list less useful).

Initial questions:

Is the mesa-stable@ mailing list useful (other than as a tag in a
committed patch)?

What do "nominated" and "queued" in the stable release candidate
announcements actually mean?

Should driver maintainers cherry-pick patches to stable on their own?

Regardless of the outcome of that question, I think we would the
process would be more transparent and predictable if patches were
incorporated into the branch over time rather than all at once a few
days before the release.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev