Re: GNOME and non-linux platforms (release team please stand up)
On 22/07/2009, at 3:54 PM, Calum Benson wrote: On 22 Jul 2009, at 20:06, Jason D. Clinton wrote: Obviously the alleged pointlessness of something that we are arguing about is relevant. Whether or not there are--you know--actual people using said OS is what this is really about. And apparently even Sun doesn't think so since they no longer invest the same level of resources in it that they once did. FWIW, in relative terms the number of people working on the GNOME desktop at Sun compared to say, 5 years ago has probably increased, but I'm aware that this isn't necessarily the general community perception. Maybe we just need to rescue Gman from his current marketing role and give him back a proper job :) Harsh! :) (but thanks all for providing the amusement to waste away a couple of hours at SFO) Gman ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
Hey, Callum McKenzie wrote: > For some modules, like gnome-applets or gnome-games, with lots of small > - loosely related - programs inside, the ChangeLog has a finer > granularity than the commit message. The ChangeLog provides a coherent > story for the sub-module - something the commit messages don't. In some > ways its a sign the repository is poorly arranged, but thats what we've > got. For some perspective, the OpenSolaris guys use very simple commit messages, but *all* commits contain a bug id which links to all the information you need. Very similar in many ways to a good detailed ChangeLog, but I'm very much of the either/or group - having nothing seems silly to me. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing GtkUnique 1.0 as a blessed external dependency
Hey, Emmanuele Bassi wrote: > Hi; > > On Wed, 2006-11-15 at 00:10 -0300, Germán Poó Caamaño wrote: Even if it implemented tabs, it's likely that the apps run on different workspaces, and it's nice to have the help browser right next to the app for which you seek help. >>> GtkUnique would only be used so that there is only one yelp executable >>> running, so that you do not have several geckos running and so on. >>> That's orthogonal to the location and number of the yelp windows. >> I'm not sure if yelp is a good candidate for GtkUnique. >> >> It's quite annoying when you work in a dual-head station and only able >> to run the application in only one display. > > GtkUnique should support multi-head environment; I say "should" because > I cannot test it - so if any has one should download the library and > launch one of the tests and see if it works. Seems to work fine here for multi-head, though I haven't tested xinerama. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: proposed architecture evolutions for GConf
Davyd Madeley wrote: > On Sat, 2006-11-11 at 12:02 +0100, Josselin Mouette wrote: > >> There are several ways to deal with a single-session, single-host >> configuration engine. Real problems arise when the user can log in >> several times on different machines, with a shared filesystem. With the >> number of corporate users working over NFS, this is not something we can >> ignore. > > It is possible to write alternative GConf backends. I recall that Sun > have written one that uses LDAP, its name starts with an A, but I can't > recall what it is. > > Would this solve your problem? APOC http://guadec.org/node/222 Joerg's probably monitoring the list to be able to give more details on this. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
Hi, Steve Frécinaux wrote: > Martin Ejdestig wrote: >> On Fri, 2006-10-20 at 13:11 -0400, Rodney Dawes wrote: >>> The menu thing looks like the Mac menu, but doesn't >>> behave anything like the real thing does on Mac OS. >> And the slab thing looks like Windows' start menu but doesn't behave >> anything like the "real thing" on Windows. Or did I miss something? :) > > Note that I'm not using MacOS, nor am I using Windows. > > I'm perfectly fine with the current "gnome-y" menu applet and don't want > to see it replaced, that's all. I don't have a huge desire for change either. We seem to change the menu layout in pretty much every GNOME minor release that we've created. That's churn every 6 months. What makes you think that slab is any better? How long has it soaked in a Novell release? [or is this an excuse to avoid having to maintain code specific to Novell? - a 'yes' answer is fine, I can appreciate that desire...] Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarius
Hey, Shaun McCance wrote: > I'm going to coin a new term: key churn. This is when people > make frivolous and unnecessary changes to GConf keys or their > default values. It sucks for large deployments. Gnome is > bigger than your personal desktop. I don't really care too much about the name change, but what I do care about is the migration story between themes as new engines/icons/whatever are dropped in and out. This stuff isn't as smooth as it should be - hopefully Calum can provide details of what currently happens [we documented this for an ARC case recently]. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On breaking the woohoo barrier...thoughts on how GNOME can get great
Calum Benson wrote: > Quim Gil wrote: >> El dv 14 de 07 del 2006 a les 08:41 +0200, en/na Murray Cumming va >> escriure: >> >>> Should anyone ever get around to creating some GNOME personas >> Someone started http://live.gnome.org/Personas months ago. Yeah, and I tried to do something like that for gnome.conf.au, but didn't get enough time in the day to get into the session. I even started on some profiles, with a more 'human' aspect [1] - http://live.gnome.org/JoshWilliams ie. has curly hair, outgoing, etc... http://live.gnome.org/HarrisonJacobs Would be real sweet to have a bit of fun and develop these types of profiles at something like the Boston Summit. Glynn [1] I took the inspiration from a previous Solaris Desktop Summit.. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for comments on where to have GUADEC in 2007
Hi, Anne Østergaard wrote: Dear GNOME Foundation Member, You are invited to comment on where you would prefer to have at GUADEC in 2007. The period for comments stops on June 15th 2006. The board (minus Dave Neary and Vincent Untz who are behind the French invitation) will make the final decision. We have got two very fine invitations to choose among: Birmingham in the UK or Lyon in France. The bids are attached in this mail. Neither of the bids have any details about financials and budgets - I think the decisions can't possibly made until we know the details of what the costs involved of hosting in each of the bids. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
On Thu, 2006-04-20 at 22:28 +0200, Vincent Untz wrote: > Le jeudi 20 avril 2006 à 14:19 -0600, Elijah Newren a écrit : > > So, new question we have to address before addressing Alex's proposal: > > Should Mono be a valid dependency and C# a blessed language? > > I believe the answer should be yes. We're starting to see a lot of > projects in C#, and I think all the major distributions are shipping > mono now. Ahem, not quite true [1]. Glynn [1] although depends on your definition of 'major'. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to add Orca to GNOME 2.16
Hi, On Mon, 2006-04-10 at 18:45 -0400, Willie Walker wrote: > 2) Add orca to the "Startup Programs" entries for gnome-session. I've > never been quite sure why this wasn't something that was done for the > current assistive technologies - was it because the "Startup Programs" > dialog requires so many steps to get to it? I think the main reason was the fact that adding startup programs programatically wasn't very easy - the file format was pretty ugly, and pretty unsupported. This should be a bit easier with the new Autostart spec, which allows you to create a .desktop file and pop it into the autostart locations [1] Glynn [1] http://www.freedesktop.org/wiki/Standards_2fautostart_2dspec ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Hey, On Wed, 2006-02-08 at 11:52 +, Alan Cox wrote: > Nor does the committee argument stand up. It is perfectly possible to > post in advance that "we are going to do this, we've created a temporary > alternate repository for the work and if you want to join in or help > merge stuff back as it meets acceptability please sign up" Indeed that's probably one of the few problems I could possibly have - seeing this stuff through some demonstration videos of NLD [1]. We probably just need some common sense involved in making sure the appropriate people in the community get a heads up so they don't have to see it 2nd or 3rd hand. Innovation happens elsewhere, and that's really, really great to see. We can just be a lot more mature about it and the community that we're building. Glynn [1] And I'm 100% sure Sun has been in this boat too... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Hey, On Mon, 2006-02-06 at 16:10 -0500, Matthias Clasen wrote: > On 2/6/06, Elijah Newren <[EMAIL PROTECTED]> wrote: > > > Was there a reason to do that instead of using Glynn's patch from bug > > 327335 to revert this specific change? > > 1) I was not aware of that bug and patch > 2) We also want the icons back So what's the situation of this - are the various patches going to be reverted? It seems like there's a *strong* disagreement for these changes by many people in this thread that these changes. It seems to me that from a corporate point of view, there's 2 vendors, Red Hat and Sun, have already reverted these changes and shipping a different version of the capplet. Aside from the 'design by committee' set of blog posts that I haven't had a chance to catch up on, anyone willing to give a summary of where things stand? I notice that these changes landed *after* 2.13.5 - that's well late in the cycle, no? It feels like we should at least revert now, find some status quo and then get some good discussion for making those changes in the 2.16 timeframe. thoughts? Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Hi, On Tue, 2006-01-31 at 17:11 -0600, Federico Mena Quintero wrote: > Can you build the whole gnome-control-center module with no inlining and > debug info (-O2 -fno-inline works well), and then run sysprof while > changing backgrounds quickly? Changing backgrounds quickly doesn't really help, since XSetWindowBackgroundPixmap() isn't being called each time, at least when nautilus has been disabled [I'm only checking that case right now] - or that's what I'm seeing while using DTrace. Also, the default set of backgrounds have completely different sizes and types as a quick browse through /usr/share/pixmaps/backgrounds will show. It might be cunning to pick one relatively plain background, duplicate it a couple of times and change the colour of it, then edit the xml files in /usr/share/gnome-background-properties for different wallpaper options. I'm also not really noticing the slowness that people are experiencing, or at least background changing seems reasonably responsive - this may be due to some cairo patches that we've applied locally, I'm not sure. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
Hey, On Mon, 2006-01-16 at 07:28 +0100, Vincent Untz wrote: > + quite a few people were assuming that 0.10 was the plan for 2.14 and >were totally unaware that 0.8 had even been on the plan. Ubuntu and >Fedora development versions (i.e. the distros that Elijah checked or >found out about) seem to both be headed towards 0.10. We're looking like GNOME 2.14 with GStreamer 0.10 is going to be the most likely candidate for the next version of JDS too, FWIW - although the community should do what's right for the community, since our release is still a way off so that we can factor in porting if necessary. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Solaris 10 University Challenge
Hey, Some people might have seen this already - http://www.sun.com/software/solaris/contest/univ_challenge.jsp There's a whole heap of project suggestions, some of which are related to desktop development [including GNOME]. Let me know if you have any questions and I'll do my best to answer them, or put you in touch with the relevant person. Good luck! Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving Applets (was: Fish in GNOME Panel)
Hey, On Thu, 2005-10-13 at 22:23 +0200, Emmanuele Bassi wrote: > The applet's code base might be small, but badly suffers of bit-rotting; > and some applets are outside the gnome-applets "mantle", e.g. the > dicionary applet - which is under gnome-utils. > > I'm giving gdict-applet some love - namely, I'm cleaning up the mess > that has accumulated during the years, and trying to separate the > widgetry from the dictionary handling; but I do suspect that the code > base of some of the oldest applets really needs more than some love > (even though it could be a start). Yeah, but at least we should try and acknowledge that fact - there's a whole heap of *really* intelligent people out there who are using our desktop, wondering if some day they might contribute something back. It's one of the things we really suck at - getting new people keen enough to get on board. Share the love! :) Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving Applets (was: Fish in GNOME Panel)
Hey, On Thu, 2005-10-13 at 00:16 +0800, Davyd Madeley wrote: > People have struck on a topic I started thinking about a little > while ago. > > This thinking is highlighted on the wiki space > (http://live.gnome.org/GnomeApplets). > > In short we would create a gnome-applets-extras. The purpose of this > package would be to include all the applets that have no home on > their own, but really don't need to be part of the standard desktop. > This will reduce the load on the maintainers/translators and > everyone else while not leaving older applets to die. So, I'm against too much flux within packages, unless the code is really unmaintainable. In many cases, the basic functionality is 'done' - sure, it may need some more work, but did you ever think about adding 'gnome-love' keyword? Applets are really easy things to start off playing around with, since the code base [generally] is relatively small. I logged a bug against the clock applet not showing the year, and added the 'gnome-love' keyword. 2 days later, a patch was attached - thanks Daniel! There *are* people out there, and we're just doing a really bad job herding them into the bits that need a little love. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug buddy configuration
Hey, On Tue, 2005-10-11 at 14:44 +0200, Fernando Herrera wrote: > Hi, > > right now you can globally disable bug-buddy dialog setting globally > the env variable GNOME_DISABLE_CRASH_DIALOG (you can do in the system > profile, for example). > > You could hack bugzillas xml file to set up another destination > addresses, but there is no way to skip all bug-buddy assistant pages. FWIW, this is actually a feature that we've hacked locally in Sun too - although with upgrading to 2.10/2.12 we still have to rewrite the patch. Basically, having customers automatically send bug reports to the community would be a security concern which is unacceptable, but we're still anxious to keep on top of stability problems in the desktop by monitoring an internal alias of bug-buddy reports. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up themes
Hey, > Perhaps we should consider moving these into the -extras package. What I > think would be really cool is having a level of integration that allows > you to install themes right off art.gnome.org from your favourite web > browser. That way we could ship our 4 very nice themes, and everyone can > install whatever else they want with ease. Very rapidly integrated with > web backgrounds, and one day web-shipped applets. What's the upgrade mechanism - is there any dialog saying where my theme has gone and how I can download it again? Doesn't seem like anyone has solved that problem to be removing themes just yet. [Of course, I could be totally wrong] Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Old versions of GNOME [was: Re: gtk 2.8 for gnome 2.12]
Heya, > Please bear with me along the following rant. Okay, so this rant covers a lot of ground, but I have specific comments from a Sun perspective - o As a Sun developer, I'd much rather the community focus on churning out the next release of GNOME. Which is pretty much what the average hacker wants to do, right - be innovative, develop new features and generally get the desktop moving forward. Bug fixing gets boring, and bug fixing on stable branches even more so ;) o I think it should be up to the various distributions to put their bug fixing patches upstream, and onto the branches ASAP - so that other distributions can also use them. Let's face it - there's no value add in bug fixes, and if they don't get pushed upstream, it makes GNOME look bad rather than other distributions. I'd very much welcome a 'free for all' on the stable branches, past the 2 or 3 official releases we do. o I'm trying to push a change in development process within Sun, so that we can concentrate our core development on HEAD as much as possible. We've been kicking this around internally for the past couple of years, and now with our focus on OpenSolaris, I think it should be more feasible to do than previously. As an added bonus, we hope to be able to throw QA resources into that as well. All this is going to take time though, and won't happen overnight. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Certification for GNOME apps
Hey, > There can be a useful intermediary between 'having no docs at all' and > 'here is a documentary that explains what we promise to support for > ever and ever, amen.' I believe the goal here is to document what we > do now, and how to usefully integrate with that. Yeah, I do agree - I guess if it helps to figure out the interfaces that we do want to keep, and those we don't, then it will be useful. > Is that necessarily > going to please 100% of ISVs? No. (Possibly not even 50%.) Will it be > useful anyway? IMHO, yes. While we should definitely get Bryan's input > and attempt to accomodate it as much as practicable, lets please not > bog this down by aiming to please the iron-clad expectations of very > serious ISVs when the current state is so abysmal for *all* consumers > of GNOME libraries. Yeah, but you know as well as I do, that those serious ISVs are exactly the people we need to target - and well, without those iron-clad expectations, we won't get a foot in the door. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Certification for GNOME apps
Heya, Dudes, you should work with Brian Cameron from Sun on this - I'm pretty sure he'll pick up this thread, but he's done a HUGE amount of work in this space already. I personally think a step by step effort working down through your list is awesome - rather than doing everything at the one time, get the initial ISV porting guide out for Level 0 *now*. Level 1+ is a hell of a lot harder to start thinking about because you're basically guaranteeing a compatibility roadmap for ISVs, and I've found [in my experience], that involves a lot more thought. FWIW, I don't think this is just a marketing thing - this involves a lot of commitment from the developers too, and a level of understanding that I'm not quite sure is there yet. Glynn > One of the marketing efforts that the Foundation Board discussed during > GUADEC is the possibility of having "certification levels" for GNOME > applications. Apps that get rated higher are "nicer" or "more > GNOME-like"; hopefully we can use the rating metrics to let users gauge > how well a particular app integrates with the rest of their GNOME > desktop. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new gnome-common release?
Heya, > > I disagree. There are folks who still prefer to build from tarballs. > > And for many distros, tarballs are the preferred base for creating RPMs, > > so as long as gnome-common is required for a build, there should be > > releases for it IMO. > > gnome-common isn't required to build tarballs, only from CVS. Not quite true for JDS though - we still seem to involve enough patching that gives us a requirement on running libtoolize, aclocal, gtkdocize, autoheader, automake, autoconf, ... etc that we always seem to need a gnome-common installed. Admittedly there's not much use for the module compared to the old days though Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Kicking off planning session planning
Hey, > How about copying & pasting the basics of your mail into the wiki as a > skeleton to hang a session on? > http://live.gnome.org/Stuttgart2005/FreeformSessions > > I hope we have a problem of overlap - which will mean that there are > lots of great sessions planned. If that's the case, we will probably > rely on our (as yet unknown) session leader to merge sessions of common > interest. I've added a link in the FreeformSessions now - http://live.gnome.org/Stuttgart2005/FreeformSessions/StableInterfaces Feel free to get an account and edit. thanks, Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Kicking off planning session planning
Hey, > The 4 tracks I propose are: > > * Interoperability - everything to do with making GNOME work better with > KDE, OO.o, XFCE, Mozilla - not just a freedesktop session, but primarily. > * Developers platform - gtk+, glib, atk, gconf, gnome-print, libgnome: > All the infrastructure we share across the desktop. Probably a good > place to talk about ABI stability too. > * Desktop - the user-visible desktop, planning sessions and > brainstorming for application teams goes here. > * Infrastructure - Bugzilla, docs, web team, source control, marketing > (which is in the schedule already) Seems like there is a lot of overlap that draws developers in different directions. I'd like to be a bit more fine-grained than the above topics. Perhaps having everyone start as a single group, try to identify problem areas, and then split up into manageable groups, with experienced people leading them. Discuss. Otherwise we'll just be twiddling our thumbs for an hour, or heckling Luis at the marketing session ;) Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GUADEC - new sessions
Hey, GUADEC is just around the corner, and we're slowly starting to finalize the GUADEC schedule for Stuttgart. The current schedule is available here - http://2005.guadec.org/schedule You'll notice that we have some new things to try out at this years conference. Lightning Talks === These are sessions giving people an opportunity to talk about their pet project, or peeve, for a short space of time, preferably between 2-5 minutes. We tried these out at the Boston summit last year, and it proved to be quite successful. If you're interested in presenting something, register yourself at http://live.gnome.org/Stuttgart2005/. We'll cram as many of you into an hour as possible - expect some crazy laptop swapping action! Freeform Sessions = Much of the planning and discussion at GUADEC happens outside the formal organized set of talks, whether over some dinner, or beer. While this is quite often the most effective way when progress needs to be made, it's also an indication that there are too many talks at GUADEC. This year is no exception. However, it's also hard for new developers to get involved in the planning. We're looking for visionary people to lead these sessions, ideally from the core group of GNOME developers [you know who you are]. We have 3 sessions available in the current schedule, with 1 already taken up with Marketing GNOME, and our very own Luis Villa. We're looking for reasonably general topics, or problem areas that we need to discuss. If you think you have what it takes, start thinking and send your ideas to [EMAIL PROTECTED] Each session will go off, brainstorm, and report back to a big group session at the end of the day on their findings, or solutions. GUADEC needs you - share the love! Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Revitalizing the Urban Center of GNOME
Hey, > Communication is so fundamentally important within an open source > project like GNOME. It also cripples it, if done badly. > > [1] I'm sure someone wrote about this, but I just can't find the > reference. It's pretty clear though, that the successful people > within the open source community are the ones that can write. Thanks to Dave Neary for remembering where I read about it - http://www.joelonsoftware.com/articles/CollegeAdvice.html See the 'Learn how to write before graduating' section. Glynn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Revitalizing the Urban Center of GNOME
Hey, > ps. Core maintainers, please respond to this thread. I REALLY want to be > part of the solution, not the problem. I also want some sort of voice, > and not be totally rejected from the process, or told to STFU. I don't write much code, so I'm not sure if I classify as a 'core maintainer' who has any influence on the direction of GNOME. However, one of my inherited job descriptions here at Sun is to try and keep on the pulse of GNOME development and know what's going on on a daily basis within the GNOME community. You can't even begin to understand how important that is, trust me. That job description has become increasingly hard over the last year or two. Like Havoc, I'm really only reading emails from the core maintainers, or those mails pointed out by other people. It's not like other people's opinions don't count, but I often find those emails to be drawn out and badly written, and consequently hard to read. The ability to structure your emails to communicate your ideas clearly is a key talent that most of us seem to lack, and desktop-devel-list seems to suffer from that fact [1]. Communication is so fundamentally important within an open source project like GNOME. It also cripples it, if done badly. Glynn [1] I'm sure someone wrote about this, but I just can't find the reference. It's pretty clear though, that the successful people within the open source community are the ones that can write. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
