launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

Thank you for the survey, Jono.

Some quick thoughts on the basis of items on the full results that you gave (http://paste.ubuntu.com/345051/). Below, I quote excerpts from the results in triple-quote blocks, and then give a reply.

"""
 * Working on related branches (the kind of stuff that eventually gets packaged
   as an egg) is very painful. If we want to effectively work with the many
   separate projects we maintain we should have a single-action procedure to do
   that.
"""

Perhaps people who feel this way could give me an idea of what they find very painful.  I currently only know two ways in which it can be very painful.  (1) You don't know how to do it.  I've tried to document it and help others, but maybe some people could help me find a more effective approach.  (2) You need to do a whole bunch of related branches at once.  If this sort of thing actually comes up frequently, which would surprise me, then perhaps we can add some automation.

"""
 * It's really annoying that creating a new branch, and have it ready to
   run tests take a long time. What I do is:

1. Create the branch and working tree

2. Link eggs and download-cache

3. Run 'make'

...

   As a side note, 2) shouldn't be necessary. It's a simple fix, we should
   do what I did to lazr-js, and link eggs and download-cache
   automatically, if some environment variables are set.
"""

Sounds reasonable-ish, though rocketfuel-* handle this now, and we should make sure that the build change here doesn't mess up the usage patterns that the LOSAs have right now.

"""
 * Making a new branch is new excrutiatingly slow. It took me 10 minutes to do
   one yesterday as I was short of real RAM and rf-branch seems RAM hungry.
   It's been like this ever since buildout and it drives me *bonkers*.
"""

Huh.  My perceptions have been that making a branch is now much faster than when I started, which I have attributed to bzr improvements and shared eggs.  People who feel the way this quote describes should maybe talk to me.

My first guess is that you are working in some way that does not let you share eggs across branches.  *If* this is the case, then my observation would be that rocketfuel-* is the blessed and supported way for building branches, and if you are doing something else, I certainly understand and sometimes do the same, but we need to either acknowledge that you are on an "expert" path and are responsible for your own safety, or that we need to have explicit support for a non rocketfuel-* approach.  Either way, IMO the idea should be that there is a path (or two) that is supported, documented, and improved; if you stray off the path for your own reasons, that's your business: the maintenance of your path is your own responsibility (until we all decide to add it to the "supported" list).

On the other hand, maybe people with this experience are in fact sharing eggs.  In that case, we should see what the problem is.  I believe and hope that this experience is unusual.

"""
 * It seems silly to constantly consult the zcml for how urls, view classes,
   and templates are mapped. It would be nice if view names and template names
   were mapped by convention instead of by configuration, but that wouldn't
   help with urls. Maybe we just need a script to discover the mappings more
   quickly.
"""

FWIW, this is the kind of thing that Grok technology can provide.  The discussion of the pros and cons of this particular idea within our own code base has not yet been run to ground, to my knowledge.  I am open to this perspective.

"""
 * I meant to do this myself, but it would be nice to have ctags generated so
   that vim could jump to the library method definition without instead of me
   grepping through the eggs.
"""

Please see ``bin/tags -v`` (or ``make tags``) and ``bin/tags -e`` (for you emacs users).

"""
 * ./bin/lint has a lot of false positives mainly because it can't resolve a
   bunch of lazr modules.
"""

I agree that this is annoying.  I thought I knew how to fix it but someone else had tried what I had in mind and it didn't work.  I don't know what to do about this ATM, other than more digging.

Gary