I'm not in favor of merging expectedFailure tests: * It adds the overhead of time running tests that we know aren't expected to work. * It's more code to maintain (might go stale in the meantime anyway). * An issue might be obsoleted (via deprecation, etc.) at some point. * When viewing commit history, it seems clearer to add tests when fixing an issue rather than removing a decorator on a test (the contents of the test won't be easily viewable in the latter case).
We currently have < 10 tests marked as such in the test suite now. I'd like to audit them to check their state. Here's a ticket if anyone wants to help with that: https://code.djangoproject.com/ticket/23943 On Monday, December 1, 2014 12:18:31 PM UTC-5, Carl Meyer wrote: > > On 11/30/2014 05:54 AM, tomv wrote: > > It's important to note that right now, index names are not re-creatable > in > > retrospect. They rely on the names of models and fields, that are free > to > > be renamed. So a complete rethink will be needed if introspection can no > > longer be used for user-specified types of indexes. For example, maybe > the > > user should choose the name, which they should make unique at the app > > level? Or if not, Django will need to either keep a record of the > generated > > index name somewhere, or start renaming indexes to keep them up-to-date > > with the components in their names. > > I think one way or another with the indexes DEP we will need to surface > the name of an index as an explicit part of its deconstructed > specification (just like with fields, models, etc). This implies > probably letting the user pick an explicit name if they want. We could > also keep the option of using an autogenerated default name, but in that > case migrations should notice if that autogenerated name changes and > generate an index-name-change operation. > > > What's the best way to proceed with the index name collision ticket > #23577 > > <https://code.djangoproject.com/ticket/23577> at this point then? I > can: > > > > 1. re-write my "use migration names in index names" branch > > < > https://github.com/tomviner/django/compare/ticket_23577_with_poc_migration_name_fix> > > > > to allow index suffix names passed from migration operations? > > What about having the entire index name explicitly passed from the > operation in migrations (even if for now its always autogenerated > there)? That seems like maybe a step towards where I think we'll > eventually need to be. (But take with a grain of salt, you've been in > this code and I haven't). > > > 2. or declare there's no consensus on the solution / we'll wait for > > Mark's index DEP - in which case, can I submit my tests > > <https://github.com/tomviner/django/compare/ticket_23577_with_tests> > as > > xfails? > > Hmm, that's an interesting idea. It's not something we've generally done > in the past, but it might be better than just letting the tests bit-rot > as an un-merged PR, later probably needing to be rebased. I'm curious > what others think of the idea of actually merging xfail tests for > unfixed bugs? > > Carl > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/12d091f9-1a8c-4086-b5d8-ffffb2eb004e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
