m/restriction would
provide a net benefit to the overall development process and experience.
If one of those premises, or the logical steps/deduction between them, is
flawed in some way, please let me know. Also, if somewhere in those three steps
I’ve suggested — explicitly or implicitly — that (e.g.)
Hi Graham,
> Thought experiment: suppose that a complete newcomer posts to the
> email list tomorrow, saying that he was interested in working on
>bug #5542 cross-staff slur hides text in eps backend
> (I picked randomly).
>
> Would anybody jump up and say "great! Let me help you get
>
On Wed, Feb 05, 2020 at 08:59:33PM -0500, Kieren MacMillan wrote:
> > LilyPond has had a lot of patches get dropped because
> > nobody feels comfortable reviewing / shepherding them.
>
> Seems to me like one solution to that problem might be a subtle
> variant on extreme programming: All
Hi Graham (et al.),
> LilyPond has had a lot of patches get dropped because
> nobody feels comfortable reviewing / shepherding them.
Seems to me like one solution to that problem might be a subtle variant on
extreme programming: All features/fixes must be signed out for "patch-ing" by
two
On Wed, Feb 05, 2020 at 12:11:48AM +0100, David Kastrup wrote:
> Han-Wen Nienhuys writes:
> > For context, I have a busy daytime job. I work 80% so I can set aside
> > a couple of hours of concentrated hacking time on Friday.
Yes. I expect that most people knowledgeable about lilypond code
are
have been mentioned for several options, but even
if there is nothing new, a systematic assessment could help
3. development process / code of conduct
a) number of stages from a proposed patch to a final change
b) decision process and who decides what
c) formal rules vs. consensus
I
"Jürgen Reuter" writes:
>Hi all,
>
>I fully agree with Han-Wen. I also could now and then (maybe once a
>week) set aside 2-3 hours work for lily. But the current development
>process really makes it hard for me to keep up submitting a patch (as
>
Kevin Barry writes:
> I don't know if lurkers' opinions count, but on the subject of potential
> replacements for Savannah/Sourceforge: I am part of a team that administer
> both Gerrit and Gitlab in-house deployments. If choosing between them I
> would advocate for Gitlab because it includes
Hi all,
> I don't know if lurkers' opinions count
I hope so, because I’m about to give another one… ;)
> Gerrit is a good code review tool, but for various reasons
> that may be our own fault, it is deeply unpopular where I work.
I know very few of these tools — my deepest version control
I don't know if lurkers' opinions count, but on the subject of potential
replacements for Savannah/Sourceforge: I am part of a team that administer
both Gerrit and Gitlab in-house deployments. If choosing between them I
would advocate for Gitlab because it includes issue tracking and CI/CD so
On Feb 5, 2020, at 06:57, David Kastrup wrote:
>
> Our current process is awkward technically, not because of the roles its
> human players assume.
+1(000)
For a long time, the LilyPond project has needed these:
1. more and better automation to reduce the load on the (amazingly
Thomas Morley writes:
> Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup :
>>
>> Han-Wen Nienhuys writes:
>>
>> >Rietveld and my local commits are not linked. If I change my commits, I
>> >update my commit message. I have to copy those changes out to Rietveld
>> > by
>> >
Hi all,
I fully agree with Han-Wen. I also could now and then (maybe once a
week) set aside 2-3 hours work for lily. But the current development
process really makes it hard for me to keep up submitting a patch (as
part of currently 11 commits (mostly small to medium ones
Han-Wen Nienhuys writes:
> On Wed, Feb 5, 2020 at 12:11 AM David Kastrup wrote:
>
>> Where commits do not belong to the same logical issue but are still
>> interdependent, they cannot be logically disentangled even using a
>> Git-specific tool like Gerrit.
>>
>
> Oh, but you can. You can review
Han-Wen Nienhuys writes:
> On Wed, Feb 5, 2020 at 10:23 AM Jonas Hahnfeld wrote:
>
>> I don't see why we need to have a final list of detailed points that we
>> all agree upon before sketching a process.
>
>
> I think it's a more systematic way of approaching the problem. The reason
> I'm doing
Am Mi., 5. Feb. 2020 um 00:12 Uhr schrieb David Kastrup :
>
> Han-Wen Nienhuys writes:
> >The review process leaves changes in an unclear state. If Werner says
> >LGTM, but then Dan and David have complaints, do I have to address the
> >comments, or is change already OK to go in?
Jonas Hahnfeld writes:
> That's not really my point, I agree that we should improve the process.
> I think everybody has a list of wishes such as yours, the major points
> from mine would be:
> * have less tools to work with (currently SF, Rietveld, Savannah)
> * use tools that agree on a
On Wed, Feb 5, 2020 at 10:23 AM Jonas Hahnfeld wrote:
> I don't see why we need to have a final list of detailed points that we
> all agree upon before sketching a process.
I think it's a more systematic way of approaching the problem. The reason
I'm doing it this way, is because I have a
On Wed, Feb 5, 2020 at 12:11 AM David Kastrup wrote:
> Where commits do not belong to the same logical issue but are still
> interdependent, they cannot be logically disentangled even using a
> Git-specific tool like Gerrit.
>
Oh, but you can. You can review the change as part of the dependent
Am Mittwoch, den 05.02.2020, 09:50 +0100 schrieb Han-Wen Nienhuys:
>
> >> We don't need to rehash that the current system sucks.
> >
> > This would also be my comment on the initial message: It's again saying
> > how bad the current process is. It would be far more constructive to
> > make a
den 05.02.2020, 00:11 +0100 schrieb David Kastrup:
> > Han-Wen Nienhuys <
> > hanw...@gmail.com
> > > writes:
> >
> > > My experiences with the current Lilypond development process.
> > >
> > > For context, I have a busy daytime job. I wo
Am Mittwoch, den 05.02.2020, 00:11 +0100 schrieb David Kastrup:
> Han-Wen Nienhuys <
> hanw...@gmail.com
> > writes:
>
> > My experiences with the current Lilypond development process.
> >
> > For context, I have a busy daytime job. I work 80% so I
Han-Wen Nienhuys writes:
> My experiences with the current Lilypond development process.
>
> For context, I have a busy daytime job. I work 80% so I can set aside
> a couple of hours of concentrated hacking time on Friday. When I am in
> my element, I can easily churn out
ral code reviews, here my take on the current
> development process. I wrote it as a google doc first, so you can also go
> here
>
> https://docs.google.com/document/d/1BSffzjiQKMTTmr988ezMbsJyfwT9S-rxGRbYSBTv3PM/edit
> for
> inline comments.
>
>
> Context:
>
>-
&
As promised in several code reviews, here my take on the current
development process. I wrote it as a google doc first, so you can also go
here
https://docs.google.com/document/d/1BSffzjiQKMTTmr988ezMbsJyfwT9S-rxGRbYSBTv3PM/edit
for
inline comments.
Context:
-
https
25 matches
Mail list logo
