hmmmm. This is my 1st Pull Request.
continuous-integration/travis-ci/pr seems to still be in progress, the other checks have been successful.
What's next?

The Travis one takes long to finish. That's normal.
Now it has finished, there are some codestyle issues with your PR. Check the link https://travis-ci.org/joomla/joomla-cms/jobs/195476952 and scroll down. It shows you each file and line where an error is.

Yes, I noticed what you explained.
When I make the fixes and commit them, I just do another pull request? What about all the comments I put in?

I've fixed a number of errors, but I'm not sure what to do with ones like this:

if ($item->home)
{
    ....
}

Ther error message for the above is:

 78 | ERROR | Expected "if (...)\n...{...}\n...else\n"; found "if
    |       | (...)\n...{...}\n...else "

Should I add == true to the if statement? What about then the if statement is:

if (empty(self::$instances[$client]))

This is a bit pedantic, not to mention that I didn't write those lines yet they were in the repo.

When I make the fixes and commit them, I just do another pull request? What about all the comments I put in?

Just push them like you did, it will trigger Travis again. You can do that as many times you want ?

if ($item->home)
{
....
}

There is a space at the end of the first line. That's probably the cause.

This is a bit pedantic, not to mention that I didn't write those lines yet they were in the repo.

It should only show errors for lines you changed something.

if ($item->home)
{
....
}

There is a space at the end of the first line. That's probably the cause.

Thanks for your assistance.
Line 78 is in the constructor method for the JMenu class, and I certainly didn't change it. No spaces anywhere in the entire method, only tabs to set the indents. I also added == true to the if statement in line 78, but am still getting the error.

Try to fix the others first, maybe Travis choked somehow.
There is a space at the end of line 276 and the } else { on line 283 needs to be
} else {

After two editors (Notepad++ and UEStudio), there are no extraneous spaces. The else you referred to, I reformatted it to follow the 3 line style. :(

Well, the long list is gone (DOS formatting issue I think) but the rest are bogus error and should be warnings really. I'm done.

Well, the long list is gone (DOS formatting issue I think) but the rest are bogus error and should be warnings really. I'm done.

Travis is just enforcing the codestyle rules we have (see http://joomla.github.io/coding-standards/).

If they not pass, this PR will never be accepted.
If you need assistance, I'm sure someone will help you with fixing them. Maybe @zero-24 has some spare time?

Ok, I will try getting help. :) Thanks for yours.

I've installed PHPCodesniffer. I'll see how I do tomorrow.

Could someone help me with running PHPCS? I'm getting this error:

PHP Fatal error:  Interface 'PHP_CodeSniffer_Sniff' not found in /Users/me/Downloads/Joomla/joomla-cms/build/phpcs/Joomla/Sniffs/Classes/InstantiateNewClassesSniff.php on line 20

when I run the command:

phpcs --report=full --extensions=php -p --standard=build/phpcs/Joomla .

From the root folder of the Joomla repository, when I run (as per the Joomla! Coding Standards Manual) CodeSniffer, I get an error. Considering I'm trying to fix documentation issues, this is demoralising. The command:

phpcs --report=checkstyle --report-file=build/logs/checkstyle.xml --standard=build/phpcs/Joomla .

Generates this error:

ERROR: The specified report file path "build/logs/checkstyle.xml" points to a non-existent directory

Including /path/to// in the command makes no difference.

I can't help you with setting up codesniffer. I always rely on Travis. Much simpler ?

Anyway, you seem to have figured out most issues. The only one left is a line lenght where you can just wrap it.

Thanks Bakual! Without your encouragement, I think I may have given up. Yes, I split the SELECT statement into an additional line.

Wallah, it's passed!!! :)

What is the next step, if you don't mind me asking?

What is the next step, if you don't mind me asking?

Now it needs manual testing by people. Usually we require at least two successfull tests.

@Napoleon-BlownApart can you please give detailled Test Instructions how to test. Something like #13758

Testing Instructions

Setup

Install latest staging (that includes my _inheritable_ branch)
Enable users to register (or manually create the users; one public, one registered).
Create a menu with 3 items, Home, Register, Edit Profile.
Set the Home menu item to _Public_ Access with _Inheritable_ YES (default).
Set the Register menu item to _Public_ Access but with _Inheritable_ NO (either on the Menu:Item Edit or Menu:Items screens)
Set the Edit Profile menu item to _Registered_ Access with _Inheritable_ YES (default).

Test 1: Visibility of the Menu Item to users.

Test 1.1

Open a browser and visit the site (make sure you are not logged in).
In the menu, you will see menu items "Home" and "Register".

Test 1.2

Register on the site (or login with a registered user)
In the menu, you will only see menu items "Home" and "Edit Profile" ("Register" will not be shown).
Log out.
In the menu, you will see menu items "Home" and "Register".

Test 2: Managing the Inheritable as an Administrator

Test 2.1

On the Menu:Item Edit screen, change the Inheritable property then "Save & Close"
You will see in the Menu:Items list that the menu item reports the state of Inheritable according to your setting.

Test 2.2

On the Menu:Items screen, attempt to change the inheritable property of the DEFAULT page.
You should be presented with an error stating you cannot do this for the default page.

Test 2.3

Choose a non-Default menu item, set  it to un-published AND set it to un-inheritable.
Now choose that same item, on the Menu:Items screen, and make it the Default page.
You should see that this action makes the item both Published as well as Inheritable.

Note I have not implemented this check at the Menu:Item Edit screen level. If necessary, I will do that.

Test 3: Language settings

Change the text of the following language dependent variables according to your requirements. You will need to add these for languages other than en-GB.
Revisit the administrator pages to see your settings.

In administrator/language/en-GB/en-GB.com_menus.ini

COM_MENUS_ITEM_FIELD_INHERITABLE_DESC
COM_MENUS_ITEM_FIELD_INHERITABLE_LABEL
COM_MENUS_HTML_SETINHERITABLE_ITEM
COM_MENUS_HTML_UNSETINHERITABLE_ITEM
COM_MENUS_ITEMS_SET_INHERITABLE_0
COM_MENUS_ITEMS_SET_INHERITABLE_1
COM_MENUS_ITEMS_SET_INHERITABLE_MORE
COM_MENUS_ITEMS_UNSET_INHERITABLE

In _ administrator/language/en-GB/en-GB.ini_

JGRID_HEADING_INHERITABLE_ASC
JGRID_HEADING_INHERITABLE_DESC

In _ administrator/language/en-GB/en-GB.lib_joomla.ini_

JLIB_DATABASE_ERROR_MENU_UNINHETITABLE_DEFAULT_HOME

In _ language/en-GB/en-GB.lib_joomla.ini_

JLIB_DATABASE_ERROR_MENU_UNINHETITABLE_DEFAULT_HOME

@Napoleon-BlownApart have installed latest staging (download on github, "Joomla Update" on tab "Upload & Update").

Click on "Menus > Main Menu" got Error: Unknown column 'a.inheritable' in 'field list'.

Proposal: Move Test instrctions on first Comment, so Community hasn't to scroll down.

Have not tested, but one thing is sure to me : this tip is really unclear. As far as I understand the PR, it deals with access levels.

+COM_MENUS_ITEM_FIELD_INHERITABLE_DESC="Determines if this menu item can be inherited by higher group types."

@franz-wohlkoenig
You have to test by installing the Joomla github version containing this PR
https://github.com/Napoleon-BlownApart/joomla-cms/archive/inheritable.zip

@infograf768 thanks for information.

@infograf768 : I'm not sure what you mean by your comment "this tip is really unclear". Could you please elaborate?

@Napoleon-BlownApart
I mean the tip does not explain what the parameter is for in clear English (which makes it untranslatable in other languages).
Determines if this menu item can be inherited by higher group types.
What is a group type? This notion does not exist in Joomla.
What we have is "User Groups" and "Access levels".

At reading your test instructions
The property determines if higher access levels inherit the menu item. An inheritable menu item will display in the menu for all user groups who inherit visibility of the menu item's set access level. A menu item set to un-inheritable will only be seen by users who belong to the access level group that is set in the menu item.

Therefore imho, the tip should be a condensed form of this, maybe even adding an example.

@infograf768 Same Result after installing the Joomla github version containing
https://github.com/Napoleon-BlownApart/joomla-cms/archive/inheritable.zip

Click on "Menus > Main Menu" got Error: Unknown column 'a.inheritable' in 'field list'. "Fix database" dosn't help.

The update files are missing indeed.

@Bakual, what do you mean by "The update files are missing."

Also, I haven't tested the repo version, but would really like too! I've been working with the files I have in my 3.6.5 Stable-Full install.
How do I install (or create the zip installer) from the repo?

Travis needs a break! I am running PHP v5.3 and it works on my system yet Travis failed. I did not make any changes to the file:

.....S.............................FPHP Fatal error:  Call to a member function getActive() on a non-object in /home/travis/build/joomla/joomla-cms/libraries/cms/application/site.php on line 325

How do I make the system perform another check when there is no code I wish to alter? Do I need to make a 'dummy' change just to trigger Travis/Jenkins?

@infograf768
Higher User Groups inherit from lower User Groups: An Editor inherits viewing privileges from the Author. That is what I mean by 'higher group types'.

what do you mean by "The update files are missing

Look at https://github.com/joomla/joomla-cms/tree/staging/administrator/components/com_admin/sql/updates/mysql. It contains the files which are applied during an update. There are similar forlders for the other databases.
Just create a new file following the pattern. So 3.7.0-2017-01-27.sql and put the needed SQL commands into it.

Also, I haven't tested the repo version, but would really like too! I've been working with the files I have in my 3.6.5 Stable-Full install.
How do I install (or create the zip installer) from the repo?

Just download your branch as zipfile (https://github.com/Napoleon-BlownApart/joomla-cms/archive/inheritable.zip)

Do I need to make a 'dummy' change just to trigger Travis/Jenkins?

We can restart it manually if needed.

I've been able to do a local build which has created the full and update installers.
I've tested the full install and it now works. However, I'm not sure how to test the update installer.

However, I'm not sure how to test the update installer.

You can try if you apply the PR using the patchtester (joom.la/patchtester) and then use the database fixer. Or you can upload the zip from your branch in a 3.6.5 installation using the Joomla Updater. Both ways should apply the update SQL files

The error in the unit tests means you either broke something with you PR or the tests need to be adjusted to your change. It looks like fetching the active menu item is broken.

This pull request is reverting several changes that have been made since 3.6.5, those must be reapplied for this to be considered.

@Napoleon-BlownApart Did you create your PR based on a 3.6.5 installation? If so that would explain what Michael said. You need to create the PR based on a current staging branch.

@Bakual, yes, that was how I developed it. I'll do what you advised which will fix the issue @mbabker mentioned.

@Bakual & @mbabker : I updated my previous comment.

The code was changed in a way to lazy load the parameters. See #13073

You need to get your changes in sync with the current development branch, not the 3.6.5 release. From the looks of things you're trying to port code from two different versions which just won't work efficiently, especially when there have been several other changes (query caching in JMenuSite and that PR I linked above being two changes reverted).

I'm stuck on the update installer because the Joomla 3.4.8

I don't think it works in 3.4.8. The ability to upload a zip directly in the Joomla Updater was added in 3.6.0 or 3.5.0.

@Bakual : Yes, I installed 3.6.0 and now am able to use the udate feature. Unfortunately my update failed, and I will debug it after I fix up the issues @mbabker raised.

@mbabker : I will go through my changes again, from a fresh start, but a little advice would help here.

I would like to start this from a fresh 'staging' state. So what I'm thinking is to delete my branch, create it again, and then proceed to make the changes necessary for the Inheritable again. Is this a feasible approach? I don't want to leave this PR (thread) hanging, and I don't want to be developing a poluted brach that is going to give everyone headaches. If the above isn't feasible, what would you recommend?

Also, since a week has gone by, should I be looking to get a more up to date 'staging' branch?

I have deleted the Inheritable branch and then recreated it. I will reproduce the changes whilst being mindful of the above comments.

I have committed the first stage; Inheritable property managed in the Menu: Edit Item level but it's not showing up here for testing. Travis isn't plaing ball anymore.....

Ok, why am I not able to "Reopen and comment"?

I have updated the Test Instructions (Setup) to include:

    Set "Guest User Group" to Public in Global Configuration -> Users: Options -> User Options.

I have updated the entire Inheritable branch and fixed the issues @mbabker pointed out concerning the caching and callbacks. I don't know how/why but that code was not there when I did my 1st pass. Anyway, @mbabker, your work has now been respected in this version of the pull request.

Locally, I am able to build both the full and update packages and have tested both here.
As stated earlier, I have php5.5.9, php5.6 and php7.0 available to my apache2 install and the code works here for all three php versions.

Now I wish Travis would wake up and run my tests.....

I created a new PR that correctly implements the changes against staging (@mbabker) with a cleaner commit history. It is PR #13817, and it has passed the tests :)