Urs Liska writes:
You are doing code reviews through a web interface already, isn't it?
And this is because that's a quite natural way to communicate, comment
on code etc. You can't do _that_ with plain Git.
To me, this is one the most unnatural and therefore annoying parts of
current
Jan Nieuwenhuizen jann...@gnu.org writes:
Urs Liska writes:
You are doing code reviews through a web interface already, isn't it?
And this is because that's a quite natural way to communicate, comment
on code etc. You can't do _that_ with plain Git.
To me, this is one the most unnatural
Am 18.09.2013 09:46, schrieb David Kastrup:
Jan Nieuwenhuizen jann...@gnu.org writes:
Urs Liska writes:
You are doing code reviews through a web interface already, isn't it?
And this is because that's a quite natural way to communicate, comment
on code etc. You can't do _that_ with plain
Urs Liska u...@openlilylib.org writes:
Am 18.09.2013 09:46, schrieb David Kastrup:
Well, it facilitates looking at stuff in context (though that's fairly
trivial to do by actually applying the patch in a cloned repository, and
in-file-system clones of git repositories are _really_ cheap).
2013/9/18 David Kastrup d...@gnu.org
The one area where I'd consider a web interface a possibly good tradeoff
of matching tools to skills would be translation work: that could/should
be a lot more crowdsourced than it is now. It turns out that organizing
and tracking incremental translation
2013/9/17 David Kastrup d...@gnu.org:
And yet [Linus] wrote Linux instead of using the best available tool for the
job: he already had a copy of Minix, interactive UNIX was quite
affordable, and other cheap versions came around.
I'm not sure, but from what i've read it seems that Linus
2013/9/18 David Kastrup d...@gnu.org:
Comparing the amount of code actually getting reviewed and the amount of
development getting done, the Linux kernel does not seem to suffer all
that badly from working with a patch/mail-centric [review] workflow.
Of course there are some reasons that
2013/9/18 David Kastrup d...@gnu.org:
The one area where I'd consider a web interface a possibly good
tradeoff of matching tools to skills would be translation work: that
could/should be a lot more crowdsourced than it is now. It turns out
that organizing and tracking incremental translation
Janek Warchoł janek.lilyp...@gmail.com writes:
2013/9/18 David Kastrup d...@gnu.org:
Comparing the amount of code actually getting reviewed and the amount of
development getting done, the Linux kernel does not seem to suffer all
that badly from working with a patch/mail-centric [review]
Janek Warchoł janek.lilyp...@gmail.com writes:
Just a reminder: nobody's talking about replacing everything with
web-based interfaces. I think that the discussion is about providing
both web-based and other interfaces.
And i know at least one potential serious contributor that is driven
Urs Liska:
Am 17.09.2013 18:21, schrieb David Kastrup:
Janek Warchołjanek.lilyp...@gmail.com writes:
2013/9/16 David Kastrupd...@gnu.org:
So the question is what we should be telling the Savannah operators
to make working on GNU projects using Git more feasible.
Here you go:
A web
k...@aspodata.se (Karl Hammar) writes:
What's natural is different for different people.
Web interfaces are not natural for me, to the contrary, for me
they appear constrained.
The main question is what's natural to those people we can have a
reasonable expectation to be working on LilyPond.
2013/9/17 Urs Liska u...@openlilylib.org:
But as far as I've understood, code doesn't get into upstream master that
way anyway, there is the Rietveld code review stage in between?
How do commits (from developers) actually end up in master?
Are they a) pushed to some branch, the diff uploaded
2013/9/18 Janek Warchoł janek.lilyp...@gmail.com:
2013/9/17 Urs Liska u...@openlilylib.org:
But as far as I've understood, code doesn't get into upstream master that
way anyway, there is the Rietveld code review stage in between?
How do commits (from developers) actually end up in master?
Am 18.09.2013 14:28, schrieb Janek Warchoł:
2013/9/18 Janek Warchoł janek.lilyp...@gmail.com:
2013/9/17 Urs Liska u...@openlilylib.org:
But as far as I've understood, code doesn't get into upstream master that
way anyway, there is the Rietveld code review stage in between?
How do commits (from
Urs Liska u...@openlilylib.org writes:
Am 18.09.2013 14:28, schrieb Janek Warchoł:
2013/9/18 Janek Warchoł janek.lilyp...@gmail.com:
2013/9/17 Urs Liska u...@openlilylib.org:
But as far as I've understood, code doesn't get into upstream master that
way anyway, there is the Rietveld code
2013/9/17 David Kastrup d...@gnu.org:
Now basically we have to split these into two different sets of
requirements: Savannah does not provide accounts or services to the
general public; its services will be restricted to actual developers.
But what you list above mostly is _not_ related to
Janek Warchoł writes:
[..] since the most important thing in my opinion is how contributors
can interact with the main repository.
Currently it is, and that's also the next most important concept to
drop and move to a distributed workflow, for some of those reasons,
see
LGTM
https://codereview.appspot.com/13373054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/13352053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
- Original Message -
From: David Kastrup d...@gnu.org
To: Urs Liska u...@openlilylib.org
Cc: Julien Rioux julien.ri...@gmail.com; LilyPond Developmet Team
lilypond-devel@gnu.org; Han-Wen Nienhuys hanw...@gmail.com
Sent: Wednesday, September 18, 2013 1:37 PM
Subject: Re: we now have
2013/9/18 Phil Holmes m...@philholmes.net:
- Original Message - From: David Kastrup d...@gnu.org
Urs Liska u...@openlilylib.org writes:
When review is finished prepare a patch file (or series of patch
files) and find someone with push access whom I can send it to?
Yup.
Strictly,
:(
2013/9/17 David Kastrup d...@gnu.org:
David Kastrup d...@gnu.org writes:
This is a reminder that next weekend, Sept 20th to 24th, there will be a
LilyPond developer and user meeting in Waltrop, Germany.
Ok, the current possible participant list would look like the following:
Jan, Janek,
Hello,
Seems I am back on-line. Thanks for filling in David et al.
*Countdown -- September 21st -- 06:00 GMT* *
* *
* *
* *
*
3495
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode86
Documentation/changes.tely:86: of the clef and key signature by default.
As in previous
https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
https://codereview.appspot.com/7005056/diff/35015/Documentation/learning/tweaks.itely#newcode2987
Documentation/learning/tweaks.itely:2987: \override
Reviewers: J_lowe, thomasmorley651, Mark Polesky,
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/13300048/diff/9001/Documentation/changes.tely#newcode86
Documentation/changes.tely:86: of the
On 2013/09/18 23:45:37, Mark Polesky wrote:
I think we should stop using the `#' for scheme numbers.
But when it is time to make that change, we would make the change over
all the documentation at once.
https://codereview.appspot.com/7005056/
Folks,
consider this snippet (image attached):
\header {
title = title
opus = opus
composer = composer
copyright =
footer =
tagline =
}
\markup { top1 }
\markup { top2 }
\markup { top3 }
\score { c''1 }
I would expect that `opus' appears vertically
29 matches
Mail list logo
