On Tue, May 07, 2024 at 16:17:24 +, Joseph Myers via Gcc wrote:
> I'd say we have two kinds of patch submission (= two kinds of pull request
> in a pull request workflow) to consider in the toolchain, and it's
> important that a PR-based system supports both of them well (and supports
> a
On Sat, 4 May 2024, Ben Boeckel via Gcc wrote:
> - every push is stored in a ghostflow-director-side unique ref
> (`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid
> forge-side garbage collection (especially problematic on Github;
> I've not noticed GitLab
On Thu, 2 May 2024, Fangrui Song wrote:
> > On the other hand, GitHub structures the concept of pull requests
> > around branches and enforces a branch-centric workflow. A pull request
> > centers on the difference (commits) between the base branch and the
> > feature branch. GitHub does not
On Sun, May 05, 2024 at 08:22:12 +0300, Benson Muite wrote:
> On 04/05/2024 22.56, Ben Boeckel via Overseers wrote:
> > As a fellow FOSS maintainer I definitely appreciate the benefit of being
> > email-based (`mutt` is far better at wrangling notifications from
> > umpteen places than…well
On 04/05/2024 22.56, Ben Boeckel via Overseers wrote:
> On Wed, May 01, 2024 at 23:26:18 +0200, Mark Wielaard wrote:
>> On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
>
>> At the moment though the only thing people seem to agree on is that
>> any system will be based on git. So
On Wed, May 01, 2024 at 23:26:18 +0200, Mark Wielaard wrote:
> On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
> > Do you (or others) have any thoughts about GitLab FOSS?
>
> The gitlab "community edition" still feels not very much "community".
> We could run our own instance, but
Pedro Alves via Overseers writes:
> When GDB upstream tried to use gerrit, I found it basically impossible to
> follow development, given the volume... The great thing with email is the
> threading of discussions. A discussion can fork into its own subthread, and
> any
> sane email client
On Thu, May 2, 2024 at 8:35 AM Pedro Alves wrote:
>
> On 2024-05-01 22:04, Simon Marchi wrote:
> > The Change-Id trailer works very well for Gerrit: once you have the hook
> > installed you basically never have to think about it again, and Gerrit
> > is able to track patch versions perfectly
On 2024-05-01 22:04, Simon Marchi wrote:
> The Change-Id trailer works very well for Gerrit: once you have the hook
> installed you basically never have to think about it again, and Gerrit
> is able to track patch versions perfectly accurately. A while ago, I
> asked patchwork developers if they
On 2024-05-01 22:26, Mark Wielaard wrote:
> For now I am cleaning up Sergio's gerrit setup and upgrading it to the
> latest version, so people can at least try it out. Although I must
> admit that I seem to be the only Sourcewware PLC member that believes
> this is very useful use of our
On 5/2/24 2:47 AM, Richard Biener via Overseers wrote:> We'd only know for sure
if we try. But then I'm almost 100% sure that
> having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA
> I am using for "quick" patch review. It might be comparable to the
> review parts I do in
On 5/1/2024 10:26 PM, Mark Wielaard wrote:
Hi Jason,
On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
On 5/1/24 12:15, Jeff Law wrote:
We're currently using patchwork to track patches tagged with
RISC-V.� We don't do much review with patchwork.� In that model
patchwork
Hi Jeff,
On Wed, 2024-05-01 at 15:38 -0600, Jeff Law wrote:
> What works well? If you've wired up some CI bits, it's is extremely
> useful to test an under development patch. Develop, push a branch,
> raise an MR. At that point the CI system kicks in. Subsequent pushes
> to the branch
On Wed, May 1, 2024 at 11:48 PM Richard Biener
wrote:
>
> We'd only know for sure if we try. But then I'm almost 100% sure that
> having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA
> I am using for "quick" patch review. It might be comparable to the
> review parts I do in
On Wed, May 1, 2024 at 11:41 PM Jeff Law via Gcc wrote:
>
>
>
> On 5/1/24 2:04 PM, Jason Merrill wrote:
> > On 5/1/24 12:15, Jeff Law wrote:
> >>
> >>
> >> On 4/22/24 9:24 PM, Tom Tromey wrote:
> >>> Jason> Someone mentioned earlier that gerrit was previously tried
> >>> Jason> unsuccessfully.
>
> Do you (or others) have any thoughts about GitLab FOSS?
Dunno about the FOSS edition specifically, but I've used many review
tools in anger in the last 5 years: github, gitlab, gerrit, phabricator,
and a couple that ran in bugzilla ("MozReview", not sure if it had some
other name; and a second
On Wednesday, May 01 2024, Mark Wielaard wrote:
[...]
> But the part that interests me most is the self-registration part that
> Sergio setup. I believe we will need that for whatever system we end
> up with to make it as easy to contribute as it is with email.
>
On 5/1/24 2:04 PM, Jason Merrill wrote:
On 5/1/24 12:15, Jeff Law wrote:
On 4/22/24 9:24 PM, Tom Tromey wrote:
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
into the
Hi Jason,
On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:
> On 5/1/24 12:15, Jeff Law wrote:
> >We're currently using patchwork to track patches tagged with
> >RISC-V. We don't do much review with patchwork. In that model
> >patchwork ultimately just adds overhead as I'm
On 2024-05-01 16:53, Tom Tromey via Overseers wrote:
> Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997
> Mark> We really should automate this. There are several people running
> Mark> scripts by hand. The easiest would be to simply run it from a git
> Mark> hook. patchwork
Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997
Mark> We really should automate this. There are several people running
Mark> scripts by hand. The easiest would be to simply run it from a git
Mark> hook. patchwork comes with a simple script that just calculates the
Mark> hash
Hi Jonathan,
On Wed, May 01, 2024 at 08:38:26PM +0100, Jonathan Wakely wrote:
> On Wed, 1 May 2024 at 20:19, Jeff Law via Gcc wrote:
> > We're currently using patchwork to track patches tagged with RISC-V. We
> > don't do much review with patchwork. In that model patchwork ultimately
> > just
On 5/1/24 12:15, Jeff Law wrote:
On 4/22/24 9:24 PM, Tom Tromey wrote:
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
into the traditional gdb development style, having it send
On Wed, 1 May 2024 at 20:19, Jeff Law via Gcc wrote:
>
>
>
> On 4/22/24 9:24 PM, Tom Tromey wrote:
> > Jason> Someone mentioned earlier that gerrit was previously tried
> > Jason> unsuccessfully.
> >
> > We tried it and gdb and then abandoned it. We tried to integrate it
> > into the traditional
On 4/22/24 9:24 PM, Tom Tromey wrote:
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
into the traditional gdb development style, having it send email to
gdb-patches. I found these
On Tuesday, April 23, 2024 5:26 PM, Simon Marchi wrote:
> On 2024-04-23 11:08, Tom Tromey wrote:
> >> Indeed. Though Patchwork is another option for patch tracking, that
> >> glibc seem to be having success with.
> >
> > We tried this in gdb as well. It was completely unworkable -- you have
> >
On 2024-04-23 11:08, Tom Tromey wrote:
>> Indeed. Though Patchwork is another option for patch tracking, that
>> glibc seem to be having success with.
>
> We tried this in gdb as well. It was completely unworkable -- you have
> to manually clear out the patch queue, meaning it's normally
> Indeed. Though Patchwork is another option for patch tracking, that
> glibc seem to be having success with.
We tried this in gdb as well. It was completely unworkable -- you have
to manually clear out the patch queue, meaning it's normally full of
patches that already landed. I know glibc
On Tue, Apr 23, 2024 at 2:32 AM Richard Earnshaw (lists) via Gcc
wrote:
>
> I've been forced to use gerrit occasionally. I hate it. No, I LOATHE it.
> The UI is anything but intuitive with features hidden behind unobvious
> selections. IMO It's not a tool for a casual developer, which makes
* Jason Merrill:
> On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote:
>
> > "Frank" == Frank Ch Eigler writes:
>
> >> [...] I suggest that a basic principle for such a system is that it
> >> should be *easy* to obtain and maintain a local copy of the history
> >> of all pull requests.
On 23/04/2024 09:56, Mark Wielaard wrote:
> Hi,
>
> On Mon, Apr 22, 2024 at 11:51:00PM -0400, Jason Merrill wrote:
>> On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote:
>>> Jason> Someone mentioned earlier that gerrit was previously tried
>>> Jason> unsuccessfully.
>>>
>>> We tried it and gdb
On 23/04/2024 04:24, Tom Tromey wrote:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
>
> We tried it and gdb and then abandoned it. We tried to integrate it
> into the traditional gdb development style, having it send email to
> gdb-patches. I
Hi,
On Mon, Apr 22, 2024 at 11:51:00PM -0400, Jason Merrill wrote:
> On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote:
> > Jason> Someone mentioned earlier that gerrit was previously tried
> > Jason> unsuccessfully.
> >
> > We tried it and gdb and then abandoned it. We tried to integrate it
>
Tom Tromey via Overseers writes:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
>
> We tried it and gdb and then abandoned it. We tried to integrate it
> into the traditional gdb development style, having it send email to
> gdb-patches. I found
On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
>
> We tried it and gdb and then abandoned it. We tried to integrate it
> into the traditional gdb development style, having it send email to
>
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
into the traditional gdb development style, having it send email to
gdb-patches. I found these somewhat hard to read and in the end we
On 2024-04-22 22:55, Jason Merrill via Overseers wrote:
> On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote:
>
>>> "Frank" == Frank Ch Eigler writes:
>>
[...] I suggest that a basic principle for such a system is that it
should be *easy* to obtain and maintain a local copy of the
On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote:
> > "Frank" == Frank Ch Eigler writes:
>
> >> [...] I suggest that a basic principle for such a system is that it
> >> should be *easy* to obtain and maintain a local copy of the history
> >> of all pull requests. That includes all
Hi -
> Would it be possible for gitsigur to support signing commits with ssh
> keys as well as gpg? Git supports this, and it's much easier for
> everybody than having to set up gpg. [...]
It would save some effort, but OTOH plenty of people have gpg keys
too, and the common desktop key agents
> "Frank" == Frank Ch Eigler writes:
>> [...] I suggest that a basic principle for such a system is that it
>> should be *easy* to obtain and maintain a local copy of the history
>> of all pull requests. That includes all versions of a pull request,
>> if it gets rebased, and all versions
On Mon, 22 Apr 2024, Mark Wielaard wrote:
> > A system that uses git as the source of
> > truth for all the pull request data and has refs through which all this
> > can be located (with reasonably straightforward, documented formats for
> > the data, not too closely tied to any particular
Hi Joseph,
On Thu, 2024-04-18 at 15:56 +, Joseph Myers wrote:
> On Thu, 18 Apr 2024, Mark Wielaard wrote:
>
> > But we like to get more feedback on what people really think a
> > "pull-request" style framework should look like. We used to have a
> > gerrit setup which wasn't really popular.
On Thu, 18 Apr 2024 at 07:06, Thomas Koenig via Gcc wrote:
>
> Am 18.04.24 um 01:27 schrieb Mark Wielaard:
> > We also should make sure that all generated files (either in git or in
> > the release/snapshot tar balls) can be reliably and reproducibly
> > regenerated. This also helps the
On Thu, Apr 18, 2024 at 5:38 PM Frank Ch. Eigler wrote:
>
> Hi -
>
> > [...] I suggest that a basic principle for such a system is that it
> > should be *easy* to obtain and maintain a local copy of the history
> > of all pull requests. That includes all versions of a pull request,
> > if it
On Thu, 18 Apr 2024, Frank Ch. Eigler via Gcc wrote:
> Hi -
>
> > [...] I suggest that a basic principle for such a system is that it
> > should be *easy* to obtain and maintain a local copy of the history
> > of all pull requests. That includes all versions of a pull request,
> > if it gets
Hi -
> [...] I suggest that a basic principle for such a system is that it
> should be *easy* to obtain and maintain a local copy of the history
> of all pull requests. That includes all versions of a pull request,
> if it gets rebased, and all versions of comments, if the system
> allows
On Thu, 18 Apr 2024, Mark Wielaard wrote:
> But we like to get more feedback on what people really think a
> "pull-request" style framework should look like. We used to have a
> gerrit setup which wasn't really popular. And we already have a
> sourcehut mirror that can be used to turn your
On Thu, Apr 18, 2024 at 11:15 AM FX Coudert wrote:
>
> > I regenerate auto* files from time to time for libgfortran. Regenerating
> > them has always been very fragile (using --enable-maintainer-mode),
> > and difficult to get right.
>
> I have never found them difficult to regenerate, but if you
Hi,
On Thu, 18 Apr 2024 at 10:15, FX Coudert wrote:
>
> > I regenerate auto* files from time to time for libgfortran. Regenerating
> > them has always been very fragile (using --enable-maintainer-mode),
> > and difficult to get right.
>
> I have never found them difficult to regenerate, but if
> I regenerate auto* files from time to time for libgfortran. Regenerating
> them has always been very fragile (using --enable-maintainer-mode),
> and difficult to get right.
I have never found them difficult to regenerate, but if you have only a non
maintainer build, it is a pain to have to
Am 18.04.24 um 01:27 schrieb Mark Wielaard:
We also should make sure that all generated files (either in git or in
the release/snapshot tar balls) can be reliably and reproducibly
regenerated. This also helps the (pre-commit) CI buildbots. We already
have the autoregen bots for gcc and
51 matches
Mail list logo
