[Xiaomi Redmi 1S] thewisenerd:
Please do remember that you can't do much by posting in this thread. If you really do want to show your support, please follow one or more of the following:

1. Volunteer: for testing new releases. Developers usually have their own set of testers, and if some are looking for testers, volunteer and help them by providing logcats, kmsgs, etc.[1]

2. Support: Show your support with the help of your signature, or publicly stating (in the kernel thread and kernel thread alone[2]) your feedback about the kernel and your suggestions for improvement.

3. Reporting Bugs: This is a crucial part. A bug report has to be as valid and understandable as possible. If you are reporting an error in a ROM, a 'logcat' is helpful. If you are reporting an error, which you think is in the kernel, you NEED to provide a 'kmsg', and usually the 'last_kmsg' in case of a reboot.

[1]: In case the developer isn't looking for testers, be rest assured that the dev has enough testers already. But that doesn't mean you have to wait for someone to say that the kernel is stable. As soon as the kernel releases, you are expected to volunteer and report any bugs that the testers might have missed to report.

[2]: Why it is stated so, is that some ROM developers feel that it is the fault of/in the kernel that the error that you are using. If you say in an XYZ ROM thread: "m using your ROM with XYZ kernel, it s awsum!", it IS often looked at as an understatement by many. If your performance/batterylife/abc did really improve with a custom kernel, be sure to keep the feedback only on that particular kernel. Another reason for refraining from stating so on ROM threads is that it is often the starter of a "which kernel is better?" argument, and then that goes on to clutter an original development thread. You are free to use whichever kernel you want to. You, however, are NOT free to try take it, and shove it down someone's throat. Okay... I might have overstated that. So, find a kernel that you are looking for, and settle down. If you think there are features that you want added in the kernel, that the dev might not really want to add, you are free to write it on your own, or cherry-pick it, and make your own custom kernel

And in case you are a developer:

1. Retaining authorship: This is a very crucial part. If you look at it, a lot can be done, if you don't bother who gets the credit. BUT, that doesn NOT mean that you have to take the work of someone, and try to pass it off as your own! (P.S. Git allows that. If you have accidentally, or (un)intentionally cherry-picked a commit, but accidentally or (un)intentionally reset the author, you can go back and change its author. A simple search on "Change commit author at one specific commit" will get you going in the right direction.)

2. Cherry Pick: This is again another important thing to do. During the inception of the Linux kernel, there were around 2000 people who had contributed code. 2000. It was not 'one' person who wrote the kernel. And, now; if there was something fundamentally wrong with the kernel, or you do not understand a particular part of the code, who would you go to? There are over 2000 people on your list. Obviously, the list will be less for the number of people who have actually made changes to that particular file, but still you'd be left with slightly over 10 people for each file. The thing is that one cannot really track a part of code, or have a look at who wrote what and stuff if we were to simply 'not' cherry-pick, 'not' retain authorship, but squash all commits into one.

<quote>If git history is not important to you, you can avoid a lot of trouble by simply requiring the commits be squashed</unquote>

yes. holds true. iff all the commits are mostly written by the same person and mostly focus upon developing for a particular feature. If you are cherry-picking, please do NOT merge in your changes with whatever stuff you cherry-picked. Instead, cherry-pick a certain commit, retain authorship, and make changes && commit under your own name. That way, you save the trouble of pissing off someone who made around 100 commits on a certain feature, and doesn't get authorship, and still get to keep authorship on the changes that 'you' really make.

But then, here too, with squashing commits, you can not follow the code, where the bug was introduced, were there any solutions to it, etc, etc.

A solution to that? Use branches. Put all your commits regarding a certain feature in a particular branch, and merge in that branch. That way, you can track which part of the code is creating a problem.

3. Contribute: You are doing a good job, by trying to contribute to the kernel. Always remember, contribute 'back'. Those ~2K people are not the only ones we owe the linux kernel to, but also the <n> number of people who have contributed 'back' to it over the past years. Since this is a device specific kernel, you can contribute towards making the kernel better, by helping others. Write legible (enough) commits, clean and "separate", so that every feature/bugfix/enhancement is an individual commit, thus helping others to easily cherry-pick your stuff, collaborate with other devs in solving problems, etc. If you figure out a fix for a particular problem, do NOT merge in your fixes while cherry-picking stuff. Instead, make it as a separate commit. What you think was a fix, or needs to be fixed, might NOT have always been the dev's original intention. So, keeping your changes separate from the changes that you cherry-pick is really helpful in tracking bug fixes. (tracking bug fixes? you might ask. yes. The way a certain bug was fixed holds considerably more significance than why/how the bug was caused in the first place, and helps identify the same. Read it once more, you'll understand.)

That's my two four cents.

peace.

twn out.