PATCHES - Countdown to June 2
Here is the current countdown report.
The next countdown will begin on May 2nd.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!2024 Fix TupletNumber.direction default callback - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/2024
Countdown:
!2027 \initialContextFrom music - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/2027
!2026 Draft: binaries: Bump Fontconfig and BDWGC - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/2026
!2025 Fix misaligned center stems for {black,semi}petrucci noteheads
(#6262) - Jason Yip
https://gitlab.com/lilypond/lilypond/-/merge_requests/2025
!2023 Fix spurious change clef - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/2023
!2020 Remove the \text markup command - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/2020
!2019 Update font documentation - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/2019
Review:
No patches in Review at this time.
New:
No patches in New at this time.
Waiting:
!1810 Let \rhythm markup derive from current layout - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/1810
Cheers,
Colin
Re: Use of dev/ branches in Gitlab and GSOC
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
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
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
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
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
