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 su
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 collecti
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 em
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 basical
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 th
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 i
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 will
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 accur
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 w
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 resources.
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 th
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 ulti
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 trigg
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 o
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.
> https://blog.sergiodj.net/posts/in
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 traditional
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 constantl
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 a
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 a
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 email
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 s
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
> > t
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 full
> 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 has
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 and
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 found
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 thes
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
> gdb-patc
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
agre
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 version
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 su
> "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 o
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 im
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. A
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 (pre-commi
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 get
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 re
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 editin
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 "pull-r
Am Donnerstag, dem 18.04.2024 um 14:01 +0200 schrieb Tobias Burnus:
> Hi Janne,
>
> Janne Blomqvist wrote:
> > back when I was active I did think about this
> > issue. IMHO the best of my ideas was to convert these into C++
> > templates.
I haven't looked at libgfortran but I didn't find it probl
Hi Janne,
Janne Blomqvist wrote:
back when I was active I did think about this
issue. IMHO the best of my ideas was to convert these into C++
templates.
I think this will work – but we have to be super careful:
With C++, there is the problem that we definitely do not want to add
dependency o
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 yo
> 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 make
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 binutils-g
53 matches
Mail list logo
