Re: Lowering the barrier (was: Re: build systems)

[Braden McDaniel <braden endoframe com>]

On Sun, 2007-11-11 at 00:37 +0000, 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 being familiar with
shell scripting and POSIX make. Those are tools of which you need to
have a basic grasp to do all kinds of development-oriented things on
POSIX systems.

Perhaps you could provide some more details about your experience; it's
not clear what you had to do (and thus why it was perceived as unduly
onerous).

It is an unfortunate fact that there are many projects that apply the
autotools in a suboptimal way. Sometimes significant build system
improvements can be made within the framework that the autotools
provide. Bug reports are entirely appropriate in such cases; but
unfortunately it usually takes someone knowledgeable about autotools
usage in order to spot them.

> 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.

For becoming acquainted with the autotools, GNU Hello is a good place to
start.

> *** I wonder if there could be one project (or a few, to cover most
> important areas) chosen as the 'examples project' (something fairly
> sexy, but well established, with simple components and already well
> documented code) that would have extra effort put in on commenting and
> 'correctness' of implementation - this way anyone looking for an
> example could be directed to that project and people would be sure to
> be doing the right thing by learning from it.

Big projects tend not to be simple. And their developers may not
appreciate a bunch of comments and documentation that, from the point of
view of experienced developers, states the obvious.

That is not to say that there aren't big projects out there that are
worth your while to understand and use for guidance. But have reasonable
expectations.

-- 
Braden McDaniel                           e-mail: <braden endoframe com>
<http://endoframe.com>                    Jabber: <braden jabber org>