This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Actually setting up patchwork on sourceware

Hash: SHA1

On 04/02/2014 01:54 AM, Siddhesh Poyarekar wrote:
> Hi,
> In an attempt to make progress on the subject of choosing a tool to
> track patches in glibc, I had created a patchwork instance on my
> server[1] for people to try their hand at it and to see what kind of
> changes we need to the tool to suit our requirements.  A few of us
> signed up and tried their hand at using patchwork and so far there
> haven't been any complaints.
> Following Carlos' suggestion, I created a wiki document to define a
> workflow around patchwork[2], which got some feedback and subsequent
> editing.
> Since there haven't been any further questions or comments on either
> the choice of tool or the workflow, I propose that we create the final
> instance on sourceware and start using it.  Does anyone have any
> objections to it?
> I volunteer to help with setup and migration, but I don't have access
> to the sourceware server beyond the glibc git repo, so I'd appreciate
> help on that end.  The setup and migration sequence:
> - Set up the patchwork application and database on sourceware and
>   configure it to use SSL by default.
> - Migrate earlier patches and state from
> - Subscribe a user for patchwork to libc-alpha
> - Have all maintainers sign up

I strongly suggest we move ahead with this! :-)

- From my perspective it has been a smashing success. I use Patchwork
daily to look for the oldest patches that need review. I keep Patchwork
updated based on my reviews, and I think it will only help the community.

With my Red Hat on I look for Red Hat patches to review.

With my FSF hat on I review the oldest patches in the tracker that need review.

Is this going to help us move towards a working bugzilla procedure? Yes
it will. If we want the bugzilla procedure to work smoothly we first need
patch review and commits to work smoothly otherwise we won't get the
bugs fixed (which is really what counts).

There have been suggestions that glibc's and binutils' Patchwork instances
could be hosted at Oz Labs, but my preference is to keep all of the glibc
services under to make it easier to keep the services in
sync (registration, ml, bugzilla, git, patchwork, wiki), working together,
and supported by one team. The only service we presently redirect is
web and that goes to the FSF glibc website and was done on purpose because
we are a GNU project.

> Siddhesh
> [1]
> [2]


Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]