Move email and number field types to \Drupal\Core\Field, remove modules

+++ b/core/modules/field/lib/Drupal/field/Tests/EmailFieldTest.php
@@ -2,12 +2,11 @@
-namespace Drupal\email\Tests;
+namespace Drupal\field\Tests;

Can we move the field type specific tests into field type specific subdirectories?

cf. #2202925: Move simple field types into Core/Field

Not sure about Fields as a sub-namespace, everything in fields.module is about fields?

FieldTypes maybe, but I agree with @sun that \Drupal\field\Tests\Email or so would make more sense.

The separation into field type specific test subdirectories (for the moved files only) should be done directly in this patch, IMHO.

I actually spent a lot of time to think through and try out possible constellations in #2202925: Move simple field types into Core/Field, and it actually was @yched who raised the concern that all of those tests would/could end up in a single directory (dumping ground), which would be a regression compared to the cleanly separated tests we have right now.

Let's move those tests into corresponding \Tests\Email and \Tests\Number subdirectories/namespaces, please. There's really no reason to hold that up on any possibly preexisting Field module test classes (and also no need to touch any preexisting files, as that would be out of scope here).

number already exists in 7.x, no idea what it is doing in https://drupal.org/node/2164623? should be removed from that. However, it should be added to https://drupal.org/node/2116417.

I don't think this needs separate change notice.

Clarifying the title a bit, we don't move the modules to Drupal\Core\Field but the field types and their widgets/formatters.

I think this is RTBC, pending an approval from a core committer.

Thanks — this patch looks great to me!

While number totally makes sense to move to core as a "native" field type, I was a bit confused why we did that for email, which seems more optional. But andypost pointed out that "core" core entities like User use it, and would ideally not be requiring an optional core module to do so. It's also a native HTML5 field type now, so that's probably another reason.

Looks like #9 enumerates all the places that need to be updated for this.

Committed and pushed to 8.x. Thanks!

We still need to remove the drupal.org issue queue "components" — they were introduced during the D8 cycle:

https://drupal.org/project/issues/drupal?component=email.module
https://drupal.org/project/issues/drupal?component=number.module

email.module is empty, great. number.module is not.

What do we do?

I really liked the clean separation of issues to get filed against discrete field types, and I think I'd really dislike to go back to a never-ending dumping ground of "field system"... — a new and smaller dumping ground of "field types" might work, although searching for issues against a particular field type will be cumbersome, since the field type names are very generic keywords (i.e., searching for "number", even when filtered to a "field types" component, will yield many false-positive results).

I really liked the clean separation of issues to get filed against discrete field types, and I think I'd really dislike to go back to a never-ending dumping ground of "field system"

Very much +1.
Also true in terms of maintainers, being a "Field API" maintainer doesn't mean I sign up to maintain all field types / widgets / formatters in Core/Field :-)

The fact that "a field type / a collection of related field types" is now scattered betwen "FieldType folder containing lots of other field types + a FieldFormatter folder containing lots of other formatters + a FieldWidget folder containing etc..." doesn't help with clarifying responsibilities, but maybe a set of separate "number fields", "text fields" ... components would be needed nonetheless.

I removed email.module, since that was introduced in D8. number.module was in D7 though, so we might as well keep it around for issue organization purposes in D8 until we find a better way.