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. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
