Performance Love Day

demonstrating just what a bunch of slackers and liars the Pango/GTK guys really are.

No, it doesn't. It just means there was no low-hanging fruit to make the optimization easy. If there are no clear bottlenecks, that is a good sign of fairly optimized code. It's just that, in Pango's case, there is still more work to be done. You know...it is possible to make a point without being insulting. Pango/Gtk is some damn good code written by some very smart and talented people. Just because it doesn't meet your every expectation doesn't mean the developers are lazy and don't give a shit.

I read about the recent Pango optimization work. The person doing the profiling and optimizing started with what he called a "flat profile" - there was no obvious place to start optimizing. If 80% of the execution time were happening in one place, then even if it were already heavily optimized, that would be a good place to start - but when you're looking at a bunch of 5-10%'s, then it's a royal pain to optimize.

And in fact, one of his first comments is that Pango is already pretty well optimized, and very well written.

Your rich metaphors ("an appalling slug dragging the entire desktop") are misplaced. But then, I would expect that from one who I assume to be a native english speaker. I would, in fact, expect it from pretty much anyone whose primary language uses latin script. It was well known that Pango wasn't the top performer as far as text rendering, but there is a price to pay for supporting every script under the sun.

There've been discussions before about things that could be done to improve Pango performance significantly - at the expense of code readability, maintainability, and only improves performance for the Latin character set. In the end it was decided that the effort would be better spent on optimizations that benefit everyone. Hence, Frederico's work.

And "basic optimizations"? Do you understand ANYTHING Frederico and the half-dozen other people have done to improve Pango performance? There were already a lot of caches to speed things up. Part of the problem was that the caches had no reaping policy.

Some of the tools that were used to identify things that could be tweaked really only became usable and/or well-known in the past year or less. Sysprof, valgrind, gtkperf. Without these tools, a lot of the great work being done now would cost a LOT more in effort.

Um, isn't performance a boring subject to use to get new hackers for GNOME?

I'd like to see half the people complaining that GNOME is slow to try and do something. If no one shows up, then I'll assume that: i.) GNOME is not that slow, ii.) there are too many armchair programmers out there bashing what they don't even understand, or iii.) to the vast majority of GNOME users, the platform is fast enough.

Anyway, the profiling part is really fun to do; running applications in a loop, doing just one thing, in order to collect data is also easy.

Debian - Even Hell Freezes Faster. -- seen on #debian-devel

I call bullshit on most of that.

- The development process is sane and on par with other projects. CVS commit access is something not given away quickly by anyone working on an important project because of security and accountability consernes. If a malicious or just plain incompetant programmer's work got into the repository, it would blow development to hell. Patches are reviewed in every project for the same reason.

- Such a patch review process can and does work for gnome. As a package co-maintainer I've reviewed and committed many submitted patches. I've reviewed and rejected a couple of patches, but I have never got a patch that hasn't been reviewed promptly.

- Gnome uses Autobreak like most other OSS projects. It may be complex but it allows a hell of a lot more flexibility than jam and other alternatives. Autobreak provides a really consistant and powerful product when set up. CVS may not be perfect, but it is similar to svn in its featureset and far more simple than arch or bitkeeper. Once again, both of these things work well with only marginally more advanced alternatives so why change?

- There are far more projects that are worsely documented than Gnome than there are better documented that gnome. Especially, the documentation for GTK+ is actually rather good.

Gnome has arrived at the point where the core developers do not want to destablise the base by changing things that do not need to be changed (like getting rid of CVS and autobreak). Most potential developers have no problem with this and the ones that do tend to be the ones with difficult personalities that wouldn't really work well as part of the team.

If you want a fork, why don't you try gonme? I don't think there is much progress with it, but it's somewhat of a fork.

If a malicious or just plain incompetant programmer's work got into the repository, it would blow development to hell.

In that case, it's a clear sign that you a) have no maintainers at all or b) are using a broken RCS that doesn't allow easy rollback.

Such a patch review process can and does work for gnome. I have never got a patch that hasn't been reviewed promptly.

That, on the other hand, can only mean that you a) have submitted patches only for very few projects that are very well maintained (like The Gimp).
I could name at least five patches immediately that were submitted and have rotten unreviewed since to a point at which they no longer apply.

Gnome uses Autobreak like most other OSS projects. It may be complex but it allows a hell of a lot more flexibility than jam and other alternatives.

That is the most ridiculus point I have ever read in the debate. Flexibility is *not* automakes strength. But I'm not going to comment on this further, feel free to read the flamewar at KDE for some comparisons.

http://dot.kde.org/1126452494/

IMO, anyone who claims that it still makes sense to use autotools for desktop projects has never even tried the alternatives.

Gnome has arrived at the point where the core developers do not want to destablise the base by changing things that do not need to be changed (like getting rid of CVS and autobreak).

Yes, fear is a powerful weapon.

It does make sense to use autoconf. I used SCons and other alternatives. Although autoconf/automake is not the best, SCons sucks in its own way. In particular, no good (and STANDARDIZED!) way to automatically create source tarballs (yes I know about the Tar function, but now try to recursively call that function in sub SConscripts to emulate the same effect of 'make dist'!), so I had to write my own shell script for creating source tarballs. No good (and STANDARDIZED!) way to install files ala 'make install' (yes I know about the Install function. try using it and see what a hell it is compared to 'make install' which Just Works). No good pkg-config integration (the scons documentation's recommended way doesn't always work well). There are not many SCons project so it makes it hard to find examples. Etcetera etcetera. There are a ton of other things I discovered while using SCons.

Now, SCons may be greatly improved now that an important project like KDE has decided to use it, and it would be great if it really would. But until SCons is better than autoconf/automake in ALL ways (in particular the things I mentioned above), don't treat like autoconf/automake is dead.

While your post is obviously a flame, and it also obviously is a personal rant (did you propose a feature that got rejected?), I think I might be trolled - I've got nothing to do, this morning.

- The development process is closed in comparison with other projects. You don't get a repository account easily, and all patches need to be reviewed before going in.

As opposed to give away repository accounts and just throw things in the codebase model? Sorry, in this universe where PI is approx. 3.1415926, the GNOME people tries to keep the codebase coherent, and tries to smoothly progress from one point to another, in order to keep things working while adding features. Much like the kernel people do. The time to throw things in without caring of who or how was in the past, and there are still leftovers which must be (heavily) sanitized (gnome-dictionary comes to mind, since I'm doing this, at the moment). Get back to the GNOME people in your universe, and tell them that this approach works, and that they should use it too.

- Such a patch review process can *never* work in a large community project

Bzzzt, wrong. The Linux kernel development process works the same way. There are even less people reviewing the patches. So, yes: this approach works.

(because there are simply not enough reviewers), so now your patches are never approved, or it takes the developers a *very* long time to do so. A real fun killer.

There is latency, yes. It's a fun killer, no - because this means that the "fun" will not be spoiled for the users just to keep it for the developers. There aren't not enough reviewers? That's what the GNOME Love days are for: adding developers, make them get aquainted with the code base (with the guidance of more experienced hackers) and become GNOME hackers themselves. It worked in the last two years. The GnomeLove project is an ongoing effort, and it's not limited to Love days, Bug days and other special events: everyday, hackers hang around on the gnome-love mailing list and on the #gnome-love channel, in order to help new developers learn whatever it takes to become GNOME hackers.

- GNOME uses development tools that are rotten leftovers from the eighties, such as CVS and autotools, hindering your every step. In fact, the whole development platform is cluttery, old and unusable cra^H^Hode.

While I agree that CVS and the auto-tools are the spawn of the devil, they have served quite a few projects in the last decades; there are plans of moving to SVN or Arch-based repositories, thouhg. It takes time: the repository is huge (here), and the development process must not be harmed by the switch.

- There are way better documented projects out there. It makes your start a lot easier if you don't have to extract your information out of hundreds of Google queries.

The documentation is not as bad as it used to be, these days. There are tons of tutorials (for various languages), API reference guides, white papers, guidelines.

I hope for a fork that brings back the openness into the project.

You can always go and help the gone-me people.

Debian - Even Hell Freezes Faster. -- seen on #debian-devel

You seem to believe that developers in an open project are stupidly committing everything no matter of the code quality. Wrong, the majority of users can be trusted to care about their code.

Caring is often not enough. People with good intentions can write bad code, for any number of reasons. Perhaps they don't understand the codebase well enough. Maybe they don't understand the full implications of the code they write. Many times, developers put something together that works well enough on the cases they tested on their own machines, but it lacks in robustness or portability.

I have rejected patches, or more often, I've asked people to do them differently, with instructions. Are you telling me I should have just blindly committed every one of those patches?

Caring is often not enough. People with good intentions can write bad code, for any number of reasons.

True, but you can trust them to care enough to ASK for a review in that case. And in the rare case that somebody really commits broken patches... that's why modern RCSs support atomic commits, making it easy to roll back a change.

And in the rare case that somebody really commits broken patches... that's why modern RCSs support atomic commits, making it easy to roll back a change.

This is, by far, the stupidest thing I've ever read.

The job of a maintainer is to work as a watchdog in order to let bad code, ugly code or just plain wrong code, go in without reviewing it first.

Just because you have the ability to roll-back, it's not by any chance an excuse for letting the commit happen in the first place.

Debian - Even Hell Freezes Faster. -- seen on #debian-devel

The job of a maintainer is to work as a watchdog in order to let bad code, ugly code or just plain wrong code, go in without reviewing it first.

The point is that you have far more "maintainers" in such a case - the people that can be trusted.

Just because you have the ability to roll-back, it's not by any chance an excuse for letting the commit happen in the first place.

This cuts both ways. Just because you don't have enough maintainers to review patches doesn't mean you can leave things unpatched for a year.

And, to be clear, I have turned down patches from people whom I do trust to care about their code. In fact, I've turned down patches from some very core Gnome hackers.

Probably Gnome 3.0 is a good opportunity to get rid of "rotten leftovers from the eighties" and to become more open.

Those developers who are denying major changes to gnome could stick with 2.xx and could generate very matured versions 2.16/2.18/2.20.

IMHO this is the very best solution.

People like me who are using gnome in a productive way and who are satisfied with the current feature set would love this approach: A maintaind 2.xx branch for the next two or three years, but the possibility to switch to the next generation gnome if required.

Regards,

Joe

No offense, but why is it that people think that major bumping solves problems?

I disagree. Nothing beats developing GNOME applications in
Python. The GNOME documentations need some improvements,
however. And your GNOME project does not have to be a part
of GNOME. Get exposure and popularity via forums like
gnomefiles. And if people like your project, they'll
nominate it to be a part of GNOME.

But the future of attracting developers to GNOME lies in
Python. It is the VB of the Unix world. It also helps that
almost every GNOME/GTK module has a Python binding. All we
need now is better documentation, tutorial and resources.

"It is the VB of the Unix world."

When the python foundation does catch you, they will make you wish that you had never been born, not just wish you had never said that. Comparing python to VB is just plain out of line.

Indentation should be manditory on every language, I have worked with too many programmers that make "individual" looking code to ever acknowledge the argument that programmers should be given control over such things.

If you ever work with other people on a project some time you will know exactly what I mean.

If mandatory indentation keeps You away from the language I can tell you one thing:

no offence, but probably you are a beginner that belives in existance of a *perfect* language. There is *no* perfect language, but Python is damn close. Learn ten other languages and You will see :)

C, Obj-C, C++, C#, Python, Ruby, perl, probably PHP, and maybe a few more that I've missed.

There are also bindings for java
Java-GNOME which can be compiled with gcj.

Well, python is good but nothing beats gnome-ruby :)
Documentation is pretty good, and ruby is a real magic!

I agree, ruby's syntax is the best!!
And It's really a pity that ruby fans support more Macosx and Fox-libs