Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

On 15/01/20 12:35 am, Christian Biesinger wrote:
> Any news on this upgrade? Would be nice to play with patchwork for gdb.
> 

Sorry I got caught up in other work and had to put this aside.  I hope
to resume in a week or so.

Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Christian Biesinger]

On Mon, Dec 9, 2019 at 12:16 PM Sergio Durigan Junior
 wrote:
>
> On Monday, December 09 2019, Siddhesh Poyarekar wrote:
>
> > On 09/12/19 9:14 pm, Sergio Durigan Junior wrote:
> >> Hey, Siddhesh,
> >>
> >> I know you're in touch with Konstantin already, but another option would
> >> be to use the OSCI VM running on gnutoolchain-gerrit.osci.io.  I can
> >> talk to the OSCI folks and ask them if it'd be possible to have an alias
> >> hostname or something to make it easier to separate the services, if 
> >> needed.
> >
> > That works too, since Konstantin just confirmed that they cannot host
> > this on kernel.org.
>
> Alright.  I'll get in touch with OSCI.  Please send me your public SSH
> key so I can give you access to the machine.


Any news on this upgrade? Would be nice to play with patchwork for gdb.

Christian

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

On 09/12/19 10:22 pm, Konstantin Ryabitsev wrote:
> I'm not sure it makes that much sense to put glibc on 
> patchwork.kernel.org. I know we have some non-kernel projects there, but 
> they are pretty tiny and were approved largely because they wouldn't 
> make much of an impact on kernel.org infra.
> 
> The same wouldn't be true for glibc, especially if we're talking bot and 
> CI integration. It really needs to stay on its own dedicated 
> infrastructure where it can be properly scoped and resourced.
> 
> Sorry that I don't have a better answer.
> 

I understand, thanks anyway.

Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

On 09/12/19 9:14 pm, Sergio Durigan Junior wrote:
> Hey, Siddhesh,
> 
> I know you're in touch with Konstantin already, but another option would
> be to use the OSCI VM running on gnutoolchain-gerrit.osci.io.  I can
> talk to the OSCI folks and ask them if it'd be possible to have an alias
> hostname or something to make it easier to separate the services, if needed.

That works too, since Konstantin just confirmed that they cannot host
this on kernel.org.

Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Konstantin Ryabitsev]

On Mon, Dec 09, 2019 at 01:26:16PM +0530, Siddhesh Poyarekar wrote:
> On 08/12/19 5:51 pm, Christian Brauner wrote:
> >> Maybe we can use  for temporary
> >> hosting?  It already covers some non-kernel lists.
> > 
> > If this is an option you'd probably need to talk to Konstantin about
> > this.

Hi, all:

I'm not sure it makes that much sense to put glibc on 
patchwork.kernel.org. I know we have some non-kernel projects there, but 
they are pretty tiny and were approved largely because they wouldn't 
make much of an impact on kernel.org infra.

The same wouldn't be true for glibc, especially if we're talking bot and 
CI integration. It really needs to stay on its own dedicated 
infrastructure where it can be properly scoped and resourced.

Sorry that I don't have a better answer.

Best,
-K

Re: [X-POST] patchwork.sourceware.org refresh

[Sergio Durigan Junior]

On Sunday, December 08 2019, Siddhesh Poyarekar wrote:

> Hello,
>
> I've been battling with this on and off for a couple of weeks now and
> I've finally given up because I haven't been able to get the
> dependencies in order for the latest patchwork+django on the sourceware
> server.
>
> I can bring patchwork.siddhesh.in (that thing i set up before moving to
> patchwork.sourceware.org) back up to the latest with data from
> patchwork.sourceware.org.  Would that work for people wanting to try
> this out?  We can migrate back to patchwork.sourceware.org once it is
> ready for the latest patchwork.

Hey, Siddhesh,

I know you're in touch with Konstantin already, but another option would
be to use the OSCI VM running on gnutoolchain-gerrit.osci.io.  I can
talk to the OSCI folks and ask them if it'd be possible to have an alias
hostname or something to make it easier to separate the services, if needed.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

On 08/12/19 5:51 pm, Christian Brauner wrote:
>> Maybe we can use  for temporary
>> hosting?  It already covers some non-kernel lists.
> 
> If this is an option you'd probably need to talk to Konstantin about
> this.

Oh of course, less work is always better, I was only trying not to
bother them since we had not finalized use of patchwork.  Konstantin if
you're OK with us using the patchwork.kernel.org instance as a pilot,
it'll be great if you could set up an instance for glibc.

I had a couple of questions though before we set this up because these
were points that led to bitrot in our patchwork instance:

1. Do you have hooks in place to auto-close patches in patchwork when
they're committed?

2. Do you know if patchwork reliably closes off older versions of patch
submissions, or if there's a way other projects are managing this.

3. Could you allow one of us (me to start with) to add hooks to do CI
runs?  Alternatively, do you have some CI infrastructure in place that
allows projects to do builds against a patchwork submission and report
errors to the mailing list?

These are things I was going to explore with a local patchwork instance
and if it's possible with patchwork.kernel.org, I'm all for it.

Thanks,
Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Florian Weimer]

* Siddhesh Poyarekar:

> I've been battling with this on and off for a couple of weeks now and
> I've finally given up because I haven't been able to get the
> dependencies in order for the latest patchwork+django on the sourceware
> server.
>
> I can bring patchwork.siddhesh.in (that thing i set up before moving to
> patchwork.sourceware.org) back up to the latest with data from
> patchwork.sourceware.org.  Would that work for people wanting to try
> this out?  We can migrate back to patchwork.sourceware.org once it is
> ready for the latest patchwork.

Maybe we can use  for temporary
hosting?  It already covers some non-kernel lists.

Re: [X-POST] patchwork.sourceware.org refresh

[Christian Brauner]

On Sun, Dec 08, 2019 at 01:10:37PM +0100, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
> > I've been battling with this on and off for a couple of weeks now and
> > I've finally given up because I haven't been able to get the
> > dependencies in order for the latest patchwork+django on the sourceware
> > server.
> >
> > I can bring patchwork.siddhesh.in (that thing i set up before moving to
> > patchwork.sourceware.org) back up to the latest with data from
> > patchwork.sourceware.org.  Would that work for people wanting to try
> > this out?  We can migrate back to patchwork.sourceware.org once it is
> > ready for the latest patchwork.
> 
> Maybe we can use  for temporary
> hosting?  It already covers some non-kernel lists.

If this is an option you'd probably need to talk to Konstantin about
this.

Christian

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

Hello,

I've been battling with this on and off for a couple of weeks now and
I've finally given up because I haven't been able to get the
dependencies in order for the latest patchwork+django on the sourceware
server.

I can bring patchwork.siddhesh.in (that thing i set up before moving to
patchwork.sourceware.org) back up to the latest with data from
patchwork.sourceware.org.  Would that work for people wanting to try
this out?  We can migrate back to patchwork.sourceware.org once it is
ready for the latest patchwork.

Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Carlos O'Donell]

On 12/3/19 2:07 PM, Tom Tromey wrote:
>> "Siddhesh" == Siddhesh Poyarekar  writes:
> 
>>> Or do you have something else, i.e. not just an upgrade, in mind?
> 
> Siddhesh> To begin with, I intend to add hooks to close patchwork patches on 
> merge
> Siddhesh> so that that aspect is automated.  It was the one problem we had 
> with
> Siddhesh> patchwork and with ChangeLogs gone in glibc, we're definitely a lot 
> more
> Siddhesh> likely to get close to that goal.
> 
> For gdb, I'd like this to be much more reliable than it is today.  We
> were thinking we'd simply add a kind of patch-id to the commit message
> -- the way we're currently doing with gerrit -- and then have patchworks
> recognize this ID and use it as its internal key.
> 
> I think this is not a very large amount of work in patchworks.

That would be awesome.

-- 
Cheers,
Carlos.

Re: [X-POST] patchwork.sourceware.org refresh

[Tom Tromey]

> "Siddhesh" == Siddhesh Poyarekar  writes:

>> Or do you have something else, i.e. not just an upgrade, in mind?

Siddhesh> To begin with, I intend to add hooks to close patchwork patches on 
merge
Siddhesh> so that that aspect is automated.  It was the one problem we had with
Siddhesh> patchwork and with ChangeLogs gone in glibc, we're definitely a lot 
more
Siddhesh> likely to get close to that goal.

For gdb, I'd like this to be much more reliable than it is today.  We
were thinking we'd simply add a kind of patch-id to the commit message
-- the way we're currently doing with gerrit -- and then have patchworks
recognize this ID and use it as its internal key.

I think this is not a very large amount of work in patchworks.

Tom

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

Hello,

A quick update on status.  I attempted an update today and discovered
that I need help from overseers to update a few system packages before I
can do this.  As a result, the patchwork update won't happen today.

Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

On 30/11/19 5:05 pm, Maciej W. Rozycki wrote:
>  How do I do that though?  There doesn't appear to be anything there I 
> could do from my profile page or elsewhere.

Oh I was only thinking of something rudimentary like copying over the
list of pending patches into a text file.

>  Sure, and greatly appreciated too (I've seen your proposal in the other 
> thread of discussion), but adding hooks is not supposed to affect any 
> existing patchwork state that the lone upgrade puts at risk.  Some kind of 
> restructuring could.

Yeah, I hope it works out without having to nuke the repo too.  I'll
find out later today.

Siddhesh

Re: [X-POST] patchwork.sourceware.org refresh

[Maciej W. Rozycki]

On Thu, 28 Nov 2019, Siddhesh Poyarekar wrote:

> >  Well, I've been using it to track the state my own patches submitted (and 
> > during the period of my active MIPS GDB port maintenance also for other 
> > people's submissions).
> 
> Can you please take a snapshot of your state?

 How do I do that though?  There doesn't appear to be anything there I 
could do from my profile page or elsewhere.

> >  Or do you have something else, i.e. not just an upgrade, in mind?
> 
> To begin with, I intend to add hooks to close patchwork patches on merge
> so that that aspect is automated.  It was the one problem we had with
> patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
> likely to get close to that goal.

 Sure, and greatly appreciated too (I've seen your proposal in the other 
thread of discussion), but adding hooks is not supposed to affect any 
existing patchwork state that the lone upgrade puts at risk.  Some kind of 
restructuring could.

  Maciej

Re: [X-POST] patchwork.sourceware.org refresh

[Carlos O'Donell]

On 11/28/19 12:47 AM, Siddhesh Poyarekar wrote:
> On 28/11/19 10:55 am, Maciej W. Rozycki wrote:
>>  Well, I've been using it to track the state my own patches submitted (and 
>> during the period of my active MIPS GDB port maintenance also for other 
>> people's submissions).
> 
> Can you please take a snapshot of your state?
> 
>>  Is it actually necessary to destroy all the recorded state (not only for 
>> patches, but also for e-mail accounts linked, which AFAIK cannot be 
>> restored once you've lost access to any) just for an engine upgrade?  
>> That would be an odd requirement and ISTR at least one of the patchworks 
>> I've had an account with to have been seamlessly upgraded at one point.
> 
> Hmm, I will try to do an in-place upgrade without actually deleting
> anything.  I can't promise that it will go well because we'll be
> upgrading from a very ancient version and I don't know right now if the
> schema has changed incompatibly.
> 
> I'll do a backup too FWIW.

When I looked at this the upgrade was *very* complicated, and carrying over
the data from a version that is so old was going to be hard.

>>  Or do you have something else, i.e. not just an upgrade, in mind?
> 
> To begin with, I intend to add hooks to close patchwork patches on merge
> so that that aspect is automated.  It was the one problem we had with
> patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
> likely to get close to that goal.

Agreed!

For me as a reviewer, knowing what's up-to-date and ready for review,
having a tool (like pwclient) to pull the patch and build a local branch
from it, and then being able to use local diff tooling is really the key
things to accelerate patch review for patches that don't require complex
consensus.

-- 
Cheers,
Carlos.

Re: [X-POST] patchwork.sourceware.org refresh

[Siddhesh Poyarekar]

On 28/11/19 10:55 am, Maciej W. Rozycki wrote:
>  Well, I've been using it to track the state my own patches submitted (and 
> during the period of my active MIPS GDB port maintenance also for other 
> people's submissions).

Can you please take a snapshot of your state?

>  Is it actually necessary to destroy all the recorded state (not only for 
> patches, but also for e-mail accounts linked, which AFAIK cannot be 
> restored once you've lost access to any) just for an engine upgrade?  
> That would be an odd requirement and ISTR at least one of the patchworks 
> I've had an account with to have been seamlessly upgraded at one point.

Hmm, I will try to do an in-place upgrade without actually deleting
anything.  I can't promise that it will go well because we'll be
upgrading from a very ancient version and I don't know right now if the
schema has changed incompatibly.

I'll do a backup too FWIW.

>  Or do you have something else, i.e. not just an upgrade, in mind?

To begin with, I intend to add hooks to close patchwork patches on merge
so that that aspect is automated.  It was the one problem we had with
patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
likely to get close to that goal.

Siddhesh