lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LilyPond GSoC logistics


From: Werner LEMBERG
Subject: Re: LilyPond GSoC logistics
Date: Wed, 20 May 2020 07:39:51 +0200 (CEST)

Hello Owen,


> First, would it be possible to shift the schedule a week earlier?
> ASU classes start on August 20th, and it would not be ideal for me
> to still be working then.  I can take the rest of this week to
> familiarize myself with the codebase (I've already started doing
> that), and then we can start on Monday, if you're open to that.

this is fine.  Basically, it doesn't matter for me when you start or
stop; it's only GSoC that gives a rhythm.

> Second, just so you're aware, I may take a weekday or two off during
> the summer, but if I do, I'll make up for the lost time on weekends,
> so that shouldn't set the timetable back.

Again, I don't care :-) Most people work in bursts, and I won't
enforce any way of scheduled working.  The only thing that is both
useful and important is weekly reports to the list – even if you just
write that you weren't able to work because of this and that.  I
measure progress in git commits and educated questions to the list.

> Third, how often would you like to touch base?

What do you mean with 'base'?

> My thought is that I could send a weekly progress report to the
> mailing list to allow for others' input, but if you have a better
> idea, please let me know.

Yep, see above.

> Fourth, now that I have LilyDev up and running and can compile from
> source, what branch should I work from?

I suggest that you take current master.  To preserve your code within
LilyPond it probably makes sense if you put your code into a private
(but public) branch of the upstream lilypond repository (i.e., not a
gitlab clone of it), for example 'dev/lamb/GSoC-2020'.

> Should I periodically fetch changes to make sure my work stays
> compatible with current development?

Ideally, yes, but this is probably not an issue since there are only
few changes (if at all) to the code you are expected to work on.  So
rebasing can be delayed until you've reached a stage that you are
comfortable with.

> And should I be working off the new GitLab repository now that
> that's a thing?

Yes, we've moved.


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]