Posted by mikey_p on January 13, 2011 at 8:41pm
7 followers
| Project: | Drupal.org customizations |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | mikey_p |
| Status: | closed (fixed) |
| Issue tags: | git phase 2 leftovers, git phase 3 |
Issue Summary
This is postponed waiting on #1026098: Create new mailing list for project applications.
This is a followup to #1023760: Remove druaplorg* dependencies on cvs.module
Comments
#1
Should also expand this to include functionality for pushing new applications to the mailing list, if we even want this functionality.
#2
#3
#1026098: Create new mailing list for project applications is closed in favor of not creating a mailing list to duplicate the functionality of issue queue subscriptions. I think we can go head with removing the CVS applications and commits lists from the drupalorg module.
#4
#5
duh, can't redirect output of git format-patch
#6
I mostly skimmed, but I noticed this:
+ dsm($account);Otherwise, seems good to me. Making drupalorg smaller++ ;)
Thanks,
-Derek
#7
Oh, and:
+function lists_update_6001(&$sandbox) {+ db_query("UPDATE {system} SET weight = 15 WHERE name = 'lists'");
+}
A) Could probably use a code comment why weight 15 (i.e. we need to be heavier than drupalorg_git_gateway or something, right?)
B) Why pass in $sandbox by reference if we're not using it at all?
Cheers,
-Derek
#8
Fixed #6 & #7.
#9
I should add that we'll also need to think about how to best re-sync the lists with d.o users since we are now just checking for users that have agreed to the git terms, which will be far more than the number of users who have a 'git vetted account' (new term for previous CVS account holders). If it is possible to remove all the users in mailman, or if it handles dupes properly, I could come up with a small drush comand that would allow re-syncing users from d.o to mailman.
#10
Query to provide list of users to be subscribed to the maintainers mailing list:
SELECT mail FROM users u INNER JOIN users_roles ur ON u.uid = ur.uid WHERE ur.rid = 20;This should not be synced up until this patch is deployed on d.o.
New patch removes a small whitespace change that was unnecessary.
#11
Marked #1075684: "My newsletters" tab automaticly unsubscribes from "Maintainers news" a duplicate of this.
#12
Looks good.
#13
Committed.
#14
re: #10, there's a subtle distinction here - having rid 20 != having consented to the ToS. if {users}.git_consent = 1, then we know they've consented to the ToS. However, if someone's git account (or d.o account) has been disabled/blocked, then they lose rid 20 automagically.
I have no idea which is right for this case, but I just want to make sure a conscious decision is being made to include the right group of users with this. Moreover, I should note (for example) that eaton only clicked his consent box a few days ago. Which means that up until a few days ago, he wouldn't have been on this list. Should we also include vetted users in this? I dunno, I'm just wanting to get the info out there :)
#15
The logic should probably be (git user || git vetted user). I forgot about slackers like eaton. ;)
#16
Committed the attached patch.
#17
List of mails to be subscribed:
SELECT mail FROM users u INNER JOIN users_roles ur ON u.uid = ur.uid WHERE ur.rid IN (20, 24);#18
Deployed.
#19
Ok, subscribed people to ML.
#20
Automatically closed -- issue fixed for 2 weeks with no activity.