Gleanings from the GSoC Mentor Summit

Mon Oct 24 20:03:17 UTC 2011

Hello:

I'll offer to "take on" the documentation thing.  The "Constructive 
Whining" document I've been working on, essentially,boils down to one 
thing: Documentation, to include gathering up and setting a torch to 
(well ..., at least properly archiving) all of the incorrect and so 
very, very misleading documentation, floating out on the net right now.  
(I've spent hours and hours and hours over these last several weeks, 
following down briar-and-bramble-filled trails because of out-of-date 
documentation, /e.g.,/ /parrot/docs; WikiBooks; and 
http://trac.parrot.org/parrot/wiki/HLL%20Resources, to name just a few 
of the examples.)

This said, I am very "new" (by which I mean old and returning after 
about almost nine years of absence from Parrot) and, consequently, may 
not be the best choice to take the lead on something of this 
magnitude.[*]  I'll leave this for others to decide.  Still, /I/ 
seriously and sincerely want/need Parrot's documentation to "make 
sense."  Because, as of now, it is, to parrot (pun intended) cotto, 
"something of a mess."[**]

Regards,

Alvis

P.S.   If it helps: I was the Editor-n-Chief of my law school's Law 
Review; clerked (meaning I substantially wrote several of the opinions) 
for a former State Supreme Court Justice; wrote and edited many, many 
legal briefs, legal opinions, yada, yada; published a few law review/law 
related articles; and published several op-eds in various smallish 
newspapers.  I have also edited, but not written, several technical 
manuals for, now, old legacy systems.  None of which is impressive.  I 
mean merely to point out one thing: I can write.

*Note:* I'm happy to give anyone a run down on my technical skills as 
well (if anyone is
              actually interested).

P.S.S. Duke, I am /still/ working on the "Constructive Whining" 
document.  Fortunately, I discovered something this weekend which 
"sheds" a great deal of light both on Parrot and on it's document set.  
Unfortunately, however, this has required me to re-write, almost 
completely, what I hadearlier written.  (I know these are rather opaque 
remarks, but, hopefully, they'll make sense when I complete the re-write 
and send it to you.)

---------------
[*]   This said, if someone doesn't do it, Parrot may be hard-pressed to 
support the needs of its prospective HLL-developers, who, I believe, 
want their projects to perform superior to, but at least competitive 
with, projects developed on the JVM or the CLI.

[**]  I would like to take this opportunity to make mention of one 
important point: As I am certain everyone on this list is aware, the 
success of getting the documentation set in order will require (1) 
specific direction "from the top," so-to-speak, and (2) a great deal of 
cooperation from the "core" developers.  What I'm trying to say is, in 
order for a documentation project to succeed, the documenting of the 
project must be seen, by all, as /almost[***]/ as important as the code.

       And, truthfully, it is.  If, for no other reason than, project 
membership changes, but the project (and the reasons for its coming into 
being, so-to-speak), hopefully, goes on, and new members are left with 
whatever code and documentation the former members left behind.  In 
short, it is /not/ just a project-maintainability-type thing, but a 
project-sustainability-type thing.

[***] Fwiw, I never have been one to subscribe to the notion that the 
documentation is "/just as important as the code./"  Why?  Two reasons: 
(1) The code is the deliverable and (2) in the end, you /have/ the 
code.  And, although it may prove unreasonably and unnecessarily painful 
to do so, if one person wrote it -- given sufficient desire and time -- 
another /can/ figure it out.  It's just that, often, the latter are 
lacking.)

      These latter remarks are just my $0.02 and, perhaps, all they're 
worth. :-)

On 10/24/2011 12:45 PM, Jonathan "Duke" Leto wrote:
> Howdy,
>
> I am at the Git Together 2011 right now, so I am time constrained.
>
> Documentation Shepherd:
> https://twitter.com/#!/parrotvm/status/128518846997999618
>
> To clarify, I have been fiddling around with Buildbot, but I don't care too
> much about whether we use Jenkins of Buildbot. But we absolutely, positively
> need to have distributed testing. This will solve *so many problems*.
>
> I talked to Alexander Graf from qemu and he showed me how I can
> generate binary rpms for Parrot for many different platforms via the
> build.opensuse.org build server. I will send another email with all
> the gory details.
>
> I talked with RTEMS people and they are still very excited about getting Parrot
> on RTEMS. They are very close to getting dlfunc support in RTEMS, which is
> huge, and will lay the foundation for dynamic languages on real-time systems.
> No concrete plans yet, but wheels are turning.
>
> +1 to setting up a community metrics website. Perhaps metrics.parrot.org ?
>
> Duke
>
> On Mon, Oct 24, 2011 at 1:20 AM, Christoph Otto<christoph at mksig.org>  wrote:
>> Howdy,
>>
>> This weekend, dukeleto++ and I had the privilege of attending the GSoC
>> Mentor Summit.  The summit is a participant-run unconference for mentors
>> of GSoC projects, by the hackers for the hackers, at Google's offices
>> and on their dime.  Both of duke and I picked up a treasure trove of
>> ideas and made some good connections with OSS hackers who we wouldn't
>> usually get to hang out with.  I tried to take notes at all the sessions
>> I attended and have boiled them down to a delicious list of action
>> items.  There's some great stuff in the list that I hope will help make
>> Parrot a better project and community, but it's considerably more than I
>> can handle all by my lonesome.  Below is a summary list of the tasks I
>> came up with.
>>
>> * Jenkins -  it's Java, but it's also awesome.  We need better CI and
>>   many projects are using Jenkins to some very cool (and very lazy)
>>   automated testing.  This would also help us make better use of the GCC
>>   compile farm and OSUOSL's Supercell.
>> * pdf.js apparently has a pretty cool bot.   Someone outght to see if
>>   there's anything worth stealing and report back to parrot-dev.
>> * dddash.ep.io is a spiffy and simple graphical display of developer
>>   metrics.  This might be fun to put on a subdomain of parrot.org.
>> * docs owner - our docs have always been something of a mess.  If
>>   someone's interested, we could benefit from having a hacker who owns
>>   our documentation and makes it his/her business to make our docs
>>   shine.  This is a substantial commitment.
>> * gsoc/gci analysis - We need to know how gsoc and gci are helping
>>   Parrot, what our goals are and if we're meeting them.  We need
>>   someone to lead this effort and to do some reporting about how gsoc
>>   has gone in the past and where we can improve.  Note that Google
>>   likes orgs that do this because it shows that we're concerned about
>>   long-term results.
>>
>> I'll be going through them in more detail at #parrotsketch this Tuesday.
>> If anything on the list looks interesting to any of you, please drop by
>> and we'll see about putting you to work.  Alternately, just jump right
>> in!  It's almost always better to ask for forgiveness than permission
>> when hacking on Parrot.*  dukeleto++ has already started seriously
>> looking at Jenkins and I've got a couple of blog posts to write and toys
>> to experiment with.
>>
>> All this may be more than we can handle during one #ps, but I hope we
>> can find people to work on a couple of these items.  Be thinking about
>> what you'd like to do and I'll see you at #ps,
>>
>> Christoph
>>
>>
>>
>> *Except where it's not.
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20111024/79148c27/attachment-0001.html>