Re: Lowering the barrier (was: Re: build systems)
Just a quickie since the kids are screaming :-) : I started a wiki page to collect the status of this discussion: http://live.gnome.org/EasyGnome If I missed anything please comment. Heck please comment anyways. Cheers, Mikkel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Lowering the barrier (was: Re: build systems)
On Sat, 2007-11-10 at 00:43 +0100, Matteo Settenvini wrote: [snip] we need some proper documentation explaining how the GNOME stack is built, jhbuild should take care of building. There is a lot of information about how to use jhbuild, including solving specific problems on specific distros. and what components fulfill what need I think this is done: http://library.gnome.org/devel/platform-overview/stable/ And if something is missing then we now have the document where it should be added, via simple patches to gnome-devel-docs in svn. bringing in concrete examples in the discussion. [snip] Maybe this is something that can be improved. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Lowering the barrier (was: Re: build systems)
On 10/11/2007, Matteo Settenvini [EMAIL PROTECTED] wrote: Il giorno ven, 09/11/2007 alle 16.58 -0600, Jonathon Jongsma ha scritto: On 11/9/07, Lucas Rocha [EMAIL PROTECTED] wrote: - Are the current drawbacks of using autotools in GNOME so so so annoying that it would be really worth the effort of migrating to something else? The only reason I could imagine migrating to something else at the moment would be if it lowered the barrier to contribution so that we got enough new contributors to offset the amount of work it required. I'm doubtful that this would actually happen though, and we'd need to be 100% sure that the system we were moving to was an improvement. Changing subject since I think that the problem of lowering the barrier of contribution is crucial to the success of any free software project. I would like to discuss with you where we could act seriously in this direction. Good. I am greatly concerned by the alarmingly steep learning curve one has to endure to be able to contribute to Gnome (without resorting to Python/Mono). I've got some comments to make: * The GNOME love bugs weren't a bad idea, the only problem with some of them was they were boring and you didn't learn a lot from fixing them. For example, fixing include file order in headers isn't exactly what I'd consider exciting if I were to hack on some part of GNOME. I want action! Challenging ideas (but still, feasible ideas)! Furry little bugs squashed! Anyway, I'd like to see more bugs marked with the gnome-love keyword, and the most popular/new ones should deserve a window in the wiki, updated every week for major visibility. Make it a challenge, let the agonism arise between teenagers with too much testosterone! * The first time I tried to write something with the GNOME stack of libraries, I was baffled by ORBit. I simply wasn't able to get anything clear out from its documentation. I even didn't understand exactly what it was for. Three years, my first year as a CS student, and some beers later, I stumbled upon the DBUS specification. It was clear, concise, and explained very well to me what DBUS was for. After reading the *DBUS* document, I started understanding *ORBit* (which is different, obviously, but that gave me the insight). Following Murphy's law, now ORBit is being put in a corner :-). What I'm trying to say, is that we need some proper documentation explaining how the GNOME stack is built, and what components fulfill what need, bringing in concrete examples in the discussion. New hackers, especially if young and inexperienced like me, really need this sort of things to avoid going on a wrong path for months and then discovering that what you wrote was already there. That discourages anyone to continue. * Proper API documentation is still more important. I think that having 100% symbols documentation should be a priority. I know that no-one likes writing it, but it's necessary for all the people out there who don't have the willingness to read the code. By the way, the Mono library documentation is frankly quite incomplete. Also the Gtkmm one. I know of at least three separate CS programming courses in C++ at university that chose to use wxWidgets over Gtkmm just because of their better documentation (I prefer Gtkmm, but I don't have a problem to search also the Gtk+ docs as a fallback). * Code a lot of times isn't commented enough. Also static functions in a compilation unit should have at least a line explaining why they're there and what they're about. As you see, most of my problems go with the documentation, and not with the code, which usually I find well written - at least, the code *I* have read. A more strict policy about API documentation would be good news, and more abstract (vision, architectural) documentation 'd be wonderful news. I am not sure that enforcing stricter API doc guidelines is going to solve our problems. Here are the core issues as I see them ISSUES: * GObjects are conceptually difficult when you have standard knowledge of C# or Java * Autotools are exceptionally hard to work with * Some parts of the Gnome API are just plain hard to use. Ever tried implementing a panle applet? Wonder why we have to many apps using tray icons? * General API docs are not as good as they could be. Compare QT4 documentation with GLib to see the point. * It is sometimes hard to grok how an application or lib is internally structured. While http://library.gnome.org/devel/platform-overview/stable/goes some of the way describing the platform as a whole, the internal structure of apps and libs are sometimes elusive. POINTS OF ACTION: Here is a list of proposed actions to address some of the outlined issues. They are intended not impose excessive work load on module maintainers. * Write a GObjects for Java/C# Developers document (or maybe two separate docs) meticulously explaining the concepts of classes and object
Re: Lowering the barrier (was: Re: build systems)
On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote: * GObjects are conceptually difficult when you have standard knowledge of C# or Java you know you don't have to use GObjects with C, right? you can write native C# and Java applications. * Autotools are exceptionally hard to work with they are not exceptionally hard. they require documentation, and we don't provide pointers to it in the right places. autotooling an application or a library takes ten minuts in a basic setup, and if you require more complex handling then you'll find that all the replacements will not handle the environment as well (if at all). * Some parts of the Gnome API are just plain hard to use. Ever tried implementing a panle applet? Wonder why we have to many apps using tray icons? from a cursory glance in my chat logs of #gnome on irc.gimp.org and gtk-list archives it seems that everybody start with panel applets; I started with those as well. it's not hard to write a panel applet: it's hard to *debug* a panel applet - but that's because of the way panel applets work. this doesn't mean that the panel applet API is easy. or, for that matter, that the entire platform API is easy; we are still missing bits and pieces (lockdown? desktop state? document models?) and we are still paying the price of having cruft lying around. * General API docs are not as good as they could be. Compare QT4 documentation with GLib to see the point. maintainers in glib and gtk+ have been incredibly responsive in pushing documentation patches; people rarely have to wait a day for a commit authorisation (insert kudos to Matthias and Tim here). we need more people fixing the documentation and attaching patches to bugzilla. it's quite easy. * It is sometimes hard to grok how an application or lib is internally structured. While http://library.gnome.org/devel/platform-overview/stable/ goes some of the way describing the platform as a whole, the internal structure of apps and libs are sometimes elusive. you have the code. if the application/library is complicated pester the maintainers for explanations and submit a patch documenting the nasty bits. or removing them, if possible. * Write a GObjects for Java/C# Developers document (or maybe two separate docs) meticulously explaining the concepts of classes and object instances compared to Java/C# objects for the lay hacker this is a false problem: since you can avoid writing GObjects in C and use native data types instead, what you need to do is refresh the GObject tutorial. * Make Anjuta better at GObject/Ginterface and Autotools handling. It is already good, but make it *excellent* I imaging that Anjuta maintainers are accepting patches for these points. * Lobby for distributions to create a gnome-developer-studio package installing all build deps, documentation, latest anjuta, everything you need to hack on Gnome. Pimp those packages on the official Gnome pages. GNOME already has a development suite; distributions should already have picked that up. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Lowering the barrier (was: Re: build systems)
On Nov 10, 2007 7:41 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote: * GObjects are conceptually difficult when you have standard knowledge of C# or Java you know you don't have to use GObjects with C, right? you can write native C# and Java applications. ...or python or perl or c++. I'm an example of someone who never bothered learning much of anything about GObject, yet have still done a fair number of contributions. In fact, my contributions have mostly been to existing apps/libraries written in C (just avoiding any parts of the code dealing with GObject). * Autotools are exceptionally hard to work with they are not exceptionally hard. they require documentation, and we I'll agree with Mikkel, here. They are exceptionally hard. And I think getting started tutorials which include info on autotools do a disservice to would-be contributors. My eyes glazed over lots of times trying to read such documentation and it definitely hindered my becoming a contributor. I eventually figured out that I didn't need to bother with that mess in most cases (someone else will always contribute auto-tooling patches), though I did eventually learn a fair amount and have fixed various issues here and there. * Some parts of the Gnome API are just plain hard to use. Ever tried implementing a panle applet? Wonder why we have to many apps using tray icons? from a cursory glance in my chat logs of #gnome on irc.gimp.org and gtk-list archives it seems that everybody start with panel applets; I Not me! But I agree with the rest of your comments. * General API docs are not as good as they could be. Compare QT4 documentation with GLib to see the point. maintainers in glib and gtk+ have been incredibly responsive in pushing documentation patches; people rarely have to wait a day for a commit authorisation (insert kudos to Matthias and Tim here). we need more people fixing the documentation and attaching patches to bugzilla. it's quite easy. I agree with Emmanuele here, though I have some extra comments about helping out with developer documentation: I thought it'd only take me a couple weeks of spare time to get up to speed and start contributing way back when I was getting started. I was off by at least an order of magnitude, in large part due to lacking documentation. Lacking either because it didn't exist, or because it was inappropriate for beginners (despite the fact that everyone would point beginners at these documents). The documents that did exist would often waste my time on stuff like autotools, intltool, popt, gobject, compiling from cvs, etc. Just give me enough info to get started on creating *something*! (I can learn how to generalize the thing later to handle a11y, i18n, u7y, a1t, portable building, source control...but let me start by being able to create something simple I can see now!) At some point when I (and others) were complaining about this, Luis suggested that I write such a document. Sure, it took me a while to be able to do so as I had to learn some stuff, and the document I wrote was pretty simple and far from complete (http://www.gnome.org/~newren/tutorials/developing-with-gnome/, and is now a little bit out of date too) but I had LOTS of people thanking me for writing it and saying that it was VERY helpful to them. Someone else needs to pick up the torch and write more. But please don't waste the time of beginners at the start by making them learn every possible technology that might be used. Help them make something simple. Then extend it a bit. Let all the general stuff come later. Putting it up front just means they'll either give up or take *far* longer to become a useful contributor. * It is sometimes hard to grok how an application or lib is internally structured. While http://library.gnome.org/devel/platform-overview/stable/ goes some of the way describing the platform as a whole, the internal structure of apps and libs are sometimes elusive. you have the code. if the application/library is complicated pester the maintainers for explanations and submit a patch documenting the nasty bits. or removing them, if possible. I had the same difficulty as Mikkel, and believe that several people do. After learning metacity, I added some documents to try to fix this. See http://svn.gnome.org/viewvc/metacity/trunk/HACKING?view=markup http://svn.gnome.org/viewvc/metacity/trunk/doc/code-overview.txt?view=markup Comments I've heard since that time seem to suggest that these documents have been very helpful for others wanting to contribute. I meant to add such documentation for libwnck and bugzilla as well; I wrote a little bit of information for both (though I only committed the libwnck stuff; and lost my preliminary bugzilla docs at some point). It'd be great to find other volunteers willing to learn a module and write up such documentation. Just my $0.02,
Re: Lowering the barrier (was: Re: build systems)
On 10/11/2007, Emmanuele Bassi [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote: * GObjects are conceptually difficult when you have standard knowledge of C# or Java you know you don't have to use GObjects with C, right? you can write native C# and Java applications. I realize that I could have been more clear here. What I find problematic is that the barrier to contributing native code is to high. I have been putting a lot of time into deskbar in the past and I can not tell you how many times I've heard oh, great - yet another Python daemon, or why did you not wrote it in C?. Setting up a PyGTK project with Python distutils is extremely easy, and about as low barrier to entry as humanly possible. * Autotools are exceptionally hard to work with they are not exceptionally hard. they require documentation, and we don't provide pointers to it in the right places. autotooling an application or a library takes ten minuts in a basic setup, and if you require more complex handling then you'll find that all the replacements will not handle the environment as well (if at all). To me, personally, they where exceptionally hard. My teaching experience from uni tells me that if one person thinks something is hard - so do at least 50% of the class. Yes, it takes ten minutes to autotool a *basic* setup if you know how to do. But doing things that are expected for packages like, passing make distcheck, building gtk-doc, build a few test/examples, install headers or other files correctly takes a long time if you are not comfortable with autotools. * Some parts of the Gnome API are just plain hard to use. Ever tried implementing a panle applet? Wonder why we have to many apps using tray icons? from a cursory glance in my chat logs of #gnome on irc.gimp.org and gtk-list archives it seems that everybody start with panel applets; I started with those as well. it's not hard to write a panel applet: it's hard to *debug* a panel applet - but that's because of the way panel applets work. Yes, everybody starts with panel applets - but I can name three projects of the top of my head that ended up resorting to tray icons even though an applet would be the right solution. I shall not point any fingers though. this doesn't mean that the panel applet API is easy. or, for that matter, that the entire platform API is easy; we are still missing bits and pieces (lockdown? desktop state? document models?) and we are still paying the price of having cruft lying around. * General API docs are not as good as they could be. Compare QT4 documentation with GLib to see the point. maintainers in glib and gtk+ have been incredibly responsive in pushing documentation patches; people rarely have to wait a day for a commit authorisation (insert kudos to Matthias and Tim here). we need more people fixing the documentation and attaching patches to bugzilla. it's quite easy. Yes it is quite easy. GLib and Gtk docs are quite good actually, but they are not exceptionally good. I am not complaining; I am only trying to hash out a strategy for making the learning curve less steep. * It is sometimes hard to grok how an application or lib is internally structured. While http://library.gnome.org/devel/platform-overview/stable/ goes some of the way describing the platform as a whole, the internal structure of apps and libs are sometimes elusive. you have the code. if the application/library is complicated pester the maintainers for explanations and submit a patch documenting the nasty bits. or removing them, if possible. Yes that is obviously a solution to the problem - but exactly the solution I claim have failed (to some extent at least) hitherto. That is why I suggested the alternative route in my Points of action which have now been snipped from the mail history. Autogenerate UML and have the some dev in-the-know write half a page about the structure. * Write a GObjects for Java/C# Developers document (or maybe two separate docs) meticulously explaining the concepts of classes and object instances compared to Java/C# objects for the lay hacker this is a false problem: since you can avoid writing GObjects in C and use native data types instead, what you need to do is refresh the GObject tutorial. I do not understand what you are trying to say here. That people can just use plain old structs or that they can use bindings like Java, Python, Mono? Assuming the latter - that is not the point I am trying to address. I want to make it easier to hack on the C libraries. Consider for example Gtk's recent call for extra man power. Myself coming from a Java background, I can tell you that it was non-obvious to me how GObjects worked with my (very) limited knowledge I had when starting getting interested in this whole Gnome business. * Make Anjuta better at GObject/Ginterface and Autotools handling. It is already good, but make
Re: Lowering the barrier (was: Re: build systems)
On Sat, 2007-11-10 at 14:41 +, Emmanuele Bassi wrote: On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote: * GObjects are conceptually difficult when you have standard knowledge of C# or Java you know you don't have to use GObjects with C, right? you can write native C# and Java applications. While you can write native non-C application, that only applies to new applications or one already written in such a language. The platform and many applications are already written in C, so having a document we could point potential contributors to would be useful. Cheers, -- To bowl a maiden over: i. Remove Cover and Extra Cover. ii. Move fine leg to square leg. Hmm, I can't seem to think of a way to finish this. -- Sid on RHOD ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Lowering the barrier (was: Re: build systems)
On Nov 9, 2007 11:43 PM, Matteo Settenvini [EMAIL PROTECTED] wrote: I would like to discuss with you where we could act seriously in this direction. I've got some comments to make: It sounds like at this stage some input from people who have found the learning curve prohibitive might be useful - so I'll chime in. My ideas will not be as technical as many people's because I am not far up that curve, they are more practical suggestions for getting people at the lowest level - I hope they are useful anyway. My actual suggestions are prefixed with '***' so you can find them if you just want to skim :) Maybe context helps to interpret what I'm writing: I am doing an Engineering degree, and I have a huge interest in and enthusiasm for FLOSS. I spent my gap year working writing automation software in C#, and I have a lot of ideas for things I'd like to try to write for GNOME. I report bugs when possible and make feature requests, but each time I do it I wish I could help more. During term I have little time, in the holidays more, but still limited. Here are my thoughts: 1. What do you use to code!? What do I need on my system to do this?-- Coding on Windows makes you soft, especially if you used something like Visual Studio. There will be a huge number of people in this position (many CS course teach on Windows), all who could contribute valuable things to GNOME, I think. One of the first things that surprised me when heading GNOMEwards (and while trying to avoid Python and Mono) was that it wasn't clear what kind of workflow people used for designing and compiling their projects. Is there an 'agreed upon' workflow - or do people all have different ideas? A wiki page describing a 'conventional' and successful workflow or two would be really nice. At my Uni when they teach us to code (ok, we are only Engineers, not CS students) they give us a fairly proscribed environment because it makes things faster (it's a little front-end to gcc that calls emacs for editing called xccmake, if you're interested :). *** If someone wanted to make things really easy an IDE with documentation, assitance debugging and compiling all in one place could significantly lower the barrier. Failing that a package that installed all the tools you need (and led you to them), as well as the very up-to-date dependencies would be nice. It's not clear sometimes how much of the system you might need to have built from the bleeding edge to get the bit you are interested in to work properly. Many times I've thought if I could just get a computer that someone had compiled this on before I'd be able to get going much quicker! - why is it not JUST a case of getting then editing the source and recompiling - because it's never seemed to be that simple 2. Fear of asking questions/uncertainty where to direct them.-- Though I'm ruining all my effort in this department by writing this, I think that one aspect limiting my involvement is the feeling that I'm dumb - that I missed some important page somewhere where it was all made clear (I didn't, right?) and that I couldn't ask people simple stuff because the would not take me seriously in the future. Whether this is right or wrong, I think it is a fear that does exist. If you're serious about getting new people involved I think a facility for 'hand holding' could be helpful - especially if some sort of gradation was possible - naturally people are likely to move from needing much help to being in a position to give out the same help they've received. ***'#Gnome-School', anybody? I think one of the successes of Ubuntu is the way it has provided a more hospitable environment for newbies. *** In the case of 'Gnome Love' bugs - perhaps people people could offer to 'mentor' on them, so anyone needing to ask questions in attempts to fix them can have a ready contact. I understand, of course, that time is important and it may well be quicker for that mentor to fix the bug themselves - even so, perhaps it is worth it? 3. Autotools Mikkel is right, it's just not easy! Especially for someone who has had the details of compiling hidden to them in the past (like many people who have only worked on Windows) Anecdotally, when I actually _did_ do some development (not that I submitted...) I did it on a Compiz plugin and the time investment of getting auto-tools to compile it (so, not starting from scratch, just correctly modifying a working system) was more than what I spent coding. 4. Knowing which examples to use. -- This one I can be less sure of as I don't know enough - but in the past I have found there are so many examples around it is hard to know which ones are 'right' - just because something works it doesn't necessarily mean that I, as a yoing developer, should copy/use it. *** I wonder if there could be one project (or a few, to cover
Re: Lowering the barrier (was: Re: build systems)
hi; On Sat, 2007-11-10 at 23:33 +0100, Mikkel Kamstrup Erlandsen wrote: On 10/11/2007, Emmanuele Bassi [EMAIL PROTECTED] wrote: On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen wrote: * GObjects are conceptually difficult when you have standard knowledge of C# or Java you know you don't have to use GObjects with C, right? you can write native C# and Java applications. I realize that I could have been more clear here. What I find problematic is that the barrier to contributing native code is to high. if by contributing native code you mean contributing to the platform then yes: the barrier is high. the required quality is also high. if you want to start contributing you might *not* want pushing patches to, say, gtk+ or evolution, but maybe start with something easier, to get acquainted with the platform, the policies and the libraries. that's why we have GNOME Love, with bug days, an IRC channel and a mailing list. I have been putting a lot of time into deskbar in the past and I can not tell you how many times I've heard oh, great - yet another Python daemon, or why did you not wrote it in C?. Setting up a PyGTK project with Python distutils is extremely easy, and about as low barrier to entry as humanly possible. not every application has to be in the desktop. writing python (as well as C++, Perl, Java, C#, Ruby, Ada, whatever) applications is encouraged nevertheless. Yes, it takes ten minutes to autotool a *basic* setup if you know how to do. But doing things that are expected for packages like, passing make distcheck, building gtk-doc, build a few test/examples, install headers or other files correctly takes a long time if you are not comfortable with autotools. then I guess what you need is getting comfortable with autotools, instead of avoiding them. when I say basic setup I mean a basic setup for a GNOME library or application: gtk-doc, distcheck, examples, tests, pkg-config, etc.. it takes me now less than 10 minutes because I created a set of templates, which I guess is what happens with every tool. I usually don't fight with autotools unless I need to port some arcane setting. * Some parts of the Gnome API are just plain hard to use. Ever tried implementing a panle applet? Wonder why we have to many apps using tray icons? from a cursory glance in my chat logs of #gnome on irc.gimp.org and gtk-list archives it seems that everybody start with panel applets; I started with those as well. it's not hard to write a panel applet: it's hard to *debug* a panel applet - but that's because of the way panel applets work. Yes, everybody starts with panel applets - but I can name three projects of the top of my head that ended up resorting to tray icons even though an applet would be the right solution. I shall not point any fingers though. if a project chooses to use a tray icon is usually because we don't have an inter-desktop standard for panel applets, and not because libpanel-applet is hard. writing a panel applet requires some magic incantations (mostly, putting an XML file in the right place), and libpanel-applet is severely underdocumented. * Write a GObjects for Java/C# Developers document (or maybe two separate docs) meticulously explaining the concepts of classes and object instances compared to Java/C# objects for the lay hacker this is a false problem: since you can avoid writing GObjects in C and use native data types instead, what you need to do is refresh the GObject tutorial. I do not understand what you are trying to say here. That people can just use plain old structs or that they can use bindings like Java, Python, Mono? no, I mean: since people can avoid thinking about GObjects at all and use native data types in their language of choice, the only time they need to know how a GObject works is because they are writing something in C. this means that the GObject native C tutorial must be fixed, expanded or clarified. if you do not know C, or don't use it, then there's no need to write a document for understanding a GObject from a Java perspective - simply because a user of the Java bindings will be exposed to Java objects. if you want to contribute to platform libraries you need to understand of GObject works, not how GObject compares to Perl blessed types, or C# objects: a GObject is a GObject, it's a different implementation of a OOP environment. I think there is no denying that Gnome development (in native C) has a high barrier to entry, and from this thread's subject I think that is what we are trying to lower. yes, it's high. for what I'm now - after three or four years - able
Re: Lowering the barrier (was: Re: build systems)
On Sun, 2007-11-11 at 00:37 +, Who wrote: [snip] Here are my thoughts: 1. What do you use to code!? What do I need on my system to do this?-- Coding on Windows makes you soft, especially if you used something like Visual Studio. There will be a huge number of people in this position (many CS course teach on Windows), all who could contribute valuable things to GNOME, I think. One of the first things that surprised me when heading GNOMEwards (and while trying to avoid Python and Mono) was that it wasn't clear what kind of workflow people used for designing and compiling their projects. Is there an 'agreed upon' workflow - or do people all have different ideas? A wiki page describing a 'conventional' and successful workflow or two would be really nice. At my Uni when they teach us to code (ok, we are only Engineers, not CS students) they give us a fairly proscribed environment because it makes things faster (it's a little front-end to gcc that calls emacs for editing called xccmake, if you're interested :). Nontrivial development with C or C++ on POSIXy systems practically demands that you learn emacs or vim. Neither of those editors is particularly friendly to novices. My own workflow involves an emacs window with a compilation mode buffer at the bottom and the top split into two or three panes (depending on the width of the monitor I'm using). One of those top panes is often a shell. When I'm debugging, the lower pane is instead used for the debugger prompt. Novice developers who aren't ready to bite off emacs or vim can get by with GEdit, NEdit, or similar. And some may prefer an IDE. (Though my experience with IDEs, even as a novice, was that I spent more time fighting the quirks of the IDE than I cared to.) *** If someone wanted to make things really easy an IDE with documentation, assitance debugging and compiling all in one place could significantly lower the barrier. Failing that a package that installed all the tools you need (and led you to them), as well as the very up-to-date dependencies would be nice. It's not clear sometimes how much of the system you might need to have built from the bleeding edge to get the bit you are interested in to work properly. Doing that and maintaining it to be in a useful state takes a *lot* of effort. More than most persons are willing/able to sustain, I suspect. 2. Fear of asking questions/uncertainty where to direct them.-- Though I'm ruining all my effort in this department by writing this, I think that one aspect limiting my involvement is the feeling that I'm dumb - that I missed some important page somewhere where it was all made clear (I didn't, right?) and that I couldn't ask people simple stuff because the would not take me seriously in the future. Whether this is right or wrong, I think it is a fear that does exist. Feeling dumb is a normal part of exploring a new domain. :-) While such a feeling can reasonably compel you to look for answers on your own (as well it should), it shouldn't compel you to give up. Obviously, you don't want to develop a reputation as someone who does not consult available reference material. But in general, you will be taken as seriously as your current apparent competency indicates that you should be. No one (whose opinion you should care about) is going to hold the occasional naive question against you. If you're serious about getting new people involved I think a facility for 'hand holding' could be helpful - especially if some sort of gradation was possible - naturally people are likely to move from needing much help to being in a position to give out the same help they've received. ***'#Gnome-School', anybody? I think one of the successes of Ubuntu is the way it has provided a more hospitable environment for newbies. If there are persons available to staff such a thing, it's a fine idea. If such a channel winds up being devoid of knowledgeable individuals, it would likely be counterproductive. *** In the case of 'Gnome Love' bugs - perhaps people people could offer to 'mentor' on them, so anyone needing to ask questions in attempts to fix them can have a ready contact. I understand, of course, that time is important and it may well be quicker for that mentor to fix the bug themselves - even so, perhaps it is worth it? 3. Autotools Mikkel is right, it's just not easy! Especially for someone who has had the details of compiling hidden to them in the past (like many people who have only worked on Windows) Anecdotally, when I actually _did_ do some development (not that I submitted...) I did it on a Compiz plugin and the time investment of getting auto-tools to compile it (so, not starting from scratch, just correctly modifying a working system) was more than what I spent coding. A huge part of understanding the autotools is just
Lowering the barrier (was: Re: build systems)
Il giorno ven, 09/11/2007 alle 16.58 -0600, Jonathon Jongsma ha scritto: On 11/9/07, Lucas Rocha [EMAIL PROTECTED] wrote: - Are the current drawbacks of using autotools in GNOME so so so annoying that it would be really worth the effort of migrating to something else? The only reason I could imagine migrating to something else at the moment would be if it lowered the barrier to contribution so that we got enough new contributors to offset the amount of work it required. I'm doubtful that this would actually happen though, and we'd need to be 100% sure that the system we were moving to was an improvement. Changing subject since I think that the problem of lowering the barrier of contribution is crucial to the success of any free software project. I would like to discuss with you where we could act seriously in this direction. I've got some comments to make: * The GNOME love bugs weren't a bad idea, the only problem with some of them was they were boring and you didn't learn a lot from fixing them. For example, fixing include file order in headers isn't exactly what I'd consider exciting if I were to hack on some part of GNOME. I want action! Challenging ideas (but still, feasible ideas)! Furry little bugs squashed! Anyway, I'd like to see more bugs marked with the gnome-love keyword, and the most popular/new ones should deserve a window in the wiki, updated every week for major visibility. Make it a challenge, let the agonism arise between teenagers with too much testosterone! * The first time I tried to write something with the GNOME stack of libraries, I was baffled by ORBit. I simply wasn't able to get anything clear out from its documentation. I even didn't understand exactly what it was for. Three years, my first year as a CS student, and some beers later, I stumbled upon the DBUS specification. It was clear, concise, and explained very well to me what DBUS was for. After reading the *DBUS* document, I started understanding *ORBit* (which is different, obviously, but that gave me the insight). Following Murphy's law, now ORBit is being put in a corner :-). What I'm trying to say, is that we need some proper documentation explaining how the GNOME stack is built, and what components fulfill what need, bringing in concrete examples in the discussion. New hackers, especially if young and inexperienced like me, really need this sort of things to avoid going on a wrong path for months and then discovering that what you wrote was already there. That discourages anyone to continue. * Proper API documentation is still more important. I think that having 100% symbols documentation should be a priority. I know that no-one likes writing it, but it's necessary for all the people out there who don't have the willingness to read the code. By the way, the Mono library documentation is frankly quite incomplete. Also the Gtkmm one. I know of at least three separate CS programming courses in C++ at university that chose to use wxWidgets over Gtkmm just because of their better documentation (I prefer Gtkmm, but I don't have a problem to search also the Gtk+ docs as a fallback). * Code a lot of times isn't commented enough. Also static functions in a compilation unit should have at least a line explaining why they're there and what they're about. As you see, most of my problems go with the documentation, and not with the code, which usually I find well written - at least, the code *I* have read. A more strict policy about API documentation would be good news, and more abstract (vision, architectural) documentation 'd be wonderful news. Cheers, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- signature.asc Description: Questa รจ una parte del messaggio firmata digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
