Sorry, I'm replying from the cumbersome gmail interface than my regular thunderbird one, so the formatting and headers might be off.
>PK wrote: > What exactly is the workflow you have in mind for how the static website > is going to be updated? Whether you use an SCM or not you are going to > have a person who finally takes a call on a "release" to the production > server. > This can be four or five people. Why just one? > Consider the steps required for a SCM repository idea to work: > > Naturally, I am assuming that you are not providing commit privileges to > everyone. Anybody who *asks*. By default it's read-only. > (NOTE: I know we are speaking of techies here, but really - how many of > even these techies will know how to send patches properly and will be > diligent enough to include any additional files and so on?) It's no difficult than contributing to any open source project. I'm assuming a lot of people are already quite familiar with the steps mentioned. If the students are unfamiliar, it will be a good starting point for them to start contributing. We'll explain the process in clear steps on the site. > > Webmaster: > > Step 5 - Webmaster receives the patch and determine if the patch can be > applied to the code. > Step 6 - He will need to actually apply the patch to determine if it is > breaking anything. Since stylesheets may have changed, he will need to > review a lot of files. It's not as difficult as it sounds - at the end of the day, installing a local version of apache is not hard, and they only need to have a browser to check the changed html files. Even if something breaks, I'm sure somebody will notice it and commit a new patch pronto. > > Consider the steps given above. One poor soul will be entrusted with the > task of doing this - there is a lot of possibility of error. Perhaps initially. But I expect this to get much faster once everybody gets a hang of it. I repeat, these steps are not something most of us are unfamiliar with. I expect people who are going to sign up as project moderators will know what they're getting into. > > What exactly is so difficult about these "themes" and "modules"? There are > kids who are setting up their own websites using these CMSs - a theme is > mostly html with some additional markup and some css. > They need to be upgraded whenever a new vulnerability is found. It means that whoever has admin access to the server has to be available immediately. And php apps are notoriously bug-prone, there is a new bugfix release every week or so. Who wants to go through this rigmarole every week? (fwiw, I have a wordpress install, and I hate upgrading it every month) > Have you tried putting in a large binary file into subversion? consider > something like 20 video files of 50 mb each. Try checking them out of > subversion. Just consider that the users who want to modify html files and > send it to the webmaster will need to checkout these files on their > desktops over a pathetic 1mbps DSL connection. There will be *no* binary files on the site. The videos go to YouTube or other video sites, so we'll only embed them. Except for logos and other small icon files, I expect things like photo albums etc should be stored in services like Picasa or Flickr. > > Consider the workflow for a CMS driven site: I understand and agree with your steps involved in maintaining a CMS-driven one. The biggest problem with the CMS approach is, *it did not work so far*. All this could have been done already, but nobody bothered. Which is why we're requesting a change in the ways of doing this. We need not depend on the commitment of one person. There can be hundreds of people pushing edits, whoever is motivated, and at least one of the 5-10 people who have deploy access can be available to push the change. The guy who has access to the server needs to be available only if something really bad happens. Finally, I'm not saying this will be perfect - but it's a good deal better than what we have so far, and it never hurts to try something different. If it's all that cumbersome to do so, I expect people will pipe up, and we'll make necessary changes along the way. Vamsee. _______________________________________________ To unsubscribe, email [email protected] with "unsubscribe <password> <address>" in the subject or body of the message. http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
