Re: Email based retest request process: proposal for new pull/re-apply feature

On Tue, Mar 19, 2024 at 5:30PM, Patrick Robb wrote: On Tue, Mar 19, 2024 at 4:37 AM zhoumin wrote: One more thing I want to confirm is whether we should apply the patch onto the branch commit which existed at the time when that patch was submitted or onto the latest tip of branch if users re

Re: Email based retest request process: proposal for new pull/re-apply feature

Patrick Robb writes: > On Tue, Mar 19, 2024 at 4:37 AM zhoumin wrote: >> >> >> One more thing I want to confirm is whether we should apply the patch >> onto the branch commit which existed at the time when that patch was >> submitted or onto the latest tip of branch if users request doing >> reb

Re: Email based retest request process: proposal for new pull/re-apply feature

On Tue, Mar 19, 2024 at 4:37 AM zhoumin wrote: > > > One more thing I want to confirm is whether we should apply the patch > onto the branch commit which existed at the time when that patch was > submitted or onto the latest tip of branch if users request doing > rebase. Users probably request a r

Re: Email based retest request process: proposal for new pull/re-apply feature

On Mon, Mar 18, 2024 at 3:59PM, Patrick Robb wrote: On Thu, Mar 7, 2024 at 12:06 PM Adam Hassick wrote: I'm not opposed to having the contexts be a key-value pair argument like the others, however that does break backwards compatibility with our existing syntax. If we don't care very much ab

Re: Email based retest request process: proposal for new pull/re-apply feature

On Thu, Mar 7, 2024 at 12:06 PM Adam Hassick wrote: > > > I'm not opposed to having the contexts be a key-value pair argument > like the others, however that does break backwards compatibility with > our existing syntax. If we don't care very much about backwards > compatibility, then we could mak

Re: Email based retest request process: proposal for new pull/re-apply feature

On Mon, Mar 4, 2024 at 10:22 AM Aaron Conole wrote: > > zhoumin writes: > > > On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote: > > > > On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole wrote: > > > > Why not something like: > > > > Recheck-request: [attribute-list],[test-list]... > > > > For e

Re: Email based retest request process: proposal for new pull/re-apply feature

zhoumin writes: > On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote: > > On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole wrote: > > Why not something like: > > Recheck-request: [attribute-list],[test-list]... > > For example, then we can do: > > Recheck-request: rebase=[identifier], > >

Re: Email based retest request process: proposal for new pull/re-apply feature

On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote: On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole > wrote: Why not something like: Recheck-request: [attribute-list],[test-list]... For example, then we can do: Recheck-request: rebase=[identifier],.

Re: Email based retest request process: proposal for new pull/re-apply feature

On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole wrote: > > Why not something like: > > Recheck-request: [attribute-list],[test-list]... > > For example, then we can do: > > Recheck-request: rebase=[identifier], > > where identifier is a branch specifier (or the word 'latest')? > I hadn't thought

Re: Email based retest request process: proposal for new pull/re-apply feature

Patrick Robb writes: > Hi all, > > I want to poll the CI group and dev community about a proposed feature > addition to the CI retest request framework. > Currently, you can respond to a patchseries or patch email, requesting a > retest like so: > > Recheck-request: iol-compile-amd64-testing, i