tag:blogger.com,1999:blog-6005885087678136998.post1067709328456622781..comments2023-12-06T00:32:09.199-08:00Comments on Random things will appear: A jealous view at Gnome Stack (from Eclipse developer)Александър Куртаковhttp://www.blogger.com/profile/04431656411376657949noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-6005885087678136998.post-65214658916187462682012-10-16T12:23:37.042-07:002012-10-16T12:23:37.042-07:00I'm late I know, but I just read your post -- ...I'm late I know, but I just read your post -- catching up on stuff I missed during holidays.<br /><br />I feel like replying now because I feel very much like you do. <br /><br />It seems to me that Gnome has many, many problems though. Many developers are gone, lack motivation, and couldn't make any real decision about moving to a higher-level language (and come up with "things" like Vala ;)). It is clearly Sun's fault for not freeing Java earlier, or we could have lived in a very different world.<br />Also, the original excitement (that lasted long enough) is gone.<br /><br />However the good points you quote are true, even if I think they're not specific of Gnome: they're the standard bullet points of a good old Free Software community.<br /><br />The 'problem' with Eclipse it's that it's an Open Source foundation. You got it right comparing it to Sourceforge, because there are many, many projects at Eclipse and little discussion between them excepted about infrastructure. <br /><br />Eclipse members have no common goal other than the release train. Even technology-wise, where Eclipse could show consistency, the practices are very different from project to project. <br /><br />But indeed Eclipse members are for the most part corporate developers. Most of them are passionate developers, but they didn't come to the Eclipse community the same way Gnome devs. did: I think there's a lack of ambition and of political goal. It's just the production of useful tools.<br /><br />You said it right: it's a showstopper for new blood, and developers hearts beat for projects elsewhere.<br /><br />If you're at the ECE next week I'd love to discuss this over a beer. :)Simon Chemouilhttps://www.blogger.com/profile/14259735131084627450noreply@blogger.comtag:blogger.com,1999:blog-6005885087678136998.post-38721346068460343052012-09-08T07:17:52.128-07:002012-09-08T07:17:52.128-07:00Keep in mind that KDE is also reexamining notifica...Keep in mind that KDE is also reexamining notifications for the next release: http://drfav.wordpress.com/2012/07/31/the-notifications-issue-part-2-the-status/<br />http://drfav.wordpress.com/2012/07/19/the-notifications-issue-part-1-the-problem/Will Stephensonhttps://www.blogger.com/profile/07441626468992805412noreply@blogger.comtag:blogger.com,1999:blog-6005885087678136998.post-23544137219563163832012-09-07T07:37:08.154-07:002012-09-07T07:37:08.154-07:00While you're entitled to your opinion, I just ...While you're entitled to your opinion, I just feel like the Gnome developers don't listen to the users. There's nothing wrong with introducing new features, but removing them for no reason? Completely changing the system? It would have been one thing to keep the classic-style interface and release gnome shell along with it for the users to choose, but they had to go ahead and just change the whole deskop. What they had with Gnome 2 was good, almost every distro used it by default, but they had to come along with Gnome shell and shit all over their success. There's a difference between being "Forward-looking" and changing things just for the sake of change.Anonymoushttps://www.blogger.com/profile/09936368372323590150noreply@blogger.comtag:blogger.com,1999:blog-6005885087678136998.post-51872535621618318382012-08-30T09:43:26.389-07:002012-08-30T09:43:26.389-07:00Wayne, It's not only Gnome Goals, there are th...Wayne, It's not only Gnome Goals, there are the LibreOffice EasyHacks/HardHacks, Mozilla, KDE and so on similar programs. It's not about infrastructure - Gnome guys do it with wiki and bugzilla. It's like we are too afraid to change things which is a showstopper for new blood. This might pave the road to enterprises but it makes the road to developers hearts really bumpy.<br />Sure, Git/Gerrit, Hudson, Tycho are improving things but on the infrastructure level not on the codebase level. <br />"Projects like to have flexibility to do things the way that they feel is best for their developers and community." Probably that's part of the problem. Many Eclipse.org developers sees Eclipse.org as kind of sourceforge/hosting solution while gnome developers think their project is Gnome.org not ekiga/gedit/anjuta/etc. This kind of attitude will be really hard to chainge. It's not like the foundation can enforce it, it has to come from inside people which is something gnome guys have.<br />About how many things we(as in Linux Tools) are guilty of - all of them!! I haven't come with this list out of nowhere it's based on real world problems I faced. It's a problem to get this fixed in a single project but it's because of how people look at eclipse.org. The release train is the best part of Eclipse Developement and that's the way to guide people in the wright direction. By adding an item everytime a project join and fail the train builds based on that (there are enough tools to enforce whatever one wants in Java land). Александър Куртаковhttps://www.blogger.com/profile/04431656411376657949noreply@blogger.comtag:blogger.com,1999:blog-6005885087678136998.post-77316539416034157662012-08-30T08:56:48.716-07:002012-08-30T08:56:48.716-07:00I do like the GnomeGoals. I'm not sure how we ...I do like the GnomeGoals. I'm not sure how we would replicate something like that at Eclipse, given that we have many dozens of different projects with different goals and different audiences, but I'm willing to explore the idea. We're always looking for new ideas on how to better engage the community and make things easier. The adoption of Git/Gerrit, for example, was motivated primarily by a desire to make it easier for folks to contribute to projects. I know that we can do a better job with issue tracking.<br /><br />In terms of consistency, we're pushing in that direction with the introduction of the common build infrastructure (CBI), a Maven repository, and common project project pages with better search and navigation, to name a few. Consistency is difficult, though, in such a large and diverse project community. Projects like to have flexibility to do things the way that they feel is best for their developers and community. We permit this within a framework while trying to provide attractive services (like CBI) that encourage projects to adopt consistent practices rather than shove them down their throats. I'm always looking for ways that we can improve on consistency without being unnecessarily burdensome or restrictive on projects.<br /><br />With regard to 'Forward looking developers', this varies widely from project-to-project and suffers somewhat from perception issues. The Eclipse Platform project, for example, is widely regarded as conservative, yet they did engage on a pretty extensive reworking of years-old APIs to revitalize the platform with the 4.x stream. The m2e project moves pretty quickly as well.<br /><br />How many of the things you list under "Get things done" are you guilty of and why? I'm not trying to be adversarial. I'd like to understand if there is anything that we can do institutionally to address these concerns. Are there changes that we can introduce into the Eclipse Development Process that can fix these issues?Waynehttps://www.blogger.com/profile/02277665617356449769noreply@blogger.comtag:blogger.com,1999:blog-6005885087678136998.post-86284196958823454462012-08-30T02:05:19.927-07:002012-08-30T02:05:19.927-07:00A real breath of fresh air - thanks!A real breath of fresh air - thanks!Kelsey Judsonhttps://www.blogger.com/profile/09817857220047436398noreply@blogger.com