As #1310130: Put drush make in drush core is moving along we should let users know.

I guess the most relevant issues should be moved to the drush queue.
Others could get a 'closed (won't fix)' with an explanation and an invitation to move the issue if someone is still interested.

Text suggestion:

Drush make is moving into drush core (#1310130: Put drush make in drush core)

This means that the issue queue is also moving.
We would like to take this opportunity to leave behind obsolete issues, allowing us to focus on a stable make command in core.

If you feel that this issue is still relevant after the move, feel free to move it.
The drush queue has a component 'Make' especially for drush_make.

Comments

helmo’s picture

helmo CreditAttribution: helmo commented

I'm preparing a Dreditor stock response for this.
And volunteer to go through all issues.

To avoid confusion this should be done after #1355604: Update project page about moving into drush core is done.

The template page is: http://drupal.org/node/1364928
It's parent book page has more details (http://drupal.org/node/1120672)

Please note that this dreditor feature is still under development in a sandbox: http://drupal.org/sandbox/clemenstolboom/1125712

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

#1355604: Update project page about moving into drush core is now done, and the 'make' branch is now merged into drush core. ;)

So, I think we're ready for this to move forward.

HOWEVER, some of the issues in the drush_make queue should move to http://drupal.org/project/drupalorg_drush not to drush itself. Basically anything about the d.o-specific validation. Namely, the Drupal.org integration component in this issue queue. So, maybe start by moving those first, and then move the rest to drush in the 'Make' component? Although, crap, there are also d.o-specific issues like #684788: Verify Library URLs against a White-list for drupal-org.make which aren't yet in the right component. Anyway, point being, this requires a bit of care and can't be fully automated.

Thanks!
-Derek

helmo’s picture

helmo CreditAttribution: helmo commented

Thanks, I'll look out for those drupalorg issues.

@dww: Could you add a 'Make' component in the drush_make project? I think that would save an update for every issue I move. As it is I would first have to move the issue to the drush queue and then change the component.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Once you change the project all the project-specific options (component, version, assigned, etc) should be available. I don't know what you mean about needing two updates, nor how having another component in the drush_make queue will help.

Thanks again for working on this!
-Derek

helmo’s picture

helmo CreditAttribution: helmo commented

It's a dreditor specific problem :(
When I use the stock response macro the form fields are updated, but not re-populated.

I've reported it as: #1367692: Reload component select box on project change
I hope the extra component works as a quick fix.

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

I did

  1. Click on Project
  2. Backspace Make from 'Drush Make'
  3. shift-tab to Issue title
  4. tab to Project
  5. tab to Version

So my guess this is not a dreditor specific issue.
Cleanup issue queue | drupal.org_.png

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

[ Powered by #1115636: Issue Macros and Templates - _default]

This is similar to #463994: ERROR: "Unable to find project" ?

helmo’s picture

helmo CreditAttribution: helmo commented

The spinner shows first between 2 and 3 and then between 4 and 5. Only the second ajax call shows the error,

@clemens.tolboom: I think that #463994: ERROR: "Unable to find project" is different.

@dww:The quickest fix is still to add the 'Make' component.

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

Doing a firebug net the second spinner result in a request to http://drupal.org/project/issues/update_project
with post data

category	task
comment	
files[upload]	
form_build_id	form-xxxxxxxxxxx
form_id	comment_form
form_token	xxxxxxxx
format	1
priority	2
project_info[assigned]	0
project_info[component]	0
project_info[project_titl...	Drush
project_info[rid]	0                <==== guess this is project version which is a required field.
sid	1
taxonomy[tags][9]	
title	Cleanup issue queue

resulting in the mentioned error.

[edit] grepping D6

grep -r "An illegal choice" *
includes/form.inc:              form_error($elements, $t('An illegal choice has been detected. Please contact the site administrator.'));
includes/form.inc:          form_error($elements, $t('An illegal choice has been detected. Please contact the site administrator.'));
modules/filter/filter.module:  form_error($form, t('An illegal choice has been detected. Please contact the site administrator.'));
clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

Edit: irrelevant: Maybe this #185851: Changing project in an issue with JS is broken is about the problem?

Do we agree the problem is not dreditor related?

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

I can 'fix the error' by selecting values from the checkboxes ...
My guess now is form API is wrong in reporting an illegal choice as these are only required fields.

Comment #1 from Eaton #351413: Editing migrated content results in "An illegal choice has been detected." helps a little explaining.

Both Version and Component are changed the option set. Just tested the same steps on a Drupal Core issue. It fails on the component ... weird.

http://drupal.org/project/issues/drupal?text=illegal+choice&status=All&v... lead me to #335179: unnecessary error reported for options validations which I bumped.

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

To conclude the bug reported between #2 and #11 is:

Changing the project name results in new values for at least version, component and more fields.
When unfocus / focus / unfocus the project field produces the errors.

Issue #335179: unnecessary error reported for options validations reports an illegal choice which is wrong. The fields are only required.

@helmo was wrong in #5 about dreditor-triage but @helmo helped improving http://drupal.org/sandbox/clemenstolboom/1125712 to at least #1367692: Reload component select box on project change

helmo’s picture

helmo CreditAttribution: helmo commented

@clemens.tolboom: thank, the two-step macro works good enough for this task.

@dww: With this fixed the extra component is no longer needed.

I've now done a few issues, I hope to work through them during the coming days.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Great, glad to hear it.

If there are specific bugs in project_issue causing these problems, by all means, let me know. However, I haven't seen anything show up in the queue yet, so I'm assuming these aren't "my problems". ;)

Thanks,
-Derek

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

@dww: I'm not sure whether project_issue is resetting the select elements wrong after the ajax call or drupal core. A quick peek @ #335179: unnecessary error reported for options validations is appreciated.

I also created an issue for dreditor-triage to make the setters better #1370632: Can we queue issue state change command instead of all at once when having ajax fields?

helmo’s picture

helmo CreditAttribution: helmo commented
Status: Active » Fixed

Yeah.... after submitting this form all 'open' issues in the drush_make queue are marked as fixed :)

For the statistics:
The drush_make project had 103 open issues.
The Make component of Drush now has 52 open issues.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

Excellent, thanks so much helmo! This is a HUGE help.

Cheers,
-Derek

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

[ Powered by #1115636: Issue Macros and Templates - _default]

Thanks for reporting, reviewing, and testing!

Was the Issue Macro and Templates dreditor patch useful?

helmo’s picture

helmo CreditAttribution: helmo commented

Yes it saved some time.
It also let me concentrate on the issue content, trusting that I would get the correct component and version in one click.

Blindly going through them would would obviously been way faster, but I could not resist to at least scan though each issue.

Status: Fixed » Closed (fixed)

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