Re: Use of dev/ branches in Gitlab and GSOC

[Jean Abou Samra]

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 "permanent home for
> > work that is not merged" in the GSOC context because it can just
> > disappear along with the original account.
> > 
> > That does not mean that I am against the use of forks in general.  But
> > for "unfinished work passing into general project reponsibility",
> > maintaining it under accounts with a possibly diverging interest (where
> > deletion is an extreme form of a diverging interest) does not appear
> > like the best policy to me.
> > 
> 
> 
> To me, code passes into "general project responsibility" by being merged
> into the project. The requirement to keep code alive, is that something
> that the student agrees to with GSOC or do we agree with GSOC on this?
>



I wouldn't make a big deal of this. Whether the branch is on the main
repository or on a fork, it is easily accessible for other people until
it gets merged. We've generally moved away from pushing branches on the
main repository in order to void the accumulation of stale branches for
abandoned MRs where the author forgot to delete the branch. For longer-lived
branches like the GSoC one, this is not a significant problem. We don't
have hundreds of GSoC projects per year.

One could even argue it would be beneficial to keep it around visibly in the 
main
repository in case it's not ready for merging at the time the project ends, like
the dev/lamb/GSoC-2020 branch that I have been looking into recently. But in 
any case,
I think we should really try hard to plan properly to avoid situations
like GSoC 2020 where the work doesn't end up merged (like a couple before as
well, something with chords and another one with cross-staff spanners IIRC, but
those weren't my times).

Bottom line: I don't think this matters much.


signature.asc
Description: This is a digitally signed message part

Re: Use of dev/ branches in Gitlab and GSOC

[Carl Sorensen]

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 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; and 2) We want the dev/ branches on GitLab to be
>> temporary,
>> >> but GSOC wants a permanent repository of the student's work.
>> >>
>> >> Am I making a mistake in giving Jason this advice?  I'd welcome any
>> >> comments.
>> >>
>> >
>> > I think you are right. Creating a fork is slightly more cognitive
>> > overhead, but it's not prohibitive, and if GSOC wants a permanent home
>> > for work that is not merged, then the fork is the right place.
>>
>> I think I disagree in this particular context because the commitment
>> from GSOC is a temporary one, and a fork is not a "permanent home for
>> work that is not merged" in the GSOC context because it can just
>> disappear along with the original account.
>>
>> That does not mean that I am against the use of forks in general.  But
>> for "unfinished work passing into general project reponsibility",
>> maintaining it under accounts with a possibly diverging interest (where
>> deletion is an extreme form of a diverging interest) does not appear
>> like the best policy to me.
>>
>
> To me, code passes into "general project responsibility" by being merged
> into the project. The requirement to keep code alive, is that something
> that the student agrees to with GSOC or do we agree with GSOC on this?
>
> I think there is no responsibility to keep code alive.  But at the end of
GSOC the student must submit a record of his/her code contributions,
whether or not they are merged into the project code.  I don't believe
there is any responsibility for LilyPond to maintain the repository.

Thanks,

Carl

Re: Use of dev/ branches in Gitlab and GSOC

[Han-Wen Nienhuys]

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 for two
> >> reasons:  1) We really want the dev/ branches on GitLab to be used only
> for
> >> merge requests; and 2) We want the dev/ branches on GitLab to be
> temporary,
> >> but GSOC wants a permanent repository of the student's work.
> >>
> >> Am I making a mistake in giving Jason this advice?  I'd welcome any
> >> comments.
> >>
> >
> > I think you are right. Creating a fork is slightly more cognitive
> > overhead, but it's not prohibitive, and if GSOC wants a permanent home
> > for work that is not merged, then the fork is the right place.
>
> I think I disagree in this particular context because the commitment
> from GSOC is a temporary one, and a fork is not a "permanent home for
> work that is not merged" in the GSOC context because it can just
> disappear along with the original account.
>
> That does not mean that I am against the use of forks in general.  But
> for "unfinished work passing into general project reponsibility",
> maintaining it under accounts with a possibly diverging interest (where
> deletion is an extreme form of a diverging interest) does not appear
> like the best policy to me.
>

To me, code passes into "general project responsibility" by being merged
into the project. The requirement to keep code alive, is that something
that the student agrees to with GSOC or do we agree with GSOC on this?

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Use of dev/ branches in Gitlab and GSOC

[David Kastrup]

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 be used only for
>> merge requests; and 2) We want the dev/ branches on GitLab to be temporary,
>> but GSOC wants a permanent repository of the student's work.
>>
>> Am I making a mistake in giving Jason this advice?  I'd welcome any
>> comments.
>>
>
> I think you are right. Creating a fork is slightly more cognitive
> overhead, but it's not prohibitive, and if GSOC wants a permanent home
> for work that is not merged, then the fork is the right place.

I think I disagree in this particular context because the commitment
from GSOC is a temporary one, and a fork is not a "permanent home for
work that is not merged" in the GSOC context because it can just
disappear along with the original account.

That does not mean that I am against the use of forks in general.  But
for "unfinished work passing into general project reponsibility",
maintaining it under accounts with a possibly diverging interest (where
deletion is an extreme form of a diverging interest) does not appear
like the best policy to me.

-- 
David Kastrup

Re: Use of dev/ branches in Gitlab and GSOC

[Han-Wen Nienhuys]

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; and 2) We want the dev/ branches on GitLab to be temporary,
> but GSOC wants a permanent repository of the student's work.
>
> Am I making a mistake in giving Jason this advice?  I'd welcome any
> comments.
>

I think you are right. Creating a fork is slightly more cognitive overhead,
but it's not prohibitive, and if GSOC wants a permanent home for work that
is not merged, then the fork is the right place.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Use of dev/ branches in Gitlab and GSOC

[Carl Sorensen]

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 of old dev/ branches.

Jason has just started his GSOC work and is jumping right into it.   He's
put up a branch dev/ljyip/gsoc2023-autobeaming
 on
Gitlab.  But it's not ready for a merge request.

I've not made any merge requests since the move to GitLab.  I've reviewed
the CG, and looked at
https://lists.gnu.org/archive/html/lilypond-devel/2023-01/msg00262.html
and https://lists.gnu.org/archive/html/lilypond-devel/2022-09/msg0.html

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; and 2) We want the dev/ branches on GitLab to be temporary,
but GSOC wants a permanent repository of the student's work.

Am I making a mistake in giving Jason this advice?  I'd welcome any
comments.

Thanks,

Carl