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 
> <[dak@gnu.org](mailto:dak@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