Re: New Outreachy Applicant

[George Dunlap <george.dunlap@citrix.com>]

On 06/10/16 15:26, Ronald Rojas wrote:
> On Wed, Oct 05, 2016 at 06:44:08PM +0100, George Dunlap wrote:
>> On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap <george.dunlap@citrix.com> wrote:
>>> Thanks for this -- if you're up for it, let me see what kinds of next
>>> steps you can do (obviously when you have the opportunity).
>>
>> So there are a couple of things we could do next.
>>
>> * If you want a simple change that you can use to get experience with
>> sending patches to the list:
>>
>> There are a number of instances in tools/libxl/xl_cmdimpl.c where
>> where domid is listed as uint32_t (or libxl_domid), but the printf
>> specifier is used as '%d'.  Change this to '%u'.
>>
>> * If you want an investigation to do:
>>
>> At least a couple of times I've accidentally run a golang program with
>> libxl functionality on a system that wasn't running Xen (i.e., I'd
>> rebooted onto Linux baremetal).  Instead of throwing an error, as you
>> would expect, it crashed with a SEGV.
>>
>> Try to reproduce this bug, and see if you can fix it.
>>
>> * If you want to dive into the project:
>>
>> I can send you my most recent version of libxl.go (which has a few
>> more things implemented).  Modify it so that it builds as a package (I
>> think "xenproject.org/xenlight" is probably the best name), and wire
>> it into the build system in tools/golang/xenlight, and installs into
>> $prefix/share/gocode/src/xenproject.org/.
>>
>> The key thing with the last one is not to get too bogged down in
>> systems you're not familiar with -- if you get stuck ask for help
>> relatively quickly; and if it's turning into a mess, I can just do the
>> Makefile side of things so that you can get to the actual Go side of
>> the project.
>>
>> What do you think?
> 
> I think I would prefer to do the first task and then the last task. I 
> have not used stgit so I think it would be beneficial to do that first
> and then I can dive into the project. 
> I will probably do the first task on either Sunday or Monday, depending
> on when I can start working on it. The packaging task seems much more 
> difficult and I really only have a significant amount of time to work 
> on this during the weekend, so it'll probably take 1 or 2 more weeks 
> to complete that. 
> In the meantime I think it would be helpful to look at the makefile 
> of another subproject from xen so I could get some inspiration on how 
> structure this new project. Is there any Makefile that you think I 
> should look at? If not I'll just read through a couple of files in xen
> and try to follow a similar style. 
> 
> Does that sound like a good plan?

Yes, that sounds good.

I should make it clear --  nobody *expects* work from you until such
time you're being paid. :-)  Doing small tasks (like the %d -> %u
change) helps us get a better idea what your capabilities are, and so
can be helpful for the decision-making process.  But it won't be counted
against you if you don't do any more small tasks; and it *definitely*
won't be counted against you if you don't do the large things.

I've talked about next steps for the larger project because you
expressed an interest in them.  They're there to do if you *want* to,
and if you have time, but it's on a strictly voluntary basis, and you
should absolutely prioritize your schoolwork.

Pressuring people into working for free with the vague promise of
something in the future is usually dishonest, and you should be wary of
anyone trying it on you.

Hope that makes sense. :-)

Let me take a look at a simple example you could use to "wire-in"
something to the build system.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel