Le mercredi 31 mai 2023 à 16:09 +0200, Han-Wen Nienhuys a écrit :
> On Wed, May 31, 2023 at 3:56 PM David Kastrup
> <[d...@gnu.org](mailto:d...@gnu.org)> wrote:
>
> >
> > I think I disagree in this particular context because the commitment
> > from GSOC is a temporary one, and a fork is not a "
On Wed, May 31, 2023 at 8:09 AM Han-Wen Nienhuys wrote:
>
>
> On Wed, May 31, 2023 at 3:56 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > On Wed, May 31, 2023 at 5:12 AM Carl Sorensen <
>> carl.d.soren...@gmail.com>
>> > wrote:
>> >
>> >> After reading all of this, I believe I sh
On Wed, May 31, 2023 at 3:56 PM David Kastrup wrote:
> Han-Wen Nienhuys writes:
>
> > On Wed, May 31, 2023 at 5:12 AM Carl Sorensen >
> > wrote:
> >
> >> After reading all of this, I believe I should recommend to Jason that he
> >> not have his gsoc repository be on the main GitLab repository f
Han-Wen Nienhuys writes:
> On Wed, May 31, 2023 at 5:12 AM Carl Sorensen
> wrote:
>
>> After reading all of this, I believe I should recommend to Jason that he
>> not have his gsoc repository be on the main GitLab repository for two
>> reasons: 1) We really want the dev/ branches on GitLab to b
On Wed, May 31, 2023 at 5:12 AM Carl Sorensen
wrote:
> After reading all of this, I believe I should recommend to Jason that he
> not have his gsoc repository be on the main GitLab repository for two
> reasons: 1) We really want the dev/ branches on GitLab to be used only for
> merge requests; a
Developers,
In the past we used to have lots of dev/ branches in our git repository as
a place to store work in process.
IIUC, when we moved to GitLab as our main repository, we moved to a mode of
only putting up dev/ branches when they were ready for a merge request,
which prevented accumulation
