> From: Joseph Myers
> Sent: Wednesday, September 25, 2024 10:46 PM
>
> On Wed, 25 Sep 2024, Jiang, Haochen via Gcc wrote:
>
> > The potential issue might be the PR will be closed after merging, which
> > might
> > be flooded in history if the regression is not fixed with the PR forgotten
> >
On Wed, 25 Sep 2024, Jiang, Haochen via Gcc wrote:
> The potential issue might be the PR will be closed after merging, which might
> be flooded in history if the regression is not fixed with the PR forgotten to
> be
> reopened. I am not sure the reopen could be automatically done. If it could,
> From: Joseph Myers
> Sent: Wednesday, September 25, 2024 12:43 AM
>
> On Tue, 24 Sep 2024, Jiang, Haochen via Gcc wrote:
>
> Where projects have existing pre-commit CI that puts CI results in
> patchwork based on patches processed there, I hope such CI would be
> updated to work with pull requ
On Tue, 24 Sep 2024, Jiang, Haochen via Gcc wrote:
> I am running regression tests on x86_64 and sending the regressions to
> gcc-regression mailing thread, will I need to send to another place or
> using another API to do that?
I don't expect use of pull requests to change anything about existin
> From: Joseph Myers
> Sent: Thursday, September 19, 2024 11:51 PM
>
Hi Jospeh,
Thank for your overall introduction on the scope of the future PR
system. It will help the patches not flooded in mails. And keep merging
what we have got in PRs to the right branch to avoid some accidents.
I have
On Mon, 23 Sept 2024 at 19:00, Eric Gallager via Gcc wrote:
>
> On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc wrote:
> >
> > [For the fortran people: Discussion on gcc@]
> >
> > Just a general remark.
> >
> > There are people, such as myself, who regularly mess up
> > their git repositori
Thomas Koenig writes:
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I mana
On Mon, Sep 23, 2024 at 8:09 AM Thomas Koenig via Gcc wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The
> On 23 Sep 2024, at 15:33, Jonathan Wakely wrote:
>
> On Mon, 23 Sept 2024 at 14:36, enh wrote:
>>
>> it doesn't make the patch _management_ problem better ("now i have two
>> problems"), but https://github.com/landley/toybox takes the "why not both?"
>> approach --- you can use pull reque
On Mon, 23 Sept 2024 at 16:20, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > The discussion is about how we do patch submission and patch review.
> > The GitHub pull request workflow is widely seen as simpler than our
> > current email-based workflow (not everybody agrees, of course). The
> >
* Jonathan Wakely:
> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not rais
On Mon, 23 Sep 2024, enh via Gcc wrote:
> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use the ma
On Mon, 23 Sep 2024, Richard Earnshaw (lists) via Gcc wrote:
> One thing we must do, however, is break requirements into a number of
> categories: must haves (red lines, we can't transition without this); should
> haves (important, but we can likely find acceptable work-arounds); and would
> like
On Mon, 23 Sept 2024 at 14:36, enh wrote:
>
> it doesn't make the patch _management_ problem better ("now i have two
> problems"), but https://github.com/landley/toybox takes the "why not both?"
> approach --- you can use pull requests if you grew up with/adapted to
> git/github, or you can use
it doesn't make the patch _management_ problem better ("now i have two
problems"), but https://github.com/landley/toybox takes the "why not both?"
approach --- you can use pull requests if you grew up with/adapted to
git/github, or you can use the mailing list otherwise ... taking into
account that
On Mon, 23 Sept 2024 at 13:09, Thomas Koenig via Gcc wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing
I highly recommend
On 19/09/2024 16:51, Joseph Myers via Gcc wrote:
1. Introduction
This message expands on my remarks at the Cauldron (especially the
patch review and maintenance BoF, and the Sourceware infrastructure
BoF) regarding desired features for a system providing pull request
functionality (patch submiss
On Mon, Sep 23, 2024 at 8:08 AM Thomas Koenig via Gdb
wrote:
>
> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The
[For the fortran people: Discussion on gcc@]
Just a general remark.
There are people, such as myself, who regularly mess up
their git repositories because they have no mental model
of what git is doing (case in point: The Fortran unsigned
branch, which I managed to put into an unrepairable state
Carlos O'Donell writes:
> On 9/19/24 11:51 AM, Joseph Myers wrote:
>> 1. Introduction
>
> Thanks for writing this up!
>
> [...]
> Agreed.
>
I just want to say the same. My sentiments match Carlos.
On Fri, 20 Sep 2024, Matt Rice via Gcc wrote:
> To me though it is nice being able to edit the PR cover letter
> directly in the editor, and do the pull-request using command line
> tools.
In the common case of a single-commit PR without dependencies, it seems
reasonable to follow the practice t
On Fri, 20 Sep 2024, Carlos O'Donell via Gcc wrote:
> > (e) All existing pre-commit checks from hooks should be kept in some
> > form, to maintain existing invariants on both tree and commit contents
> > (some hook checks make sure that commits don't have commit messages
> > that would cause other
On Thu, Sep 19, 2024 at 3:52 PM Joseph Myers via Gdb
wrote:
>
> 1. Introduction
>
> This message expands on my remarks at the Cauldron (especially the
> patch review and maintenance BoF, and the Sourceware infrastructure
> BoF) regarding desired features for a system providing pull request
> func
On 9/19/24 11:51 AM, Joseph Myers wrote:
> 1. Introduction
Thanks for writing this up!
> This message expands on my remarks at the Cauldron (especially the
> patch review and maintenance BoF, and the Sourceware infrastructure
> BoF) regarding desired features for a system providing pull request
>
1. Introduction
This message expands on my remarks at the Cauldron (especially the
patch review and maintenance BoF, and the Sourceware infrastructure
BoF) regarding desired features for a system providing pull request
functionality (patch submission via creating branches that are then
proposed us
25 matches
Mail list logo
