[Yt-dev] Parallelism, or, how I learned to stop worrying and love open source development

Matthew Turk matthewturk at gmail.com
Sat Aug 21 00:36:44 PDT 2010


Hi Jeff,

Thanks for your thoughtful reply.

On Fri, Aug 20, 2010 at 3:01 PM, j s oishi <jsoishi at gmail.com> wrote:
> Hi All,
>
> I have a few brief thoughts to add.
>
>> Overall, though, what really needs to happen is some kind of *buy-in*
>> on the part of the user -- which in this case is anyone who has had
>> trouble with yt.  I have pulled back from yt-users, and I'm really
>> happy that everyone else has stepped up.  But I'm worried that as time
>> goes on, people will pick up knowledge in ways that aren't indexable
>> by search engines and then this knowledge keeps getting re-learned.
>
> I'm 100% in agreement here about increasing reporting of bugs. I
> myself am quite guilty of not formally reporting bugs. One thing we
> might do is to attempt to force yt to ask people to report bugs when
> it crashes. I'm not sure how easy this might be, but I often report
> bugs when software I use explicitly tells me to.

After I read your email, I set up a quick demo of how this might go.
I've placed it here:

http://paste.enzotools.org/show/1107/

What this does is, unless asked not to or if it detects someone else
has already done so, register an excepthook.  (We have two mechanisms
for doing this in place in yt already: --paste, --rpdb, and today I
added two more of --detailed and --paste-detailed, which print out
some better contextual information.)  If an exception is handled by
the excepthook, the code will print the exception and ask if the
traceback should be submitted to the pastebin.  It times out after ten
seconds.

This is an option.  In fact, we could include a little blurb about how
to report it as a bug.  What does everyone thing?  I'm sort of on the
fence about this mechanism.

> On the other hand, I think we need to make it as easy as possible for
> people to report bugs. OpenID is a great idea, and would definitely
> help. I personally recieve a few bug reports from users privately
> every now and again. These bugs easily fall into two categories: ones
> I fix right away, and those that fall into pergatory. I would love to
> simply say "report the bug on trac, please". Of course, I acknowledge
> my own fault in not doing myself when handed these bugs.

I have added OpenID support.  It's a bit glitchy, in that I can't
quite decipher how to make Trac only show one login or one login-name
at a time.  I'd prefer if developers logged in here:

http://yt.enzotools.org/login

but it's been tricky to get a unified interface going.  Anyone who
logs in with OpenID is now able to report bugs.  Furthermore, I've
added links to bug reporting on the main pages.  And, finally, I've
set it such that all changes to tickets get emailed to yt-svn.  This
should help to make sure we don't miss anything.

> This is a great idea. Can we have trac email us our bugs, or let us
> know when a bug is assigned to us, or when a new bug comes in? This
> way we, the non-Matt yt developing community, can assign incoming
> bugs? I apologize if these are simple things that are already well
> known, but I'd like to make sure we can make it as easy as possible to
> have the entire yt development team responding to and categorizing
> bugs in addition to fixing them.

Yup, I have set it to email yt-svn.  I think this is the best wya of
handling it.  I've also re-worked the components for tickets a bit, so
that instead of module names they are coarse names of regions in the
code: documentation, enzo, orion, cookbook, yt, halo_finding ...

> I think we need to create a roadmap for future versions of yt. I think
> we need to think seriously about what needs rewriting in the
> internals, what features we want to add, and how long we want to allot
> ourselves to achieve those goals. Furthermore, we need to explicitly
> and publically commit to doing those things we're interested in. Any
> unassigned features/rewrites would then be added to a wishlist, which
> we could advertise to new users as a way to get in the door.

This is the best articulation of a gameplan I've heard yet, and I like
it.  I nominate you to spearhead this, but I think a roadmap will
probably write itself ...

> One
> uphill battle is that most users of yt are astronomers, who do not
> necessarily have much exposure to free software nor do they
> necessarily have a lot of desire to get really good at software
> development. This is very sad, of course, because being a bit better
> at software development is something that would help anyone using any
> large AMR simulation codebase.

Both of these are true.  I think that the lack of exposure to Free
Software is damaging, because I think that for myself (and I know you
feel similarly) my feelings on collaboration and communication have
been shaped by my exposure to the ideals of the free and open source
software movement, and I think they have been beneficial to me.

> I also agree that documentation features should be classified as bugs.
> Perhaps we should poll yt-users fairly frequently (once or twice a
> year) in order to solicit documentation bugs/feature requests.

Excellent idea, and I like this form submit mechanism -- it's gotten
very nice uptake.

> thanks, and many thanks to Matt for the amazing amount of work he's
> put in to yt thus far.

Thank *you*.

Best,

Matt

>
> J.S.
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list