All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Farrell <paf@cray.com>
To: lustre-devel@lists.lustre.org
Subject: [lustre-devel] Working on client merge
Date: Wed, 10 Jun 2015 12:59:30 -0500	[thread overview]
Message-ID: <55787B02.4080802@cray.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1506101915280.5463@hadrien>

I suggest breaking it up first by work type.  As Julia noted, 
coccinelle/checkpatch/etc fixes (coding style, straightforward errors 
caught by the tools, sparse complaints, warnings, etc.) rarely require 
awareness of the larger flow of the design.

Then there is some other types of cleanup that require more Lustre 
knowledge to tackle.  If possible, those would be better for someone 
like Ben (or you, James) to work on.  What do we have for that kind of work?

- Patrick

On 06/10/2015 12:16 PM, Julia Lawall wrote:
>
> On Wed, 10 Jun 2015, Simmons, James A. wrote:
>
>>> Where would be a good place to get started with helping merge the client
>> into mainline?
>>
>>   
>>
>> Hi Ben
>>
>>   
>>
>>       Thanks for helping out for this work. I added people in the chain that
>> have contributed a great
>>
>> deal to the upstream client so we can coordinate our work. Also I like to
>> make people aware
>>
>> a lustre IRC channel does exist.   Andreas can supply the details about the
>> IRC channel. Currently
>>
>> my work has been focused on the libcfs/lnet layer. I had discuss early with
>> Mike Shuey  since he
>>
>> was also working in that area but will be migrating to the lustre core.
>>
>>   
>>
>>      Since more people are getting involved we need to find  a way to break
>> up the work to avoid
>>
>> duplicate work. Should the work be broken  up by layer, i.e lov, mdc, or by
>> task such as removing
>>
>> specific checkpatch errors with files?
> For the work I have done with Coccinelle, it is more convenient to do the
> whole thing.  Breaking things up by layer is not helpful.
>
> This is just a data point, though. It doesn't have to imply anything about
> how others work on the code.
>
> julia
>
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150610/0dded25b/attachment.htm>

  reply	other threads:[~2015-06-10 17:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-09 14:08 [lustre-devel] Working on client merge Ben Evans
2015-06-10 17:14 ` Simmons, James A.
2015-06-10 17:16   ` Julia Lawall
2015-06-10 17:59     ` Patrick Farrell [this message]
2015-06-10 18:11       ` Chris Hanna
2015-06-10 18:14   ` Christopher J. Morrone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55787B02.4080802@cray.com \
    --to=paf@cray.com \
    --cc=lustre-devel@lists.lustre.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.