Trying to use devel_generate to randomly generate project nodes on a D7 test site results in invalid projects which have no machine_name set. I believe it's just because there's no machine_name.devel_generate.inc that tells devel_generate how to populate random value for this field. I'm working on a fix (since this would be useful for D7 Project* porting). Stay tuned.

CommentFileSizeAuthor
#3 1952404-1.machine_name_devel_generate.patch1012 bytesdww

Comments

dww’s picture

Status: Active » Needs review

This works fine in my local testing. Any objections to me committing this to both 7.x-1.x and 7.x-2.x branches?

BTW, why do we already have a 2.x branch? ;)

Thanks!
-Derek

greggles’s picture

Seems like you forgot to attach the patch?

dww’s picture

StatusFileSize
new1012 bytes

indeed. ;)

c-logemann’s picture

Assigned: dww » Unassigned
Status: Needs review » Fixed

@dww: Thanx for the devel generate patch. It works fine.
Commited in 7.x-2.x branch: http://drupalcode.org/project/machine_name.git/commit/b626401

BTW, why do we already have a 2.x branch? ;)

The 7.x-2.x branch is for new features:
#1647904: Machine Name needs a 1.0 stable release as part of the Drupal.org D7 Upgrade Initiative

dww’s picture

Assigned: Unassigned » c-logemann
Status: Fixed » Needs review

Wow, I hadn't seen all that. I think #1647904-10: Machine Name needs a 1.0 stable release as part of the Drupal.org D7 Upgrade Initiative was mistaken in arguing for a new branch. Yes, d.o wants to use this module, but that doesn't mean it needs to be locked into a prison. ;) We ask for being careful and responsible as a maintainer, and if you were planning a major refactoring, we'd definitely request/argue for a new branch, but until that's actually happening, I think extra branches are generally more work and should therefore be avoided until actually needed.

For example, it's inconceivable this will break anything, so there's no reason not to have this in the 7.x-1.x branch, too. Furthermore, I just did a trial git merge in a local clone, and IMHO every commit in 7.x-2.x since it was created also belongs in the 7.x-1.x branch. d.o wants bug fixes, too. ;) The Search API "feature" #1832328: Expose Entity Metadata property (for Search API, etc.) was also added with d.o in mind: #949372: Port issue views to Search API so we can have a performant backend so we're going to want that in 7.x-1.x, too.

At this point, I'd suggest the following:

  1. git merge 7.x-2.x into 7.x-1.x
  2. make 7.x-1.x the default branch and continue all work there for now
  3. mark 7.x-2.x unsupported at this point, and don't use it until we have a good reason to
  4. edit the 7.x-2.x-dev release node to make it clear people should use 7.x-1.x-dev instead

We can still leave the 7.x-2.x-dev release node published (and corresponding version choice in the issue queue) so that we can use it when needed in discussing where various issues belong. But, until there's a real need for another branch, let's keep things simple.

Thoughts? I'm happy to take care of any/all of the tasks on that list. Just let me know.

Thanks,
-Derek

dww’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
c-logemann’s picture

Assigned: c-logemann » dww

@dww: You are still a Co-Maintainer of this module and I think you are a more experienced maintainer than me. Your help is very welcome!
Especially if you want to help to maintain the 7.x-1.x-Branch with d.o in mind it's OK for me to merge both branches again.
I am very busy at moment in several customer projects. So if you like to do the work on your comment #5-list by yourself feel free to do.

dww’s picture

Status: Needs review » Fixed

Great, thanks. I didn't want to act unilaterally, but I'm happy to help if you agree. :)

I just moved this into a separate task since it's a little weird to have this happening in this issue:
#1971726: Merge 7.x-2.x branch back into 7.x-1.x and (for now) abandon 7.x-2.x

Thanks,
-Derek

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.