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? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
