Posted by christefano on July 31, 2011 at 8:03am
We discussed the ladrupal.org website at the organizers' meetup today and jromine said he'd like to see a code sprint for ladrupal.org at DrupalCamp LA. Who would like to talk about what, if anything, we want to do with the site and get together at the camp to do it?
There are a number of approaches we could take, from performing security upgrades and doing functional testing and fixes to descoping the site's features and relaunching in Drupal 7 — or completely decommissioning the site entirely and focusing on groups.drupal.org/la instead.
Please discuss. As one of the server sysadmins, I'd be happy with simply doing a security audit and updating core and contrib. Of course, I think it would be great if we could do more.
Comments
Still interested in helping
My only cautious thought about it is wanting to make sure I get to hit all the juicy sessions I'd like to. But like I said yesterday, this is an area where I think I can make some genuinely helpful contributions.
My preference would be to
My preference would be to concentrate on our g.d.o presence and only use the LADrupal site as a supplement for situations where the g.d.o site just can't provide a service we need.
Sound fun
Im always up for this sort of thing.
Getting back to this
No code sprint at DCLA, which was fine; there was more than enough to do and see without this.
I want to see this move forward. It's my understanding that the ladrupal.org site is kind of a mess right now due to burnout, lack of attention, whatever. I am volunteering to head up an effort to get it rolling as a useful resource. Here's what I'd like to do:
Get it updated to the latest 6.x core and update the module salad. I don't have access to do any of this right now (I'm sure we can fix that), but it just needs to be done, and I can Just Do It™ once I have access to the site. I'm not sure who I should speak to about the right way to do it (I assume it's all in git, not sure), but with a little coaching on procedures done, I'm sure I can do it. And now that the site has been taken offline, I guess there's no harm done if I manage to screw it up for a little bit. :)
Because I'm a New Guy and haven't spent much time with ladrupal.org, I don't necessarily know what functionality is on there that we'd absolutely want to preserve, but it seems like upgrading to Drupal 7 would be the next logical step. I'm sure there's little on there that we couldn't do in D7, so that would be the next target for me. If I can audit the site and figure out what all is in there, we can maybe throw some unused portions away (keeping/moving them here on g.d.o) to make it easier.
I know there's a swanky new theme ready to be developed -- I've seen a PNG. I do this all the time, so I could do this too, or if someone else wants to jump in, that's fine too.
Once even step #1 is done, but certainly after the step #2 D7 upgrade, we'd have a nice, stable platform to work with moving forward. We can have discussions while the other three steps are going to figure out what we want ladrupal.org to be, especially related to what's already happening on g.d.o. John's told me there's already been some
discussion on this, so that will be good to see.
Thanks, Joe!
Seeing your roadmap here is really great. I love your fresh look at what we currently have and hearing your suggestions for what you'd like to do. Thanks, Joe!
There's been a lot of discussion recently about what kind of functionality is available on the OG subsite we have here and I think knowing what groups.drupal.org can do should be part of what gets planned for ladrupal.org. LA Drupal is active in a lot of places online (I believe they're all listed at http://groups.drupal.org/la/join) and we need to prevent duplication of effort and keep the scope of the ladrupal.org sprints down at every opportunity.
What I'd like to see is our user group using http://groups.drupal.org/la for everything it possibly can. I can help by sharing what can be done and what features are in the pipeline. ladrupal.org should only have the content and features necessary for accomplishing the things we decide are important to build and maintain elsewhere. This is the least time-intensive approach and having less to do (planning, building, maintaining, etc.) will enable us to do more.
That said, if we want to do things that aren't possible on groups.drupal.org, like aggregating Twitter, Flickr, etc. all in one place or having payment processing for membership dues (as jstoller suggested) or donations from sponsors, having a separate site certainly make sense.
Meanwhile, Rain and I put the existing site in maintenance mode at the camp. There are some freaky problems we've known about for a while, but we ran into a new one yesterday... We couldn't enable the Offline maintenance theme, even though the theme was installed, enabled and
$maintenance_themewas set in settings.php. No matter what we tried, Garland kept showing up instead. What I ended up doing was moving Garland to a different location and symlinking Offline to where Garland was, and voila, we have a maintenance theme.Updating the current site to the latest version of Drupal 6 core is easy, but half the contrib modules installed don't have version information in their .info files from Drupal.org's packaging system because someone installed them directly from CVS. (I've asked that person three times if he might get around to resolving this and he's just been too busy.) In light of these issues (and countless others), I propose that we skip Drupal 6 and rebuild the site entirely in Drupal 7.
I think NOT having access is
I think NOT having access is key, and has been generally problematic for most people to get into.
I'd like to see us move everything to a simpler setup that doesn't require specific knowledge of how things are setup. Chirstefano did some great work when he originally set it up, but I know some of us find it cumbersome and difficult due to its unique setup -- and right now he is pretty much the only person to handle situations where something goes wrong or to set something up.
I propose we find a solution where the server is maintained by the hosting company and access for the community is simpler and more like what more beginners would be used to. I'm not sure if softlayer could do that, but I think Media Temple or Web Enabled could do that.
Ultimately, I'd like to see a workflow that makes it easy to share a common workflow using GIT -- including a sanitized DB, and mirror of the files folder (either as part of the same repo -- or a separate one that is "pushbutton easy" to maintain).
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
This is a strange tangent
This is a strange tangent. I don't see how your comment about hosting and how the server is set up is relevant to the ladrupal.org website, which is what this thread is about. I'm not sure why you're proposing to change things when there are volunteers already who are active sysadmins of our server at SoftLayer and you aren't one of them.
Are you saying that you want to be involved in system administration? If so, you can always ask how things are set up. It's a standard Debian server and there's nothing exotic about how the server is set up. The only problems we've had with with access were when people forgot their passwords and changed their public keys.
The only extras running on the server are Dropbox and Virtualmin. Dropbox just runs in the background, as you know, and Virtualmin doesn't interfere with sysadmins editing conf files via the command line (i.e. Virtualmin will respect files that have been modified outside of Virtualmin). It's secure by default so there's no reason to remove it.
Just chiming in as a fellow organizer of other local groups
Just chiming in as a fellow organizer of other local groups without any insight of how LADrupal.org is managed so take with a grain of salt. But, as an advocate of beginners in this field and cultivating them to raise the level of their skillset to keep the local development pool growing, versus those oversea folks, just thought I'd give my two cents. I have had experience with Virtualmin and it is great platform as OCPHP had Joe Cooper, founding developer of Virtualmin/Cloudmin/Webmin present back in March. However, I would have to side with Mike in terms of simplicity versus complexity when it comes to organizational duties and involvement from others. The idea, to me, of a community developed website should have a back-end on auto-pilot where time doesn't have to be wasted on assuring network and mysql security -- afterall, everyone gets busy throughout the year and not good if a select few are pros with this type of management and they are busy to address any needs or allow more access to someone when requested. Yes, this is where something like MediaTemple (gs) or others would be a fantastic option in the terms of going on autopilot. The focus should be on development workflow and functional requirement online docs where if someone is interested in helping, you say, here you go, this is the process of getting your environment working to share with others and welcome aboard with a smile. It is the same idea of why frameworks have coding standards and a process of contributing. I think this will encourage some beginners to be more willing to help if that is the goal or if the goal is only to have only select few ninjas develop for the sake of saying they did so for a promotional tool. A beginner will likely not approach a project if it appears complex to get involved.
Have fun with the site.
Co/Organizer @ Orange County PHP | OC Drupal | Inland Empire Drupal
Everything that should be on autopilot already is
As far as the server being on "autopilot" goes, everything that should be on autopilot already is. Cron is being run. Databases are being backed up every hour. Full site backups are created every night at midnight. Everything is synced to Dropbox. If there's anything else, let's start a new thread and talk about it. This thread is about the ladrupal.org site and not about the server that the Drupal application is running on.
Every sprint that's posted to our community calendar has been open and collaborative. For those who want to work on Drupal or learn more about it, there's room for that. For those who are sysadmins or want to learn more, there's room for that. It's natural that in order to move forward some people want to question how we've done things before or scrap things and start over, but abandoning one hosting sponsor in exchange for another one doesn't make any sense to me.
When it comes to Git and getting everyone access to the code, that's a completely different subject and it's important to distinguish between server access and Git access, which usually takes some time and should be done prior to any sprint. We have gitosis running on our server already, though, and granting access to that is very straightforward. Ron and I have always been glad to explain how this process works, but as far as I know we've never been asked.
So, right now there are sysadmins who have volunteered to do things and help in case things go wrong (myself, rgon and BTMash), and there are several others with root access (partly for redundancy and partly for political reasons) and direct access to SoftLayer support. SoftLayer provides basic support for free and advanced support for just $3 a ticket. SoftLayer has kindly waived those fees in our case.
Thanks for the 411 Christefano
Cool --- Thanks for the 411 Christefano. Sure others may be interested as well in learning the inner workings as you have detailed. Again, was just chiming in without any insight into the development organization and didn't mean to derail anything. As just another organizer out there, the KISS principle has always proved for myself valuable in keeping the gears of my user groups oiled so thought to inject input as I've been to a few LA Drupal meetups. Best of luck with your crew and whatever works for your community out there. I've always been highly impressed overall with the LA community in terms of community participation whether LA Drupal or LA PHP so best of luck to everyone involved. Have fun everyone who participates!
Co/Organizer @ Orange County PHP | OC Drupal | Inland Empire Drupal
Autopilot is not enough. In
Autopilot is not enough. In the event of disaster... we're screwed. When the server goes down... we (the group) would be responsible for debugging the problem as well as resolving it and potentially losing work or data.
As it stands, I believe Christefano is the only person that knows how the entire setup. In the IT world... this is known as a human Single Point of Failure (SPOF) -- and obviously not desirable. I know Ron, BTMash, John, and myself (at least) all have access and could help in the event of system downtime -- but I don't believe any of us know the entire setup well enough to build from scratch in a reasonable amount of time or without Christefano's help -- unless we choose to lose/change setup just to make it work -- but regardless, I don't see it as a good use of our volunteer time.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Mike, calm down
Mike, calm down. In the event of a disaster, the full site backups we have can be used to set up the sites again. These backups are created locally to /root/Dropbox/backups, but in case something goes wrong on the server itself the Dropbox folder is regularly synced to the LA Drupal Dropbox account that you and half a dozen other people have access to. The backups are tar.gz files containing the Drupal installation, server logs, databases, etc., which are standard across all Drupal sites.
We should definitely have an open discussion about single points of failure. I'm glad you brought it up. The ladrupal.org domain name nearly expired this year, for example, and the Meetup.com group organizer "stepped down" because of a billing problem. These things were tended to when they came up and the world didn't end, but having a list of single points of failure and likely single points of failure is a really good idea.
Thanks for replying, but you
Thanks for replying, but you didn't address most the issues I outlined. Plus I'm not asking about the details of who has access to what or where things are located. Doing so is a tangent and also totally overlooks the main point of my post: that it could benefit the community by simplifying.
But look, I'm not trying to attack you or say the setup is bad/wrong/broke. I've just expressed my desire to improve and simplify our workflow -- and pointing out that autopilot isn't actually enough.
To me the benefits are clear. Everyone in the community has the skillset and time to submit a trouble ticket in order to get help when needed. Disaster recovery of our current workflow setup is at best problematic -- and definitely exclusionary (due to knowledge/time/and or skillset).
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Disaster recovery is actually something
Disaster recovery is actually something that I know a lot about and I'm always happy to talk about it.
Huh, okay. I already addressed those issues elsewhere in this discussion. Here's a recap:
1. Autopilot is not enough. In the event of disaster... we're screwed.
The automatic backups are running smoothly (i.e. autopilot). So, we're not screwed.
2. Everyone in the community has the skillset and time to submit a trouble ticket in order to get help when needed.
SoftLayer provides basic support for free and advanced support for $3 a ticket, which they have kindly waived in our case.
3. I know Ron, BTMash, John, and myself (at least) all have access and could help in the event of system downtime -- but I don't believe any of us know the entire setup well enough to build from scratch in a reasonable amount of time or without Christefano's help
There are several sysadmins other than myself who have volunteered to help. The backup files are in tar.gz The backups are tar.gz files containing the Drupal installation, server logs, databases, etc., which are standard across all Drupal sites.
4. Disaster recovery of our current workflow setup is at best problematic -- and definitely exclusionary
What's the basis of this statement? In the case of server downtime (however you define it), anyone with root access or access to the backups in the Dropbox account can get the sites back up and running.
ok, at least second time
ok, at least second time you've said softlayer offers basic and advanced support... but neither time have you directly said if softlayer can handle all of the LA groups maintenance (including backup/recovery) needs?
I've never said we shouldn't host on softlayer. Also, I'd appreciate if we could stay focused on the issues, so again, I'm choosing not to engage in the minutia and point out the obvious holes in our setup. I agree the setup is good... I just started this discussion because I don't feel it works well for us in its current state.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
SoftLayer supports the server
SoftLayer supports the server and all things related to their infrastructure (DNS, security, networking issues, their control panel, etc.). They don't support extras like the Drupal application running the ladrupal.org website or maintenance scripts that are installed by their customers.
We also have a Virtualmin Pro license which gives us sysadmin support at virtualmin.com if things go wrong. I've used that when I've had questions about why something wasn't working and the support at virtualmin.com has been great.
I think at this point this has been asked and answered and I appreciate that you appreciate staying focused. If you ever have specific questions, you can always talk with me on IRC or in person (I'll be at the high performance meetup later today) instead of this thread.
Right on target - too much complexity
That's pretty much the exact problem I've run into. I was unable to figure out the complex hosting configuration for drupalcampla.com, and ended up just copying the entire git repository for 2011.drupalcampla.com. I lost an entire day trying unsuccessfully to get things to work. I was getting ready to just build a new server at UCI to run the site when I finally got something patched together well enough to work.
During the development of ladrupal.org, the code base was put onto git, and a bunch of us pretty much lost an entire day at a code sprint because nothing was working right, and we couldn 't check out the code. That's certainly one of the reasons the project ended up getting sidetracked. The barrier was too high, and people just gave up trying to contribute.
This discussion is absolutely relevant to rebuilding ladrupal.org. We need a setup for ladrupal.org that doesn't rely on specialized knowledge or a single person having the right permissions to do things.
The goal is absolutely to get everyone who wants to help involved, not just a few ninjas. It should be easy to get up to speed with the project, and easy to contribute. I agree with you 100% that too much complexity chases off everyone but a few extremely determined ninjas.
John Romine
Don't blame the airport
It's a huge bummer that this discussion is going this way after we all had a wonderful camp. I wish that I could say that all the infrastructure that's in place from building ladrupal.org before is still in place for rebuilding it and then leave it at that...
I love you for everything you've done and I'm sorry to hear that you lost a day trying to get things to work, but you know as well as I do that the 2011 camp site wasn't launched until 2 weeks before the event because the camp organizers weren't communicating with one another or pretty much anyone in the community.
Please don't blame the server for problems you had with a Drupal multisite installation you inherited and had no help with prior to your epic, one man army code sprint. That's like blaming the airport instead of the airline when your plane is late.
This isn't the case of "a single person having the right permissions to do things", as you put it. There are 9 people who have root access on the server, including you. Now you're making me feel bad for being the person who volunteered at the July 14th code sprint to set up the DNS, database, document root, SSL certificate, etc. for the 2011 camp site. Not fair.
Woa, nellie! ;-) I was just
Woa, nellie! ;-) I was just talking about workflow and suggested moving ladrupal.org to another host might be easier for both workflow and maintenance.
I'm afraid you may have taken it that I was suggesting moving all hosting away from softlayer -- ie., the intranet.lardrupal.org and drupalcampLA sites... but that's not what I said -- and not what I meant. I nearly always favor less work and without a compelling reason to change them (such as people new to the setup) ... I'd leave them alone.
However, IMO this thread is relevant to any work on ladrupal.org. If we're talking about upgrading and making changes, then we must share a common workflow. My suggestion is to simplify our current setup, with in the hope you won't need a guide on the intranet in order to contribute to ladrupal.org.
Plus, having an alternative workflow (possibly host/setup), versus the current ladrupal/DCLA/D4D/Intranet workflow, provides us with a useful metric.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
I don't have a problem with
I don't have a problem with anything you're saying here. It's important, I think, to distinguish between LAMP stack server setup and Drupal coding / development practices. There's an intersection between the two called workflow, but I've tried as hard as I could to make that distinction. This hasn't worked so far, however, so I'll stop beating my drum.
All the problems that I saw happen with the ladrupal.org project centered around coding / development practices. As far as I'm concerned, the server setup we have now is rock solid. The workflow and development practices we used... not so much.
(The one time I remember having trouble with the server was when the Subversion repository got up and quit. We replaced it with Git and, of course, those of us who hadn't used it before had some difficulties. We tried to address that by having a Git with Drupal 7 bootcamp to help bring everyone up to speed.)
RE: An idea about reconciling "best practices" & "low-entry-barr
NOTE: This is in reply to: http://groups.drupal.org/node/165374#comment-559269 -- but felt it belonged on this section of the thread in order to keep ideas about workflow together.
@bangalos - I like the super simple workflow and appreciate you ook the time to outline it. I do however feel there are two compelling reasons to use GIT.
First, I feel projects with multiple people require a version control system and due to drupal using GIT it makes sense to me we would. Secondly, if you are new to GIT, this is actually an opportunity for the group to teach how to use the tool using common (best?) practices. Plus its a repeatable marketable skill that you'd use elsewhere.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
What if the repo were on drupal.org...?
I know you wanted to include the db with it and do other things ... but what if the repo (even if in a sandbox state) was hosted on drupal.org? Users could get assigned to be able to commit on a per-user basis. We could use the issues queue to correct things or take on tasks? It seems like an easier option to add what we need (assuming it is allowed on d.o in the first place) and could be a low entry barrier (and users new to drupal would get used to using the issues queue this way as well).
EDIT: Again, note I am not referring to any sort of best practices (though where would this fall in a best practices case? I imagine something with a very sanitized db would make sense to go through but otherwise??). But I really liked the ideas by Srikanth and think this could be a balance to try and get whoever we can on to using git.
This is a brilliant idea and
This is a brilliant idea and I hope it gains some traction. Using Drupal.org resources like this to develop a website is certainly allowed on Drupal.org so long as the project is an installation profile.
It would need to be a full project and not a sandbox project in order to have an issue queue, though. That shouldn't be a problem for someone like yourself who has a vetted account. :)
Just to clarify, sandboxes do
Just to clarify, sandboxes do have issue queues. Anyone that knows about the repo has the ability to file an issue (since there may be bugs that need to get fixed or features to add to try and make it more viable on its potential path towards a full blown project). What they do not provide is the ability for the maintainer of the project to create releases for download (anyone that wishes to download the project must use git). They also don't show up in search results.
I'm trying to recall what being an installation profile entails, but so long as users have an understanding of what steps to follow (hopefully on the easier side) and how/where to make changes (I would imaging packaging features, any custom modules, themes as a part of this profile?) that this could work. Though I also foresee a higher barrier to entry since users will need to understand the installation profiles, possibly make files, etc. But I might just be overthinking.
Alternatively, if we want a one line clone or a download of the repo, I would think github as being another way we could do this. It does take you out of the Drupal.org infrastructure (which could be a huge negative depending on who you talk to) but the experience of collaborating is quite cool. Anyone that isn't involved as a collaborator in the project still has the ability to fork it out (with one click!), work on some of the issues, and then issue a merge request. Woest and I had moved to work on the signup module port to d7 over onto github where we merged requests with each others for testing. The process was quite easy. And once we had something working well, we issues a nice fat patch so a dev version of signup could finally get released. We also get a download button from the get-go. And it could be a full drupal installation as opposed to just an installation profile. You also get a download link and search results from the get-go. But like I said, it takes you out of the d.o infrastructure which could be very problematic. But then again...ack, off on another tangent.
In both cases, the major plus is that it is REALLY easy to get involved in the project. If you want to be able to commit, provide your public keys to the SERVICE. You can then request for commit access to the project if you want (though both allow you to download the project via git without even registering on the respective sites!). Its easy to add/update/remove your public keys since there is no other management of that portion and you can still go on working on the project without additional work. The maintainers of the project would then just need to grant access to the user and worry about what is being committed as opposed to management of all these other things.
EDIT: I want to add that these are only 2 possible services that we could go with. Rain mentions google code below (also supports git). But the main point would be the low barrier to entry. And if we're trying to be inviting to the community at large to participate, then we'll have to do some things on our end to make sure they can access it and participate in various ways without going through the 'I know a guy who knows a girl who can get us in' because we're trying to be extra cautious. Be it a heavily sanitized db, make files / install profiles, additional files, features, exportables. We have a lot of options.
This is definitely an interesting idea
going this route could have two significant positives (if not many more):
This really emphasizes the community aspect of the project
Those volunteers who have not yet become comfortable with contributing on g.d.o Will have a distinct opportunity, and the encouragement of other LA Drupal members, to become comfortable and become significant contributors in their own right
This concept also returns us to where we were originally the project development, when we had our code on Google code. While not was not a perfect solution, it did create an inviting environment.
Thanks for bringing this idea to the table, it's a creative solution and will hopefully spark other great ideas for ways we can move forward with site configuration as well.
Find my introductory Drupal 8 video course on O'Reilly.com: Learning Drupal 8: Install, Build, Deploy and Maintain a Customized Drupal Website.
I love the idea,,, I really
I love the idea,,, I really want something that is standardized and easy. but my concern is the db &/or files might not be included in the repo at this state. and if they are, how'd they get there (and can it be automated)?
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Options
I have been talking with Mike on irc over the last couple of days about all this and as far as we both see, there are 4 basic options we have going ahead:
Talking things through, option 2 and option 4 seem like the best possible candidates for the project. Using a public repository would mean more exposure to the project and possibly more hands joining on to contribute. Those without explicit commit access would still be able to file issues in the issue queue and, as Rain said, become contributors in their own right. Thus, it would be a lower barrier to entry for those entering the project from a site-building perspective. With option 2 and 4, however, it will also mean that we will need to write out some scripts (which we could include as part of the project) that heavily sanitize the database so contributors can download the db from a link we provide. There will likely need to me some other scripting work done on the server to help out with creating new builds / deployments of the site(s). The possible advantages of a setup with Option 1 / 3 would be that having the public/private repo on the server would lend itself to forcing people to access our server and therefore knowing more about our environment setup -- which may be beneficial to the longevity / passing the torch (Options 2, 4 support this as well but may require more work to ensure it gets to that stage).
In regards to the hourly database
In regards to the hourly database snapshots that are already being created, these are not being sanitized but they can be easily with Virtualmin's "Command to run after backup" feature:
The script to sanitize private data can be based on http://groups.drupal.org/node/102109#comment-331054 or any other sanitizing script that's out there. Also, every feature and setting in the Virtualmin web UI has a command line equivalent with the
virtualmincommand line tool, so bash scripts can contain things like Drush andvirtualmincommands for deploying, syncing and sanitizing data if necessary.Okay, so this wasn't a tangent
Okay, so this wasn't a tangent. Just a misunderstanding. I was surprised by your desire to reinvent the wheel and get a different control panel until you told me on IRC that Virtualmin was too hard to use because it requires SSH tunnels and browser-side proxy configurations.
What you're remembering is the optional way of securely administering the Jabber server (which isn't running anymore due to non-use) so that you could log in via http without leaking your password. Virtualmin is easy to access at https://ladrupal.org:10000 and is secure by default without any additional setup.
Happy to see new life coming into this project
1st, a disclaimer: I'm 3 days into using dictation software for writing, and it is uncomfortable because it is unfamiliar and I am still learning. Please forgive any oddities typos, or robotic tone.
Thank you Joe, for being eager to bring new life into this project. From what I've heard, both Joe and Jeremy have expressed interest in helping to spearhead moving forward.
As one of the original initiators of this project, I would like to add a little bit of history as well as my own opinions of what may work best moving forward.
The project was fun and progressing as long as we were able to THAT everyone was at varying skill levels and learning. If we didn't focus on doing things exactly the best way for the perfect way, we were able to move forward, see progress, and fix things as seemed appropriate.
We had a vision, which changed constantly, and we even got to explore new trends or ideas in building Drupal sites.
As a group we got derailed once we started to be concerned with doing things only according to best practices. The project did become too complex for some, we had a few issues with our hosting configuration, getting peoples public keys, and getting people comfortable with git. Once we got derailed, our energy stalled.
For these reasons, I agree with the idea of going the simplest route possible. Well we have a great tool in softlayer, we also have access to webenabled, where we could quickly set up a new, fresh git repository without all of the complicated history that makes what we currently have hard to access at varying skills. We could also start fresh with the Drupal 7 install, and use the work that we've done historically, as a guide for our goals.
As the originator of the design Joe mentions above, I'd be happy to work on the theming, and to be available to offer reference and support for those who would like to lead this new project.
I hope this is helpful, and look forward to seeing what happens next.
I would be happy to host a Sprint to get us started, but would like to wait until Joe and the Ashok are both available, which sounds like it won't be until early September.
Find my introductory Drupal 8 video course on O'Reilly.com: Learning Drupal 8: Install, Build, Deploy and Maintain a Customized Drupal Website.
Mid-September is perfect
Mid-September is perfect timing for me personally. The rest of this month I'm decompressing after DrupalCamp LA, and trying to get caught up on other projects.
You are right on the money about the project stalling when people got frustrated with the complex setup.
John Romine
'The Ashok' will be available in September ;)
I'm off on vacation from August 18 - 28 (visiting Toronto to look at some clouds). As always, I'm happy to help out in whatever way possible. Most of my recollection in history and opinion is similar to what Rain has described above. I recall folks jumping in and out of the project early on but once we decided things don't have to be perfect from the get-go, development started to ramp up and we were all having some fun. Then we got into the best practice route which made things stall a bit (please note that I'm not saying screw best practices; its always good to try and follow them. But we as a group were a bit lost at that stage) and once we lost the svn repo (the 500 error which remained wholly unresolved), the move over to git seemed like slamming into a concrete wall (personally, I was completely out of my element with git at that time and didn't really know where to start with helping out; me not having my public key on the server also didn't help things when I didn't know how to configure git :/ I'm still not really proficient at it like some of the other folk in LA but atleast I can now get by). I remember not being able to make the sprint after that happened and it seemed like the site stayed in the state it is in now after that point.
I recall trying to help John out with some of the issues happening on the server once the Camp site was ready to go live (and due to my lack of an understanding of virtualmin, I don't think I ended up being any help :(). But now that I've derailed, I'll try and go back to the issue at hand.
I don't know if my opinion on making the call on how the server configuration should be (should it be on webenabled? should be it on the dev cloud? do we keep in at softlayer? what are other alternatives) is really necessary since each of the folk that are an admin on the current server and site have their own ideas on how the environment should be set up (the server setup I have at my workplace is drastically different than the setup for ladrupal. And I imagine John and Mike's setups are completely different from everyone else's). But I do agree with the general sentiment that at the very least exploring the other options that are out there would be a good thing. If not just for learning the strenghts and weaknesses of each.
I also agree that we should start with a Drupal 7 install and rebuild the site. Aside from modules being out of date, there are modules that are simply not maintained anymore (this site was built when feedapi was the king of aggregation!). Depending on what the objective of the site build is (to me, its not just about building the site, but what each and every one of us gets out of it), I'd personally be happy if this was built in D7 for the simple fact that I think it will be a good learning experience for anyone involved. From modules that get used to configuration to hopefully working effectively in a team.
I think I've gone off on a tangent at this point but I hope what I wrote makes sense...
EDIT: I hope 'the Ashok' doesn't end up becoming my name :( I'm quite attached to my current name (real and nick) ^_~
:) i'll try not to call you "the Ashok" again...
I think it was the effect of me trying to say "b.t.m.a.s.h." and giving up after my third effort on the "t" but not realizing that I didn't remove the "the."
Jokes aside, our thread seems to be going in a common direction for next steps, which is awesome:
pick a date in early September for a sprint, which begins with us just talking about what the goals were and making all past materials available to those involved
pick low-barrier-for-entry directions for both server setup, version control and build, and stick with them even if hour choices aren't perfect "perfect"
start building
Joe and Jeremy, do one of you want to throw out possibilities for step 1? Or would you like for me or Benno to do that? We have two strong possibilities for places to host:
Benno's (nice backyard table, grill, good central location with easy access from public transit)
Rain's (nice backyard and space with a large whiteboard, plenty of free and easy access parking, grill, maybe fresh-baked cookies from Rain, and our mascot Pixel)
Find my introductory Drupal 8 video course on O'Reilly.com: Learning Drupal 8: Install, Build, Deploy and Maintain a Customized Drupal Website.
mike or john - pls delete
my novice skill at dictating caused me to post twice, please delete this one? Thank you
Find my introductory Drupal 8 video course on O'Reilly.com: Learning Drupal 8: Install, Build, Deploy and Maintain a Customized Drupal Website.
group admins can't delete
group admins can't delete comments -- and IMO thats a good thing ;-)
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
A suggestion...
It's good to see so much energy & discussion on this topic &, as such, I'd like to provide a suggestion:
How about we have a meetup where all the folks who led certain aspects of the ladrupal.org project explain what they did & how to best move forward?
This way, once the code sprint actually starts all the newbloods know not only what to expect but where they can best help out. This would make it so that the first day of the code sprint is actually productive since folks will, invariably, have to travel out to the meetup, taking time out of their busy schedule. Also, folks could be pointed in the right direction so that they're somewhat prepared beforehand (i.e. pointing to the video link of the GIT event that happened last september, pointing to some videos/resources for themers/front-end engineers, sysadmins, site architects, etc.).
Just some thoughts in hopes of not only making it a successful endeavor, but making it as efficient as possible, as well.
Miguel Hernandez - www.migshouse.com
Founder & CEO - The OpenMindz Group
Writer- Linux Journal & TechZulu
An idea about reconciling "best practices" & "low-entry-barrier"
Consider the following scenario:
You want to help with ladrupal.org site. You go to dev.ladrupal.org. There is a link for "download code and database". You click it, and you get all the code and mysqldump in a zip file. No need for git access etc at this stage. And you know enough drupal to duplicate the setup on your own server. Cool. Now you are ready to help.
You then go to dev.ladrupal.org site again, and see the a list of "nice to have features" for which there is no owner. You decide to work on one of them at your home, and solve it on your computer. You indicate on the site that you are now working on it. When you get it to work on your computer, you are ready to show up at the next "code sprint".
At the code sprint, there are experts who know how ladrupal.org works (all of it). You give a demo to them on how your built one of the "nice to have features". They will give you certain instructions on what they need from you, and work with you to get your contribution in to the dev.ladrupal.org site during the code sprint.
========================================
The workflow could be:
Step 1: "New Contributor" adds contrib modules or builds custom modules and configures the site on his/her local machine.
Step 2: "New Contributor" gives Demo + documents on what he/she did.
Step 3: An "expert" working with "New Contributor" to get the contribution in as a git-diff-patch or a custom module or a feature-export etc.
Step 4: The "expert" works with the "build manager" to add the feature in and make sure that nothing breaks.
========================================
There are at least 3 roles and associated with them are 3 different levels of skill sets:
please read/reply at:
please read/reply at: http://groups.drupal.org/node/165374#comment-559719 (above)
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Thank you
I said a lot of things above, but I want to say in a very direct post that I think your idea and approach are fantastic. What you wrote made me think about D.O / other public repos as a method to be inclusive of the community, and whether we do (or don't) go with that approach, you deserve a lot of credit for it. Thank you :)
Operation Manual suggestion
There is lots of grunt work in putting a Drupal site online, in it's own dedicated server. Lots to be documented. I'm pretty sure most LA members have no idea how or what needs to be documented. I do. So, some of this info is below.
For many projects I write an Operation Manual. It is standard practice in large firms, even medium ones. The freelancer or small web shop seem to forgo an Operation Manual. In fact, most everyone in our LA membership I have mentioned "Operation Manual" have been mystified by what might be in it.
Operation Manual eliminates the "complexity" by listing all involved procedures. It provides a list of where files reside, and what is not 'standard'. And why it's not standard, and if any needed procedures are necessary to handle the standard item.
Operation Manual permits new personnel/members to perform standard operations. What git commands should be used to clone, fetch, check in? What is the git URL? How to get your public key added (a list of people to email the key - and the time frame each can typically add it). How to set up your own dev copy of the site. How to git to/from it. (Yes, these last two items are "simple" - when you've done it before, many times... new members... they need 1 page to read, not the git manual).
How is the site backed up? Where is the back up software (pathname)? The pathname to the config file. How to run a backup. How to run a restore. Some of these can be URLs, better to copy and paste, so the OM is a stand alone manual, and have an URL to where that version of the software's instruction manual was 'last found'. For an example see http://www.vpscoop.org/content/ipmi-raw-notes
The entire manual is stored at an offsite, online web site, in case the computer or net connection is lost. The VPSCoop.com has www.VPSCoop.org where I have written the OM, detailing hardware, replacement hardware, vendors, boot up past issues, boot up current issues, how to troubleshoot boot up failures (when the single root admin, most expert, is unavailable), what web GUIs are available, where the documentation is located for those, what are the most used GUI features, etc. How to restart your OpenVZ slice using the web gui, what web gui features might aid in determining why your slice is not starting up, how to view the syslog entries, etc.
Do visit www.VPSCoop.org and see the menu items I have exposed, but the page content is protected to logged in members. The navbar items ought to give you an idea of what I see our OM would include.
Our OM would not repeat what Drupal is, how a module is used. It would list what modules are used, and for what purposes (user data stored is what?). It's not enough to say it's backed up. It's not enough to have 7 root access users. These users need to know pathnames, software package names, URLs to their manuals, etc. An emergency is not time for guessing. Or searching. Instead, there should be a manual, with Table Of Contents (Drupal Book Navigation).
It would list contacts who can resolve what type of problems, providing an ordered list of contacts and their many contact info (cell, email, home phone, etc) to be tried in an emergency. Stuff that is needed for when only the low man on the totem pole is available, and instead of running around telling everyone the sky is falling, this person can read the Operation Manual, and start the process of fixing.
I suggest we make our OM public, at GDO/la as a Wiki. I'm willing to start it, and maintain it, but contributions are needed, like your desired contact info that would be public... or better we ought to password protect that part (can GDO do that? If not, then I can host that info).
If you install a complex View, then the high level details should be included. If you install something "complex" that Joe Ordinary could not understand in five minutes, then a brief description, along with URLs to existing methodology... If the LAD.org web site grabs things off of GDO/la, then that is complex, and needs a page in the OM. Each module/custom/* would need an OM page. Can the site go live without that module working is a key question to have an answer to. Rather than force a newbie to read all the module code, look at the data, and make that decision, the newbie would start reading the OM and be bootstrapped to the right area to focus on.
John's issue with getting DCLA live again for 2011, should not happen again. An OM would have been key to John having an easy time doing it. Why? Creating the next year's DCLA site would have had a Standard Procedure page that detailed each step to do so.
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
You make some very good
You make some very good points and suggestions. I've heard it many times before and think I repeated it in one of the presentations "I write things down if there are too many steps, and one step is too many". Having a wiki / book of everything that we have running on the server and how things are set up / how to set things up (I don't know if it needs to go into the why x module is set up but knowing what is there, where it gets configured ... clear instructions, most definitely) will be crucial regardless of where / how the site gets hosted. It will also mean anyone entering at a later state can be told to 'look at X' which they can follow along to hopefully get up to speed at a faster rate than being tutored down the line at each subsequent sprint / meetup.
Operation Manual as Book better than Wiki
A manual has pages, while a Wiki does not. Drupal Book has a module that supplies a menu for page navigation, and Books can be printed by chapter or whole, with just a few mouse clicks.
Why print it? At a code sprint having 3-4 copies of it available, would let newbies get bootstrapped, without an expert hovering next to them.
For that reason alone, I would expect experts would want a decent manual. Experts could focus on doing tough things, not training newbies.
Newbies could take the copy home with them. This would motivate them to do more on LADrupal.org.
A manual ... would be a guide to run a Drupal site. Not just LADrupal.org. And set it up. And create a dev environment. Do staging. And troubleshoot it. All in one place. It could become an O'Reilly book. After I finish my D7 Module Cheat Sheet, I'll finish this Drupal Guide Book.
I'll create a Table Of Contents strawman, in Drupal, at d7guide.peterbenjamin.com, over the next 2-4 weeks, just for LADrupal.org code sprints (It's initial focus will be getting newbies on board). I'll make it public when it's got all the placeholder book chapters and pages in place. It will need a "character count" in the menus, next to each link, telling if the chapter or page is "empty", pending additions, or has reading material. It would be nice to have an option so empty pages do not print. I like penciling in details, and typing them in later.
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Is there still any interest
Is there still any interest in this? Ashok's idea of starting up an ladrupal.org project on Drupal.org infrastructure has a big +1 from me and makes sense to me as the next step.
I noticed in my calendar that the SSL certificate for ladrupal.org will be expiring tomorrow. I can renew it later on if / when we come back around to this and we still want to send all authenticated traffic over https.
I'm still up for this if that
I'm still up for this if that counts for anything :) Heck...if we decide to go forward with the LA patches pool to work on, this would be something good to add in there ^_~
Still kicking
I'm also still up for it too, just got a bit buried. If no one beats me to it, I'll see about proposing a sprint to get started.
sounds good... I'm still game
sounds good... I'm still game too
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Come discuss LADRUPAL.ORG at the next general LA Drupal meetup
I will add this to the official agenda for our April 10th LA DRUPAL meetup, taking place at the Santa Monica Public Library from 6pm-9pm. For those available to meet up in the first hour (6pm-7pm) to hear the LADRUPAL.ORG web site needs and how we'll be moving forward, please come join us.
I will be leading that discussion and overseeing the site roadmaps & volunteers, to help assure we stay on target. And for educational purposes, we will run public SCRUMS (dates & frequency TBD), so those who are new to Agile Development practices can get exposed to the process through this project. Scrum meetings are short, usually under 15-20 minutes, so volunteers should expect the impact of participating to be low. (We know you have work to do too ;) )
Note: While we may not knock out all the necessary details of moving forward, but we can get started with an official wiki/thread to mark what the goals and work is needed, for an easy plan that focuses on what would be done in the next month or two, and then what will be needed across the next 3-6 months. That would get it back on the rails and take care of 2012 and get us more than situated for early 2013.
Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant
I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us
ladrupal.org back on track
This sounds like a good plan. The work on 2012.drupalcampla.org has been moving quickly, I think in part due to using a wiki and a project/ticket tracker. This has also allowed interested people to help easily by creating tasks, working on tasks, and providing input. Using #dcla-planning in IRC has also been particularly helpful in answering quick questions and helping people find tasks to work on.
John Romine
ladrupal.org back on track
I'll be glad to see LADrupal.org go live again. It can do things for us that GDO can not. At a minimum, drive traffic to GDO/la
Can we get the ticket system working before the meeting, so a list of desired features and migrations can be discussed? Yes, I'm jump starting, again. ;-)
Project tracking has been a great boon for DCLA 2012. Several volunteers have entered dozens of tickets, replies to about 25% of the tickets changed their status, reducing the workload, as more minds chipped in. We have it sort of easy, in that 2011 DCLA is being 'migrated.' So, needed functionality is pre-defined, to a high degree.
GDO supplies many Drupal User Groups with a free website at a path within GDO, that comes packed with functionality. I recall LADrupal.org design discussions years ago, where the below was mentioned.
1) Duplicating GDO features would split, and possibly devalue both resources.
2) Events should be on both sites, but GDO did not play well back then. Does it now?
I mention these now so we can think it over before the next meeting. I'll add a half dozen tickets for keeping existing functionality already on the site, while GDO data needs to be fed into it, and massaged, which needs tickets as well. The discussion can then review these tickets.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
that is a great idea
that is a great idea Jromie.
We should host the git repo over at bitbucket (or equivalent) and set it up with a public wiki and issue tracker. we can run it just like a project on d.o and have any one who is able submit a patch.
We should use drupal.org infrastructure
If we're going to be providing it as a distro to the community at large, we should just start off over here. Easier to get folks involved, easier to see patches, people can fork off their own sandbox if they want, send set sof commits to pull in, etc. etc. Plus people get to see how we're working on it.
We still have to figure out our server issues but getting a sanitized download of the db should be easy peasy given what we are doing for the camp site.
ya, I like. plus its another
ya, I like. plus its another common workflow and set of tools.
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
Sorry, didn't realize that
Sorry, didn't realize that this was going to be contributed back.
As an fyi, I think we should
As an fyi, I think we should pay close attention to http://drupal.org/project/learn. We can read more on it at http://drupalize.me/blog/201203/plan-helping-new-drupal-contributors