Re: critical issues

[James]

hello,

On 3 Jan 2012, at 22:26, Janek Warchoł <address@hidden> wrote:

> Hi Luke,
> 
> nice to see you joining the discussion :)
> 
> W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński
> <address@hidden> napisał:
>>> That's like +1111 from me!
>>> In general, i agree that we should think in a more 'release-oriented'
>>> way ("last stable release was half a year ago, so we should make
>>> another one, so i'm fixing whatever needs to be fixed to make this
>>> possible") instead of 'free coding' way ("i care about this issue,
>>> i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
>>> stable release before an obstruction occurs!").  To do so, we would
>>> have to work more as a team, less independently.  How can we achieve
>>> that if GOP7 showed that we don't want to?
>> 
>> and:
>> 
>>>> And we better be in a position to provide answers,
>>>> since there is no more effective way to spend our time than on getting
>>>> more people to spend their time, and love, and interest.
>> 
>> Regarding all those fragments of Janek's and David's emails: For some time I
>> have been observing how bugs are being fixed in Lilypond and spent some time
>> on conversations with Janek.
>> For me there is almost no team work in Lilypond - only a bunch of geek
>> trying to fix some issues, but without a leader who coordinates all actions.
> 
> I might have given you a wrong impression, i don't think its really
> that bad.  There is some teamwork, but no leader indeed.

to use an English expression ... poppycock!

Janek you may have not noticed that the team of Colin, Phil and myself along 
with some of the bug squad managed, with the the help of Graham (if you want to 
call him a 'leader') to process a quite impressive number of patches. 

Before we managed to get some kind of automation of patch testing I personally 
was fielding about 6 new patches a day, producing reg test diffs, make checks 
and the like. Colin was managing all patch countdown and push requests while 
Phil ran around, figuratively speaking, making sure things were in order in 
terms of regressions between dev releases. all co ordinated by graham - pretty 
much.

in the meantime Mike, Keith, Carl and co had plenty of time then to fix some 
long standing bugs, and I am seeing some serious work by David to do whatever 
it is he does with the parser etc.

All of which we still pretty much managed to keep a relatively stable tree with 
one or two hiccups which considering the amount of pushed changes and the 
fundamental stuff the coders were free to do because of them not having to 
worry about things like ... oh testing their patches don't break the main tree, 
spotting quickly any potential issues or breakages because now they can focus 
on reviews of code than having to administer them, that new features are 
documented and that all emails from users complaining about this and that are 
documented themselves in a tracker completely makes that claim ridiculous and 
rather gets on my wick( to use another expression).

comments like that from Luke are unhelpful, disrespectful to many of us and 
frankly, tedious.


> 
>> As far as I remember, some time ago you have tried hard to make some big
>> changes in Lilypond, but finally there was no big revolution...

Maybe before my time, however instead of complaining how about doing something 
constructive?


> 
> Hmm?  I remember that i mentioned to you the rewrite of vertical
> spacing system, which was implemented quite successfully.
> 
>> Without a leader that will make key design & implementation decisions
>> Lilypond will improve in a slow pace, letting Finale and Sibellius gain more
>> and more users.

So what?

it's not a competition. 


>> Probably some of you will return to the old row - is a goal
>> of a Lilypond to substitue Finale or compete with Sibellius. I think there
>> is no point in loosing your energy and time on that.

Yet you just did. some of us aren't fixated wit the stupid Sibfib comparison or 
even care. 

>> Instead we should do as much as possible to constantly improve Lilypond.
>> That means not only fixing critical bugs, but also: anticipating future
>> stability problems, constantly improving end user documentation and the
>> quality of source code (reduce complexity, comment code and so on). By now
>> there is a huge work to be done and Lilypond needs someone who will form
>> guidelines and priorities.

yeah, blah blah ... some of us already know and some of us are getting on with 
it instead of complaining.



James