On Wed, May 31, 2023 at 8:09 AM Han-Wen Nienhuys <hanw...@gmail.com> wrote:
> > > On Wed, May 31, 2023 at 3:56 PM David Kastrup <d...@gnu.org> wrote: > >> Han-Wen Nienhuys <hanw...@gmail.com> 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
