[X-POST] patchwork.sourceware.org refresh

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[X-POST] patchwork.sourceware.org refresh

Siddhesh Poyarekar-8
Hi,

During discussions over patch tracking systems on the glibc libc-alpha
mailing list[1] we thought it would be a worthwhile experiment to try
the latest patchwork to see if it fits our needs.  A quick look through
the current instance on patchwork.sourceware.org indicates that none of
the current projects (glibc, gdb, guix) are actively using the instance,
so I will be nuking it and reinstalling it afresh.

I intend to do this during the day of 1 Dec 2019, India time, so if
there are any objections or if you would like to take backups, please do
so before that.

Thanks,
Siddhesh
Reply | Threaded
Open this post in threaded view
|

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

Simon Marchi-4
On 2019-11-28 12:00 a.m., Siddhesh Poyarekar wrote:

> Hi,
>
> During discussions over patch tracking systems on the glibc libc-alpha
> mailing list[1] we thought it would be a worthwhile experiment to try
> the latest patchwork to see if it fits our needs.  A quick look through
> the current instance on patchwork.sourceware.org indicates that none of
> the current projects (glibc, gdb, guix) are actively using the instance,
> so I will be nuking it and reinstalling it afresh.
>
> I intend to do this during the day of 1 Dec 2019, India time, so if
> there are any objections or if you would like to take backups, please do
> so before that.
>
> Thanks,
> Siddhesh
>

Thanks for doing this!  I look forward to experiment with it, see how we can
automate as much as possible the management of patches to reduce the manual
work.

Simon
Reply | Threaded
Open this post in threaded view
|

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

Maciej W. Rozycki
In reply to this post by Siddhesh Poyarekar-8
On Thu, 28 Nov 2019, Siddhesh Poyarekar wrote:

> During discussions over patch tracking systems on the glibc libc-alpha
> mailing list[1] we thought it would be a worthwhile experiment to try
> the latest patchwork to see if it fits our needs.  A quick look through
> the current instance on patchwork.sourceware.org indicates that none of
> the current projects (glibc, gdb, guix) are actively using the instance,
> so I will be nuking it and reinstalling it afresh.

 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).

> I intend to do this during the day of 1 Dec 2019, India time, so if
> there are any objections or if you would like to take backups, please do
> so before that.

 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.

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

  Maciej
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
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
Reply | Threaded
Open this post in threaded view
|

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

Carlos O'Donell-5
In reply to this post by Siddhesh Poyarekar-8
On 11/28/19 12:00 AM, Siddhesh Poyarekar wrote:

> Hi,
>
> During discussions over patch tracking systems on the glibc libc-alpha
> mailing list[1] we thought it would be a worthwhile experiment to try
> the latest patchwork to see if it fits our needs.  A quick look through
> the current instance on patchwork.sourceware.org indicates that none of
> the current projects (glibc, gdb, guix) are actively using the instance,
> so I will be nuking it and reinstalling it afresh.
>
> I intend to do this during the day of 1 Dec 2019, India time, so if
> there are any objections or if you would like to take backups, please do
> so before that.

I have no objection to nuking the entire state.

My only use of patchwork was to review old patches for a particular
subsystem. So for example when we were working on malloc changes I would
review what was in the backlog and do an update of all those bugs.

This was just a courtesy to users who had posted previous patches that
we'd never gotten around to fixing. I could do a similar query by just
looking back across the mailing list and grepping for "malloc" or
similar.

--
Cheers,
Carlos.

Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer
* Carlos O'Donell:

> On 11/28/19 12:00 AM, Siddhesh Poyarekar wrote:
>> Hi,
>>
>> During discussions over patch tracking systems on the glibc libc-alpha
>> mailing list[1] we thought it would be a worthwhile experiment to try
>> the latest patchwork to see if it fits our needs.  A quick look through
>> the current instance on patchwork.sourceware.org indicates that none of
>> the current projects (glibc, gdb, guix) are actively using the instance,
>> so I will be nuking it and reinstalling it afresh.
>>
>> I intend to do this during the day of 1 Dec 2019, India time, so if
>> there are any objections or if you would like to take backups, please do
>> so before that.
>
> I have no objection to nuking the entire state.

We should make sure that we can figure out what URLs refer to.  I
found one in the commit log:

  <https://patchwork.sourceware.org/patch/10342/>

This is:

Subject: Re: [PATCH 2/2] Initialize tunable list with the GLIBC_TUNABLES
 environment variable
To: Siddhesh Poyarekar <[hidden email]>, [hidden email]
References: <[hidden email]>
Cc: [hidden email], [hidden email], Andi Kleen <[hidden email]>
From: "Paul E. Murphy" <[hidden email]>
Message-ID: <[hidden email]>
Date: Mon, 11 Jan 2016 15:26:43 -0600

<https://sourceware.org/ml/libc-alpha/2016-01/msg00239.html>

There are probably a few more references in Bugzilla and on
libc-alpha.
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
On 28/11/19 9:32 pm, Florian Weimer wrote:
> We should make sure that we can figure out what URLs refer to.  I
> found one in the commit log:
>
>   <https://patchwork.sourceware.org/patch/10342/>
>

Hmm, that's going to be a bit of a challenge.  Let me see what I can do.

Siddhesh
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer
* Siddhesh Poyarekar:

> On 28/11/19 9:32 pm, Florian Weimer wrote:
>> We should make sure that we can figure out what URLs refer to.  I
>> found one in the commit log:
>>
>>   <https://patchwork.sourceware.org/patch/10342/>
>>
>
> Hmm, that's going to be a bit of a challenge.  Let me see what I can do.

Maybe it's possible to grep the backing files for the message ID?
Then we have at least *something* to resolve the URL in case we need
it in the future.
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer
* Andrew Burgess:

> * Florian Weimer <[hidden email]> [2019-11-28 17:23:58 +0100]:
>
>> * Siddhesh Poyarekar:
>>
>> > On 28/11/19 9:32 pm, Florian Weimer wrote:
>> >> We should make sure that we can figure out what URLs refer to.  I
>> >> found one in the commit log:
>> >>
>> >>   <https://patchwork.sourceware.org/patch/10342/>
>> >>
>> >
>> > Hmm, that's going to be a bit of a challenge.  Let me see what I can do.
>>
>> Maybe it's possible to grep the backing files for the message ID?
>> Then we have at least *something* to resolve the URL in case we need
>> it in the future.
>
> If there aren't too many references, maybe you could dump the patch
> information into a text file within the source tree?
I think just posting it to the mailing list would be sufficient.

Below is the (compressed) output from:

mysql -u patchwork -p -B -e "SELECT id, msgid FROM patchwork_patch" patchwork

I think this is all we need.


patches.txt.gz (744K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Maciej W. Rozycki
In reply to this post by Siddhesh Poyarekar-8
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
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
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
Reply | Threaded
Open this post in threaded view
|

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

Tom Tromey-2
In reply to this post by Siddhesh Poyarekar-8
>>>>> "Siddhesh" == Siddhesh Poyarekar <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
In reply to this post by Siddhesh Poyarekar-8
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
Reply | Threaded
Open this post in threaded view
|

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 <https://patchwork.kernel.org/> for temporary
hosting?  It already covers some non-kernel lists.
Reply | Threaded
Open this post in threaded view
|

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

Christian Brauner-2
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 <https://patchwork.kernel.org/> 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
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
On 08/12/19 5:51 pm, Christian Brauner wrote:
>> Maybe we can use <https://patchwork.kernel.org/> 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
Reply | Threaded
Open this post in threaded view
|

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 <https://patchwork.kernel.org/> 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
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
In reply to this post by Siddhesh Poyarekar-8
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
Reply | Threaded
Open this post in threaded view
|

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

Siddhesh Poyarekar-8
In reply to this post by Konstantin Ryabitsev
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
Reply | Threaded
Open this post in threaded view
|

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

Sergio Durigan Junior
In reply to this post by Siddhesh Poyarekar-8
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.

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/

12