Can someone please add my public key?
Also Berdir and miro_dietiker need their keys to be added for review purposes.
I need the access for localize.7.devdrupal.org (as discussed in #1424984: Port localize.drupal.org to Drupal 7)
These guys are helping with the update of the Localize site to Drupal 7.
We are looking forward to start working on this.
Added you all to devwww.drupal.org with usernames sleu, mirodietiker, and berdir. General information is at https://drupal.org/node/1018084 and I think sebcorbin has been managing localize dev sites.
Thanks drumm. Unfortunately i found out now that localize.7.devdrupal.org is a staging site and i can't access it using ssh sleu@ devwww.drupal.org . Sebcorbin told me that i can access it only using ssh firstname.lastname@example.org but my key isn't added there.
Could you please also add our keys to the staging site?
Or rather than adding it ALSO there, just add them there :)
We can only grant staging access when necessary, since it has personal user data such as email addresses and password hashes. And staging is a canonical copy of what has been checked into Git and BZR. Dev is the best place for development.
I can grant staging access for people who will be working on the site long-term, at the level Gábor and Sebcorbin have.
Ok, we need to figure out yet another solution then to have a site on devwww then.
In order to make the devwww localize environment happen, do we need to file another task?
For now we will continue with fixing remaining issues of l10n_server & friends "offline". However tasks are almost done and we will be stuck soon to help pushing the port.
Deploying dev sites is well-automated. SebCorbin has access to do this, and I can give it to Gábor Hojtsy. Before I deploy a dev site, I'd like to see all the contrib modules updated to their latest versions on localize.7.devdrupal.org, so there is a good place to start from. I'd also like to see snapshot_to_localize.7.devdrupal.org running on a schedule; I went ahead and set it to run daily.
since it has personal user data such as email addresses and password hashes.
Is it really necessary to have this information available on stating sites? How about developing with dummy users and importing the real information later when the site is ready?
And staging is a canonical copy of what has been checked into Git and BZR
I hope here you mean there will be no difference working on staging or dev. First time I read I understood it could contain the user passwords and hashes in the repository =P
If you guys are doing code driven development there is not much reason for having an exactly copy of the database on staging.
Finally we completed all tasks we where able to push.
With a local dev setup and local own produced test data, we have tested and improved l10n_server, potx and l10n_client by rerolling / porting patches and fixing the remaining known issues. Also we tested the software manually a lot.
Many patches are now ready for review and review and committing is up to others from the community and the maintainers. We can't continue here.
Staging access with "real" data - say impersonated - makes sense for what's remaining. For instance testing real user experience with real data and testing the upgrade path with real data.
We also discussed to have a look at the severe performance problem of l.d.o. However, in many cases even staging is not enough for such cases. It can require access to production systems to look into its system measures. We will still try to reproduce and improve some aspects on staging. Again, also tools like new relic might help identify origins of irregularities (in production).
Please notify us once we can continue.
I still want to see contrib modules all updated in BZR by the site maintainers, Gábor or sebcorbin. https://localize.7.devdrupal.org/admin/reports/updates should be all green or have a good reason for un-updated modules.
Gábor updated the modules.
There are 3 newly-created dev sites:
Automatically closed -- issue fixed for 2 weeks with no activity.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.