patchwork.sourceware.org is live!

patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Hi,

Frank and I have now completed migration of the patchwork test
instance to patchwork.sourceware.org.  I posted a couple of sample
patches to the script directly and they seem to work just fine.  All
accounts that were on patchwork.siddhesh.in should continue to work in
the same manner on this instance.

I urge all glibc maintainers to please sign up and give it a spin.  As
of now, Carlos and I have admin rights for glibc and Gary for gdb, so
one of us should be able to add you to the project after you sign up,
after which you can change patch state.  Once that is done, please
close patches you know you have already pushed into master.

Please also take time to review the workflow for patch reviews:

https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

Thanks,
Siddhesh

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

On 24 May 2014 02:43, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> I urge all glibc maintainers to please sign up and give it a spin.  As
> of now, Carlos and I have admin rights for glibc and Gary for gdb, so
> one of us should be able to add you to the project after you sign up,

I forgot to mention that we don't get notifications when you sign up,
so please let us know when you have so that we can add you to the
maintainers group.

Thanks,
Siddhesh
-- 
http://siddhesh.in

Re: patchwork.sourceware.org is live!

[David Miller]

From: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
Date: Sat, 24 May 2014 08:50:38 +0530

> On 24 May 2014 02:43, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
>> I urge all glibc maintainers to please sign up and give it a spin.  As
>> of now, Carlos and I have admin rights for glibc and Gary for gdb, so
>> one of us should be able to add you to the project after you sign up,
> 
> I forgot to mention that we don't get notifications when you sign up,
> so please let us know when you have so that we can add you to the
> maintainers group.

I just registered as user "davem"

Thanks for setting this up.

Re: patchwork.sourceware.org is live!

[Eli Zaretskii]

> Date: Sat, 24 May 2014 08:50:38 +0530
> From: Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
> Cc: GNU C Library <libc-alpha@sourceware.org>, gdb@sourceware.org, carlos@redhat.com, 	fche@redhat.com, gbenson@redhat.com
> 
> On 24 May 2014 02:43, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> > I urge all glibc maintainers to please sign up and give it a spin.  As
> > of now, Carlos and I have admin rights for glibc and Gary for gdb, so
> > one of us should be able to add you to the project after you sign up,
> 
> I forgot to mention that we don't get notifications when you sign up,
> so please let us know when you have so that we can add you to the
> maintainers group.

Why not register all of the maintainers automatically?

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

On 24 May 2014 12:59, Eli Zaretskii <eliz@gnu.org> wrote:
> Why not register all of the maintainers automatically?

I don't know of a way to do it automatically and I don't want to do
the grunt work of adding users for everyone, communicate their
passwords to them and hope that they start using it in future.

Siddhesh
-- 
http://siddhesh.in

Re: patchwork.sourceware.org is live!

[Andreas Jaeger]

On 05/23/2014 11:13 PM, Siddhesh Poyarekar wrote:
> Hi,
> 
> Frank and I have now completed migration of the patchwork test
> instance to patchwork.sourceware.org.  I posted a couple of sample
> patches to the script directly and they seem to work just fine.  All
> accounts that were on patchwork.siddhesh.in should continue to work in
> the same manner on this instance.
> 
> I urge all glibc maintainers to please sign up and give it a spin.  As
> of now, Carlos and I have admin rights for glibc and Gary for gdb, so
> one of us should be able to add you to the project after you sign up,
> after which you can change patch state.  Once that is done, please
> close patches you know you have already pushed into master.
> 
> Please also take time to review the workflow for patch reviews:
> 
> https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

I have one question:

A patch that is merged, should have "Accepted", correct? so, patches
that are already committed should be changed to have this...

If i just comment on a patch with a "Looks fine", should I say "Under
Review" - and then the submitter sets this to "Accepted"?

Please document this workflow a bit better, it's confusing to me...

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

On 26 May 2014 12:36, Andreas Jaeger <aj@suse.com> wrote:
> A patch that is merged, should have "Accepted", correct? so, patches
> that are already committed should be changed to have this...
>
> If i just comment on a patch with a "Looks fine", should I say "Under
> Review" - and then the submitter sets this to "Accepted"?

'Under Review' is a transitional state for a reviewer to 'take' a
patch off the queue for review.

We don't differentiate between review completion and commit; I guess
we should since the reviewer is not always responsible for commiting
the change.  May I add an additional status 'Committed' to indicate
this?  That way a reviewer sets 'Accepted' when the patch looks good
and the committer changes state to 'Committed' when the change is in
git.  If the reviewer commits the change herself (i.e. when the
submitter does not have commit access), the former may set status to
'Committed' directly.

Thoughts?

Siddhesh
-- 
http://siddhesh.in

Re: patchwork.sourceware.org is live!

[Andreas Jaeger]

On 05/26/2014 09:29 AM, Siddhesh Poyarekar wrote:
> On 26 May 2014 12:36, Andreas Jaeger <aj@suse.com> wrote:
>> A patch that is merged, should have "Accepted", correct? so, patches
>> that are already committed should be changed to have this...
>>
>> If i just comment on a patch with a "Looks fine", should I say "Under
>> Review" - and then the submitter sets this to "Accepted"?
> 
> 'Under Review' is a transitional state for a reviewer to 'take' a
> patch off the queue for review.
> 
> We don't differentiate between review completion and commit; I guess

Ah...

> we should since the reviewer is not always responsible for commiting
> the change.  May I add an additional status 'Committed' to indicate
> this?  That way a reviewer sets 'Accepted' when the patch looks good
> and the committer changes state to 'Committed' when the change is in
> git.  If the reviewer commits the change herself (i.e. when the
> submitter does not have commit access), the former may set status to
> 'Committed' directly.
> 
> Thoughts?


What happens if one person says "fine" while another one disagrees? Is
Accepted then the right state for this?

Could you write up a workflow: Live of a patch, something like:
1. Patch gets submitted, system puts patch into state NEW
2. Reviewer comments on it:
a) Disagrees: Sets it to
b) agrees: Sets it to
c) Not a patch for glibc, set it to Not Applicable
3. Patch gets committed: Set it to Commited/Accepted


Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

On 26 May 2014 13:07, Andreas Jaeger <aj@suse.com> wrote:
>
> What happens if one person says "fine" while another one disagrees? Is
> Accepted then the right state for this?

The first reviewer sets 'Accepted' (assuming she doesn't need another
reviewer to validate) and if another reviewer disagrees then he can
set the status back to 'Under Review'.  if he agrees, then there's no
need to change any status.

> Could you write up a workflow: Live of a patch, something like:
> 1. Patch gets submitted, system puts patch into state NEW
> 2. Reviewer comments on it:
> a) Disagrees: Sets it to
> b) agrees: Sets it to
> c) Not a patch for glibc, set it to Not Applicable
> 3. Patch gets committed: Set it to Commited/Accepted

That's a good idea.  I have modified the current document[1] and also
added the Committed status to the document.  Once we have consensus on
adding the new 'Committed' status, I'll also add it to patchwork.

Siddhesh
[1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
-- 
http://siddhesh.in

Re: patchwork.sourceware.org is live!

[Andreas Jaeger]

On 05/26/2014 09:52 AM, Siddhesh Poyarekar wrote:
> On 26 May 2014 13:07, Andreas Jaeger <aj@suse.com> wrote:
>>
>> What happens if one person says "fine" while another one disagrees? Is
>> Accepted then the right state for this?
> 
> The first reviewer sets 'Accepted' (assuming she doesn't need another
> reviewer to validate) and if another reviewer disagrees then he can
> set the status back to 'Under Review'.  if he agrees, then there's no
> need to change any status.
> 
>> Could you write up a workflow: Live of a patch, something like:
>> 1. Patch gets submitted, system puts patch into state NEW
>> 2. Reviewer comments on it:
>> a) Disagrees: Sets it to
>> b) agrees: Sets it to
>> c) Not a patch for glibc, set it to Not Applicable
>> 3. Patch gets committed: Set it to Commited/Accepted
> 
> That's a good idea.  I have modified the current document[1] and also
> added the Committed status to the document.  Once we have consensus on
> adding the new 'Committed' status, I'll also add it to patchwork.
> 
> Siddhesh
> [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
> 

thanks, that answers my current ;) questions nicely,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Re: patchwork.sourceware.org is live!

[Ondřej Bílka]

On Mon, May 26, 2014 at 10:02:22AM +0200, Andreas Jaeger wrote:
> On 05/26/2014 09:52 AM, Siddhesh Poyarekar wrote:
> > On 26 May 2014 13:07, Andreas Jaeger <aj@suse.com> wrote:
> >>
> >> What happens if one person says "fine" while another one disagrees? Is
> >> Accepted then the right state for this?
> > 
> > The first reviewer sets 'Accepted' (assuming she doesn't need another
> > reviewer to validate) and if another reviewer disagrees then he can
> > set the status back to 'Under Review'.  if he agrees, then there's no
> > need to change any status.
> > 
> >> Could you write up a workflow: Live of a patch, something like:
> >> 1. Patch gets submitted, system puts patch into state NEW
> >> 2. Reviewer comments on it:
> >> a) Disagrees: Sets it to
> >> b) agrees: Sets it to
> >> c) Not a patch for glibc, set it to Not Applicable
> >> 3. Patch gets committed: Set it to Commited/Accepted
> > 
> > That's a good idea.  I have modified the current document[1] and also
> > added the Committed status to the document.  Once we have consensus on
> > adding the new 'Committed' status, I'll also add it to patchwork.
> > 
> > Siddhesh
> > [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
> > 
> 
> thanks, that answers my current ;) questions nicely,
> 
That should be set automatically. I use a following script to detect
commited patches.

tester(){


}

rm failed
rm applied
rm uncompiled
PATCHES=`~/pwork/pwclient list -s New | tail -n +4| awk '{print $1}'`
for I in $PATCHES; do
   cd $GLIBC/glibc
   ~/pwork/pwclient get $I
   if  git apply -R /tmp/patch 2>/dev/null; then
     git apply /tmp/patch 2>/dev/null
     echo already applied
     ~/pwork/pwclient info $I
     ~/pwork/pwclient info $I >> applied
   elif git apply /tmp/patch 2>/dev/null; then
     tester
     cd $GLIBC/glibc
     git apply -R /tmp/patch 2>/dev/null
   else
     echo cannot apply
     ~/pwork/pwclient info $I
     ~/pwork/pwclient info $I >> failed
   fi
done

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Mon, May 26, 2014 at 12:20:52PM +0200, Ondřej Bílka wrote:
> That should be set automatically. I use a following script to detect
> commited patches.
> 

It might be useful if you could write it as a post-receive hook.

Siddhesh

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: patchwork.sourceware.org is live!

[Ondřej Bílka]

On Mon, May 26, 2014 at 04:12:26PM +0530, Siddhesh Poyarekar wrote:
> On Mon, May 26, 2014 at 12:20:52PM +0200, Ondřej Bílka wrote:
> > That should be set automatically. I use a following script to detect
> > commited patches.
> > 
> 
> It might be useful if you could write it as a post-receive hook.
> 
> Siddhesh

not practical as now it takes ten minutes because it enumerates all
patches. it is part of automated checker which will be slow (doing
things like running make xcheck for each patch)

Re: patchwork.sourceware.org is live!

[Samuel Bronson]

Ondřej Bílka <neleai@seznam.cz> writes:
> On Mon, May 26, 2014 at 10:02:22AM +0200, Andreas Jaeger wrote:
>> On 05/26/2014 09:52 AM, Siddhesh Poyarekar wrote:
>> > That's a good idea.  I have modified the current document[1] and also
>> > added the Committed status to the document.  Once we have consensus on
>> > adding the new 'Committed' status, I'll also add it to patchwork.
>> > 
>> > Siddhesh
>> > [1] https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow
>> > 

Are there any objections to the new state?

> That should be set automatically. I use a following script to detect
> commited patches.

If there are no objections, I guess the script will need to be changed
to put patches in the "Committed" state instead of the "Accepted" state?

However, really I'd prefer if it could give some indication as to
*which* commit(s) the patch was committed as, and it doesn't look like
this is viable with the current approach, since you seem to just test if
each patch can be applied backwards to HEAD.

Oh, but now I notice that that *particular* script is glibc-only anyway,
so maybe I don't really care that much ...

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

On Thu, May 29, 2014 at 09:56:55PM -0400, Samuel Bronson wrote:
> Are there any objections to the new state?

None so far.  I have added it to patchwork now.  I have not yet made
'Accepted' an 'Action Required' state because that will clutter the
view; I'll do it when I get explicit blessings from more maintainers.

> > That should be set automatically. I use a following script to detect
> > commited patches.
> 
> If there are no objections, I guess the script will need to be changed
> to put patches in the "Committed" state instead of the "Accepted" state?
> 
> However, really I'd prefer if it could give some indication as to
> *which* commit(s) the patch was committed as, and it doesn't look like
> this is viable with the current approach, since you seem to just test if
> each patch can be applied backwards to HEAD.
> 
> Oh, but now I notice that that *particular* script is glibc-only anyway,
> so maybe I don't really care that much ...

That particular script was just an example, so ideas for automating
this are still welcome.

Siddhesh

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: patchwork.sourceware.org is live!

[Pedro Alves]

On 05/30/2014 04:00 AM, Siddhesh Poyarekar wrote:
> On Thu, May 29, 2014 at 09:56:55PM -0400, Samuel Bronson wrote:
>> Are there any objections to the new state?
> 
> None so far.  I have added it to patchwork now.  I have not yet made
> 'Accepted' an 'Action Required' state because that will clutter the
> view; I'll do it when I get explicit blessings from more maintainers.

That's be fine with me (speaking from the gdb side).  And I like the
new state.

-- 
Pedro Alves

Re: patchwork.sourceware.org is live!

[Pedro Alves]

On 05/30/2014 09:36 AM, Pedro Alves wrote:
> On 05/30/2014 04:00 AM, Siddhesh Poyarekar wrote:
>> On Thu, May 29, 2014 at 09:56:55PM -0400, Samuel Bronson wrote:
>>> Are there any objections to the new state?
>>
>> None so far.  I have added it to patchwork now.  I have not yet made
>> 'Accepted' an 'Action Required' state because that will clutter the
>> view; I'll do it when I get explicit blessings from more maintainers.
> 
> That's be fine with me (speaking from the gdb side).  And I like the
> new state.

BTW, before (or just after) you make 'Accepted' be 'Action Required', I'd
like to bulk change all current GDB 'Accepted' patches to 'Committed',
and start making use of 'Accepted' only for new patches.  I don't think
it's that worth it to go through each and every currently 'Accepted'
patch and check whether it's committed manually.  We can work on automating
that afterwards.  But can't do that bulk change with pwclient until
the "No authentication credentials given" issue is sorted out.

Did you plan on doing such a bulk change from the admin side?

-- 
Pedro Alves

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Fri, May 30, 2014 at 09:45:34AM +0100, Pedro Alves wrote:
> BTW, before (or just after) you make 'Accepted' be 'Action Required', I'd
> like to bulk change all current GDB 'Accepted' patches to 'Committed',
> and start making use of 'Accepted' only for new patches.  I don't think
> it's that worth it to go through each and every currently 'Accepted'
> patch and check whether it's committed manually.  We can work on automating
> that afterwards.  But can't do that bulk change with pwclient until
> the "No authentication credentials given" issue is sorted out.

Yes, I've asked Frank for help with that since I don't have access to
the web server configuration, which is where the authentication header
must be getting stripped.

> Did you plan on doing such a bulk change from the admin side?

That was the question I forgot to ask :) I agree that it does not make
sense to go through old patches to mark them Committed manually.  I'll
plan to do bulk change unless someone objects to it.

Siddhesh

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: patchwork.sourceware.org is live!

[Pedro Alves]

On 05/30/2014 09:56 AM, Siddhesh Poyarekar wrote:
> On Fri, May 30, 2014 at 09:45:34AM +0100, Pedro Alves wrote:

>> Did you plan on doing such a bulk change from the admin side?
> 
> That was the question I forgot to ask :) I agree that it does not make
> sense to go through old patches to mark them Committed manually.  I'll
> plan to do bulk change unless someone objects to it.

It seems no one objects.

pwclient works again, so I went ahead and did this on the GDB side:

 $ pwclient list -s "Accepted" > /tmp/accepted
 $ grep "^[0-9]\+" /tmp/accepted | awk '{print $1}' | while read id; do pwclient update -s Committed $id; done

-- 
Pedro Alves

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Thu, Jun 05, 2014 at 12:36:27PM +0100, Pedro Alves wrote:
> pwclient works again, so I went ahead and did this on the GDB side:
> 
>  $ pwclient list -s "Accepted" > /tmp/accepted
>  $ grep "^[0-9]\+" /tmp/accepted | awk '{print $1}' | while read id; do pwclient update -s Committed $id; done
> 

Thanks, I'll do this on Monday on the glibc side too if nobody objects
till then, and then make 'Accepted' patches visible for committers to
close as Committed.

Siddhesh

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: patchwork.sourceware.org is live!

[Ondřej Bílka]

On Fri, May 30, 2014 at 08:30:29AM +0530, Siddhesh Poyarekar wrote:
> On Thu, May 29, 2014 at 09:56:55PM -0400, Samuel Bronson wrote:
> > Are there any objections to the new state?
> 
> None so far.  I have added it to patchwork now.  I have not yet made
> 'Accepted' an 'Action Required' state because that will clutter the
> view; I'll do it when I get explicit blessings from more maintainers.
> 
> > > That should be set automatically. I use a following script to detect
> > > commited patches.
> > 
> > If there are no objections, I guess the script will need to be changed
> > to put patches in the "Committed" state instead of the "Accepted" state?
> > 
> > However, really I'd prefer if it could give some indication as to
> > *which* commit(s) the patch was committed as, and it doesn't look like
> > this is viable with the current approach, since you seem to just test if
> > each patch can be applied backwards to HEAD.
> > 
> > Oh, but now I notice that that *particular* script is glibc-only anyway,
> > so maybe I don't really care that much ...
> 
Its pretty general, you can use it for any project that uses git. A
more important part is running automated checks with it.

Re: patchwork.sourceware.org is live!

[Florian Weimer]

On 05/23/2014 11:13 PM, Siddhesh Poyarekar wrote:

> Frank and I have now completed migration of the patchwork test
> instance to patchwork.sourceware.org.

Unfortunately, the zone update for sourceware.org failed to propagate to 
dns.zembu.com:

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> +norecurse 
@dns.zembu.com. patchwork.sourceware.org.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36413
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;patchwork.sourceware.org.	IN	A

;; AUTHORITY SECTION:
sourceware.org.		43200	IN	SOA	ns.sourceware.org. root.sourceware.org. 
2013031902 14400 3600 1728000 9600

;; Query time: 76 msec
;; SERVER: 64.13.131.148#53(64.13.131.148)
;; WHEN: Mon May 26 05:57:45 2014
;; MSG SIZE  rcvd: 86

This will cause intermittent failures to reach the service for some users.

-- 
Florian Weimer / Red Hat Product Security Team

Re: patchwork.sourceware.org is live!

[Carlos O'Donell]

On 05/26/2014 05:59 AM, Florian Weimer wrote:
> This will cause intermittent failures to reach the service for some users.

+1

Had to add patchwork.sourceware.org to my /etc/hosts file with a fixed IP
until this propagates fully.

c.
 

Re: patchwork.sourceware.org is live!

[Andreas Jaeger]

One more question: Can I comment in patchwork on patches?

I'm used to gerrit where I can review and comment patches in one webui.
patchwork looks like I need to switch the whole time between webui - for
tracking what's not done and possible review - and mailer - for
commenting. That's a lot switching of tools ;(

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Re: patchwork.sourceware.org is live!

[Carlos O'Donell]

On 05/26/2014 10:31 AM, Andreas Jaeger wrote:
> One more question: Can I comment in patchwork on patches?
> 
> I'm used to gerrit where I can review and comment patches in one webui.
> patchwork looks like I need to switch the whole time between webui - for
> tracking what's not done and possible review - and mailer - for
> commenting. That's a lot switching of tools ;(

That's the way it works.

Email for all discussion.

webui or cli for orthogonal but related review process.

Cheers,
Carlos.

Re: patchwork.sourceware.org is live!

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

Hi!

On Sat, 24 May 2014 02:43:38 +0530, Siddhesh Poyarekar <siddhesh@redhat.com> wrote:
> patchwork.sourceware.org

> close patches you know you have already pushed into master.

Does that mean changing the state to »Accepted« (or »Committed«, once
that has been added), or ticking the »Archived« box, or both?  What's the
meaning of the »Archived« box?

> Please also take time to review the workflow for patch reviews:
> 
> https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

So, does patchwork's »Delegate to« Patch Property equal Bugzilla's
»Assigned To« field?  And, it is not totally clear to my why the Patch
Review Workflow suggests to »not change the status of the patch« if
»changing the Delegate to value to their patchwork username«?

"In a perfect world", after a patch review, during which »Delegate to«
has been set to the reviewer(s), should it then be changed to the person
who is responsible for committing the patch (which may be the submitter,
or the reviewer, or someone else), together with changing the state to
»Accepted«?


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

Re: patchwork.sourceware.org is live!

[Siddhesh Poyarekar]

On 27 May 2014 11:52, Thomas Schwinge <thomas@codesourcery.com> wrote:
>> close patches you know you have already pushed into master.
>
> Does that mean changing the state to »Accepted« (or »Committed«, once
> that has been added), or ticking the »Archived« box, or both?  What's the
> meaning of the »Archived« box?

Only change to Accepted for now, since nobody has commented on my
suggestion to add a new Committed status.  I have no idea what the
Archived checkbox does :)

> So, does patchwork's »Delegate to« Patch Property equal Bugzilla's
> »Assigned To« field?  And, it is not totally clear to my why the Patch
> Review Workflow suggests to »not change the status of the patch« if
> »changing the Delegate to value to their patchwork username«?

That suggestion is no longer necessary.  I have added the 'Under
Review' and 'Change Requested' statuses to the default view, so
changing state should not make those patches disappear from the queue
unless the state is Accepted, Superseded, RFC or Rejected.

> "In a perfect world", after a patch review, during which »Delegate to«
> has been set to the reviewer(s), should it then be changed to the person
> who is responsible for committing the patch (which may be the submitter,
> or the reviewer, or someone else), together with changing the state to
> »Accepted«?

Yes, that would be good idea.

Siddhesh
-- 
http://siddhesh.in