Sorry about my other issues Ted. But if you would like to give
me a change, I would like to help out on ext4 development.
Just tell me what I should read before I start helping out:).
Cheers Nick
On Thu, Jul 24, 2014 at 10:29:49PM -0400, Nick Krause wrote:
> Sorry about my other issues Ted. But if you would like to give
> me a change, I would like to help out on ext4 development.
> Just tell me what I should read before I start helping out:).
So here's my concern. The patches and questions which you've sent to
LKML seem to indicate either that (a) you are incredibly sloppy, (b)
you're technically not very capable, or (c) you were so enthusiastic
to Make A Difference that you were sending out patches and asking
questions without spending any time to think, test, and spending time
doing research.
Whichever it is, the worry to me is that you will consume far more of
my time and other developers than the actual effort you will actually
end up contributing. So the "help" ends up sucking away precious
developer time and bandwidth.
If you can send pointers to actual technical work you've done that
might pursuade folks that you can actually contribute in a positive
fashion, that might be helpful.
Regards,
- Ted
On Fri, Jul 25, 2014 at 10:59 AM, Theodore Ts'o <[email protected]> wrote:
> On Thu, Jul 24, 2014 at 10:29:49PM -0400, Nick Krause wrote:
>> Sorry about my other issues Ted. But if you would like to give
>> me a change, I would like to help out on ext4 development.
>> Just tell me what I should read before I start helping out:).
>
> So here's my concern. The patches and questions which you've sent to
> LKML seem to indicate either that (a) you are incredibly sloppy, (b)
> you're technically not very capable, or (c) you were so enthusiastic
> to Make A Difference that you were sending out patches and asking
> questions without spending any time to think, test, and spending time
> doing research.
>
> Whichever it is, the worry to me is that you will consume far more of
> my time and other developers than the actual effort you will actually
> end up contributing. So the "help" ends up sucking away precious
> developer time and bandwidth.
>
> If you can send pointers to actual technical work you've done that
> might pursuade folks that you can actually contribute in a positive
> fashion, that might be helpful.
>
> Regards,
>
> - Ted
Ted,
I was being sloppy. I screwed up if you want my help still, please
let me known.
Nick
Hi Nick,
Ext4 is relatively stable, i think there are a lot of things to do
for Btrfs development, maybe you can take a notice:
https://btrfs.wiki.kernel.org/index.php/Main_Page
> Sorry about my other issues Ted. But if you would like to give
> me a change, I would like to help out on ext4 development.
> Just tell me what I should read before I start helping out:).
> Cheers Nick
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 25, 2014 at 11:22:02AM -0400, Nick Krause wrote:
> I was being sloppy. I screwed up if you want my help still, please
> let me known.
Well, tell you what. Why don't you start by downloading the following
git repository:
git://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git
And then start by trying to use kvm-xfstests. There are some tests
which are known failures; some are false positives, some are just bugs
that we haven't gotten around to fixing. (This is especially true for
bigalloc, which has a number of failures that still need to be tracked
down.)
The main rule that we follow is that we don't want to see any
regressions. So extending kvm-xfstests by writing a script which
analyzes the output of the get-results scripts so that regressions can
be automatically flagged would be a good and useful thing to add.
Another thing that would be useful is a script which automates using
kvm-xfstests to drive "git bisect". Typically what happens after we
discover a regression is to try to check and see of the failure is
easily replicable using a single xfstests, and then to start bisecting
from the baseline run where the test was successful, to try to find
the guilty bisect. Automating this would be very useful.
This will hopefully get you started on the testing side of things,
which is also a good way to start learning about how ext4 works.
Cheers,
- Ted
On Fri, Jul 25, 2014 at 11:24 AM, Wang Shilong
<[email protected]> wrote:
> Hi Nick,
>
> Ext4 is relatively stable, i think there are a lot of things to do
> for Btrfs development, maybe you can take a notice:
>
> https://btrfs.wiki.kernel.org/index.php/Main_Page
>
>
>> Sorry about my other issues Ted. But if you would like to give
>> me a change, I would like to help out on ext4 development.
>> Just tell me what I should read before I start helping out:).
>> Cheers Nick
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks Wang,
I will look into brtfs development later today.
Cheers Nick
On Fri, Jul 25, 2014 at 11:59 AM, Nick Krause <[email protected]> wrote:
> On Fri, Jul 25, 2014 at 11:24 AM, Wang Shilong
> <[email protected]> wrote:
>> Hi Nick,
>>
>> Ext4 is relatively stable, i think there are a lot of things to do
>> for Btrfs development, maybe you can take a notice:
>>
>> https://btrfs.wiki.kernel.org/index.php/Main_Page
>>
>>
>>> Sorry about my other issues Ted. But if you would like to give
>>> me a change, I would like to help out on ext4 development.
>>> Just tell me what I should read before I start helping out:).
>>> Cheers Nick
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Thanks Wang,
> I will look into brtfs development later today.
> Cheers Nick
Hey Ted,
I will look into this later today.
Cheers Nick
On 7/25/14, 10:41 AM, Theodore Ts'o wrote:
...
> This will hopefully get you started on the testing side of things,
> which is also a good way to start learning about how ext4 works.
>
> Cheers,
>
> - Ted
The old adage on IRC is "Don't ask to ask; ask." In
development-land, it's more like "Don't ask to help; help."
The trick is knowing what constitutes "help." Asking for
detailed instruction is not "help."
Over on the btrfs-list, Hugo had a good set of suggestions as
well; some are btrfs-specific, but in general, good advice for
anyone trying to get engaged with an upstream project:
>From Hugo -
...
> My recommendations for you, if you want to work on btrfs, are:
>
> * Build and install the latest kernel from Linus's git repo
>
> * Read and understand the user documentation [2]
>
> * Create one or several btrfs filesystems with different
> configurations and learn how they work in userspace -- what are the
> features, what are the problems you see? Actually use at least one
> of the filesystems you created for real data in daily use (with
> backups)
>
> * Build the userspace tools from git
>
> * Pick up one of the userspace projects from [3] and implement that.
> If you pick the right one(s), you'll have to learn about some of
> the internal structures of the FS anyway. Compile and test your
> patch. If you're adding a new feature, write an automated xfstest
> for it as well.
>
> * Get that patch accepted. This will probably involve a sequence of
> revisions to it, multiple versions over a period of several weeks
> or more, with a review process. You should also send your test to
> xfstests and get that accepted.
>
> * Do the above again, until you get used to the processes involved,
> and have demonstrated that you can work well with the other people
> in the subsystem, and are generally producing useful and sane code.
> It's all about trust -- can you be trusted to mostly do the right
> thing? (So far on linux-kernel, you've rather demonstrated the
> opposite: your intentions are good, but your execution leaves a lot
> to be desired)
>
> * Use the documentation at [4], and the output of btrfs-debug-tree to
> understand the internal structure of the FS
>
> * Pick up one of the smaller, more self-contained ideas from the
> projects page [5] (say, [6] or [7]) and try to implement it. Again:
> build, write test code, test thoroughly, submit patch for review,
> modify as suggested by reviewers, and repeat as often as necessary
>
> Hugo.
On Fri, Jul 25, 2014 at 12:07 PM, Eric Sandeen <[email protected]> wrote:
> On 7/25/14, 10:41 AM, Theodore Ts'o wrote:
>
> ...
>
>> This will hopefully get you started on the testing side of things,
>> which is also a good way to start learning about how ext4 works.
>>
>> Cheers,
>>
>> - Ted
>
> The old adage on IRC is "Don't ask to ask; ask." In
> development-land, it's more like "Don't ask to help; help."
>
> The trick is knowing what constitutes "help." Asking for
> detailed instruction is not "help."
>
> Over on the btrfs-list, Hugo had a good set of suggestions as
> well; some are btrfs-specific, but in general, good advice for
> anyone trying to get engaged with an upstream project:
>
> From Hugo -
>
> ...
>
>> My recommendations for you, if you want to work on btrfs, are:
>>
>> * Build and install the latest kernel from Linus's git repo
>>
>> * Read and understand the user documentation [2]
>>
>> * Create one or several btrfs filesystems with different
>> configurations and learn how they work in userspace -- what are the
>> features, what are the problems you see? Actually use at least one
>> of the filesystems you created for real data in daily use (with
>> backups)
>>
>> * Build the userspace tools from git
>>
>> * Pick up one of the userspace projects from [3] and implement that.
>> If you pick the right one(s), you'll have to learn about some of
>> the internal structures of the FS anyway. Compile and test your
>> patch. If you're adding a new feature, write an automated xfstest
>> for it as well.
>>
>> * Get that patch accepted. This will probably involve a sequence of
>> revisions to it, multiple versions over a period of several weeks
>> or more, with a review process. You should also send your test to
>> xfstests and get that accepted.
>>
>> * Do the above again, until you get used to the processes involved,
>> and have demonstrated that you can work well with the other people
>> in the subsystem, and are generally producing useful and sane code.
>> It's all about trust -- can you be trusted to mostly do the right
>> thing? (So far on linux-kernel, you've rather demonstrated the
>> opposite: your intentions are good, but your execution leaves a lot
>> to be desired)
>>
>> * Use the documentation at [4], and the output of btrfs-debug-tree to
>> understand the internal structure of the FS
>>
>> * Pick up one of the smaller, more self-contained ideas from the
>> projects page [5] (say, [6] or [7]) and try to implement it. Again:
>> build, write test code, test thoroughly, submit patch for review,
>> modify as suggested by reviewers, and repeat as often as necessary
>>
>> Hugo.
>
>
I have got some work in brtfs for now , Ted so I won't
be able to run the tests for you for the next few weeks
probably. Sorry about the issues, but brtfs seems
more work then ext4 as of this point in time.
Nick
On Mon, Jul 28, 2014 at 12:01:54AM -0400, Nick Krause wrote:
> I have got some work in brtfs for now , Ted so I won't
> be able to run the tests for you for the next few weeks
> probably. Sorry about the issues, but brtfs seems
> more work then ext4 as of this point in time.
Yes, that's probably true.
One bit of advice. I'd encourage you to think about this not about
your lending help to a project. At your level of experience, you will
be consuming far more project development resources than you will be
contributing, no matter whether it is btrfs or ext4. I'd suggest that
you focus on learning, and in order to do that, you will need to focus
on one area --- and by that I mean not just one subsystem, but one
feature or one specific subarea --- for a sustained amount of effort.
I have to agree with Hugo Mills' observation that you are "bouncing
all over the place like a hyperactive puppy". His advice is on the
mark; listen to it.
There are no short cuts. Malcolm Gladwell's book "Outliers" quotes
some studies which show that on average, master musicians have
accumulated an average 10,000 hours of practice before they achieved
mastery. Some other sources have "debunked" Gladwell's claim by
showing in their studies, it has required 10,000 to **30,000** hours
of practice. So if anything 10,000 hours is not a magic threshold,
and it might be much more than that for some.
No doubt you will be higher functioning contributor --- a journeyman
--- before you achieve complete mastery of the craft of programming,
but at this point, you are barely an apprentice. And as such, people
who spend time hand holding you are doing so in the hopes that some
point, the investment the OSS community has put into you will pay off,
and you will start adding more value than you are subtracting, and
then, in turn, that you will "pay it forward". But that point, at
which the breakeven is reached and you can start contributing at a
high level and perhaps, mentoring other enthusiastic newocmers, is
months if not years away.
Good luck on your journey,
- Ted
On Mon, Jul 28, 2014 at 8:45 AM, Theodore Ts'o <[email protected]> wrote:
> On Mon, Jul 28, 2014 at 12:01:54AM -0400, Nick Krause wrote:
>> I have got some work in brtfs for now , Ted so I won't
>> be able to run the tests for you for the next few weeks
>> probably. Sorry about the issues, but brtfs seems
>> more work then ext4 as of this point in time.
>
> Yes, that's probably true.
>
> One bit of advice. I'd encourage you to think about this not about
> your lending help to a project. At your level of experience, you will
> be consuming far more project development resources than you will be
> contributing, no matter whether it is btrfs or ext4. I'd suggest that
> you focus on learning, and in order to do that, you will need to focus
> on one area --- and by that I mean not just one subsystem, but one
> feature or one specific subarea --- for a sustained amount of effort.
> I have to agree with Hugo Mills' observation that you are "bouncing
> all over the place like a hyperactive puppy". His advice is on the
> mark; listen to it.
>
> There are no short cuts. Malcolm Gladwell's book "Outliers" quotes
> some studies which show that on average, master musicians have
> accumulated an average 10,000 hours of practice before they achieved
> mastery. Some other sources have "debunked" Gladwell's claim by
> showing in their studies, it has required 10,000 to **30,000** hours
> of practice. So if anything 10,000 hours is not a magic threshold,
> and it might be much more than that for some.
>
> No doubt you will be higher functioning contributor --- a journeyman
> --- before you achieve complete mastery of the craft of programming,
> but at this point, you are barely an apprentice. And as such, people
> who spend time hand holding you are doing so in the hopes that some
> point, the investment the OSS community has put into you will pay off,
> and you will start adding more value than you are subtracting, and
> then, in turn, that you will "pay it forward". But that point, at
> which the breakeven is reached and you can start contributing at a
> high level and perhaps, mentoring other enthusiastic newocmers, is
> months if not years away.
>
> Good luck on your journey,
>
> - Ted
Ted,
I am already reading the brtfs good and found some work there.
Regards Nick