cvs Haiku
Yet again my lack of cvs skills failed me miserably & I had to go back and try tag files in a folder so it got released with the last version of my "html nerdy" theme mothership ( it isnt a folder or how it is in cvs?...) well I came to reflect a bit over this cvs thing
I for one have a very passionate relationship with CVS that i had to write a Haiku:
CVS errors taunts me
No escaping this commit
How will I release now?
It have taken me at least 2 (TWO!) pain full years to get into. I really wanna help out in the drupal community and make it prettier, so I have put myself into the pain of learning cvs. yes i know eater im very dumb or very stubborn...
As a "more of a designer than a developer" its a really hard to dive into this lovely CVS thing- one thing is that we dont have really good gui's (No a terminal is NOT a gui!)
So the amount of time and frustration, and not to forget fear of thrashing own code, have more than once put a stop to my willingness to work on a design & theme that could be commited
Stop whining - learn to code like (wo)man!
In DCDC (drupalcon dc 2009) we had this discussion it was at the first "Drupal-themers-social-meetup" ever. I mean EVER as a teenage girl would say it: eeeeveeer as if!
Off course at the meetup were others than us artsy fartsy whining boys and girls who like pretty colors and feely usability stuff. Hardcore terminal loving badass developer types (ooh the horror) had joined the party -yup they figured out where the good preparty was that night.
So it went back a forth a bit between the 2 opposite sites with with the usual arguments:
- "...we need to have out code into some kind of version control" .
- "...cvs is just some commands"
- "...but i dont wanna understand cvs"
- "...well nodby likes it just need to accept it"
- "...we need more beer ... and margaritas"
Till it Finally it went down to:
(its not the exact words but added a bit of color for the dramatic effect - hey you didn't believe your reading the gods honest truth did you?)
"Hey get a grip cvs is a tool that you just have to learn whats the big deal, you guys figured out html/css/php whats the problem - just use it and stop the whining"
Offcourse this was countered by the local heros (the frontend themers if you had any doubt!):
"To use CVS is to a frontend designer the same as having a developer to design a website so it looks and feels spanky sexy & hot"
Aha Its a totally different skill set we try to force on the frontend developers to use, that is not a part of his "natural language".
okay Lets turn the table
Okay So if your a "version control terminal loving dev." who still dont se my point - look at it this way:
Every time you had to commit youre code to drupal you had to:
- Put it into small nice boxes in the "colors of the season"
or by the feeling of "strawberry fields" (what ever the art director feels he likes at this moment ;) - The boxes follows a "natural" flow- Is combined with each other to give it a good "organich" feel.
- It gives you a human feeling but not to soft - just right is what were looking for.
- You texts leading in the heading is correct.
- the text needs enough "air"
Then and if the Art Director "feels" like you did it right - then your code can come into Drupal.
What im trying to get at here is that were trying to force frontend geeks to use a tool that is not a part of their skill set, actually not even part of their language (and we know that at least 25% of the developers hate cvs even more) how on earth did we expect frontend people to ever wanna learn this? By saying: Hey if you wanna be a part of out community, then you have learn cvs - get an account (if you can get one) else we dont wanna play with you. How many designers do we really think that wanna join in and fight with CVS - just so they can add a new look to Drupal ?
If you want the dead honest answer look into out theme repository and count the one you would like to use! - The hard cold reality is that we have a hard time actually finding decent themes that can go into the Drupal7 distribution! Should we try to compare outself to other CMS systems?
Does it even matter?
This wouldn't be a problem - if we didn't cared about how drupal looked out of the box, or just ignored it and went with the "well all Drupal projects is so big that they will always have a custom theme, so that cant be generic", or just accepted that Garland gets the job done.
If we think that Drupal should look as diverse and fantastic as it is on the inside then we need to do something else that we are doing today. It should be clear to everyone that were not getting asskicking wonderful designed themes into the Drupal repository as long as the designer/themer/frontender have to get an developer involved to hold his hand to get him safely over the road - so big bad cvs dont hurt him.
CVS or die?
I know that its not only themers that are crying and whining about cvs, but at least its a part of a language that a developer talks ...
I was asked to look at this http://drupal.org/node/289117 before i ranted to much...
- Goddammit always a dev who tries to add nuances to the debate... damn and they even try to play nice ;)
I guess I can take from that, that im not the only one frustrated, and we share the same vision - ooh and offcourse its okay to take the piss on each other in the community :)
Alternatives
Simple committer
http://drupal.org/project/simple_committer
The initial goal of this module is to simplify the process of committing a theme to Drupal's CVS. For a HTML/CSSer, CVS is too much of a barrier for contributing new projects, and we would like to lower that barrier as much as possible.
Themes in SVN
Would it be so hard to just give the themers acces to svn (pretty please)
Why oooh why ... well theres some pretty amazing guis out there. My person favorite Versions
especially with the beanstal svn setup - im actually not that frustrated, by using a version control system so far it "feels" right.
GIT
well personally i dont even understand that whole distributed repository thing, and even tools like gitX dont yet removes the the need for the terminal to do push, pull, submodule update etc
Better CVS training
If we insist on using CVS for everything we need to step up the education of the themers.
So every camp, con, meetup, whatever gathering theres is should have a class/session in cvs for themers - yup im talking special treatment (cause were special ;)
Releasing outside drupal.org
One thing that i kinda fear will happen is that some will begin to release in other ways than use the hated cvs on drupal.org "the I can do it myself" and don't have to rely on the community, the down side of this is off course that its not possible to get user statistics, updates etc & having issue trackers and all the other tools that d.o provides (damn!) - and its gonna be hell for the rest of the community to find themes that are being developed :(
But if thats the alternative to using cvs, well I bet im probably not the only one thats a bit tempted to go that way and just code & design your theme, and get the work done, and gpl it to the bone.
Dude if you just wanna complain...
This I have heard a couple of time, and I can see the logic in it. Drupal is not build for designers or frontend nerds. Its a developer tool, so go another place and don't bother with you colors, ux crap, typography babble and html/css nonsense...
The choice is simple Do we wanna have better themes available at drupal.org?
If we keep up the way we have done so far -well then its not gonna happen :(
Personally I think its a big #fail, and will end in a #Uberfail when we push away the frontend / themers, cause they'll never be a real part of the Drupal family as long as they dont speak the language: CVS.
We all know that commits are gold in a open source system - so pretty please (with sugar on top) give us a chance to do so - without us have to break arms and legs
resources
- D.O handbook on cvs: http://drupal.org/handbook/cvs
- Rob features try on showing how to commit your theme into cvs for the first time: http://mustardseedmedia.com/podcast/episode28
- Todd says im wrong ...wtf : Todd's post here is a must read !
- How designers can release themes on Drupal.org using CVS: designfordrupal.org CVS taskforce
- http://project.designfordrupal.org/org/node/81
Some thoughts
1) Do we need to "move all of CVS to SVN" in order to make it possible for designers to commit themes more easily? What if CVS was used for Drupal core and modules (where they already exist) and SVN was set up for themes. Then we 'frontenders' could use Versions (pretty pretty SVN) without anyone needing to move all of the Drupal code. (Which sounds hard).
2) Yes, maybe a lot of us will learn CVS... but there will still be people who don't and can't. Believe me, I talk to young designers all the time who haven't heard of webstandards and who are asking me to teach them where to put their Dreamweaver code in Drupal. The learning curve it steep. Any thing we can do to make it possible for themes to be committed without the designer knowing CVS will be valuable to the Drupal community. We will get more good themes. So... mentorships, robots, way to submit via upload of a zip file that someone else moves into CVS... Those efforts will pay off.
3) For those of us who want to learn CVS, we need better tutorials. Like ones the explain the concepts, from the beginning. Before getting into code or how to — WTF is this thing? How does it work? I've used FTP for decades, and understand it. You can see what you are doing to the files. I've used SVN via a GUI several times, and didn't break anything, but I got close. I don't have a good conceptual understanding of what's happening — so when things did go wrong, I didn't have a clue. I just clicked until it looked right, and hoped no one pinged me back to tell me I borked the whole project's code locker. I don't like poking at things I don't understand. It makes me nervous and frustrated. Please someone explain using metaphors. Tell us what the CVS is doing. Then we'll better understand what's up with the code needed to command it.
4) ALSO it's hard for many of us to learn, or go make tutorials (like the one I just asked for), or simply try out CVS when you have to apply for an account before you can play with it. I wanted to look at how it works so I can have a more-informed opinion about this discussion, and I realized these are the steps to just get to TRY CVS:
a) design and code an entire theme for contrib
b) put your theme in public so it can can be "evaluated"
c) wait to see if you "get in"
That alone makes me say "oh wait, nevermind. I don't have time for this right now."
I'm sure there are reasons for all of those barriers, and good reasons. It's just, from the perspective of someone new to Drupal's CVS system — it's a big fat reason to say, yeah, forget it. Can someone set up a CVS sandbox where we can go learn and break it while learning until we understand? One that doesn't require 50 hours of prep work to get permission to use?
Alternative?
I am certainly not going to defend CVS in any way. :-) However, I will turn one of the questions back.
Yes, the current process to get a new CVS account is backward for designers. It's actually backward for developers, too, we're just generally stubborn enough and/or used to it enough that we deal. The problem is that we need to keep just anyone of the 2 billion people on the Internet from being able to commit code to our repository (for social reasons, quality control reasons, and legal reasons). So we need some way of vetting new applicants. The current standard is, in effect, "do you have something to show us that you're going to commit that isn't total crap or a duplicate, OR do you have a reference from another existing account holder?" ("I'm going to co-maintain module X with so-and-so" is an accepted reason to apply for an account.)
That's great if you're either doing spec work or are friends with the right people, and kinda sucks otherwise. Not just for themers, but for module devs, too.
So what's the alternative? How do we vet new repository applicants (which we would need to do regardless of whether we were dealing with CVS, SVN, git, bzr, or anything else) in a better way than we do now?
I don't actually have an answer to that. Hopefully someone can come up with one that could be implemented. :-)
New rites
First. This is not just a problem for themers & designers. Developers have the exact same problem. I dunno if the is what Larry alludes, but the whole cvs-issue seems to be a sort of rite of passage. The complexity of cvs provides a sort of gatekeeping.
But the main problem with this rite, is that it doesn't work. There are people who know how to code, but struggle with cvs. And vice versa. This means that alot of quality contributions never make it to d.o - and that sucks.
We must find some other way of ensuring code quality. Horrible revision control usability is not a good solution.
Maybe an idea could be to have two levels of contributions. An closed "premium" repo with quality contributions from Drupal Rockstars, and a public contrib for the rest of us. Once you've proved in the open contrib, that your code is good and used, you can apply for "premium" access. Could that be a solution?
Of course at least the open contrib should be in svn or another modern revision control system.
Not struggling really
Well, I'm not really struggling with CVS. I'm simply refusing to use it as a tool for getting stuff done. I use it as dumb storage for my code, and just dump everything into it prior to creating a release. All my real versioning is done through git, and a quick googling for "drupal module maintainer cvs" gives me pretty much all the help I need when CVS acts up.
Vetting
The whole issue of "vetting" becomes pretty redundant when using a dvcs like git or bazaar. Then the vetting becomes a social, rather than a technical, process. Imagine all drupal code hosted on github - pure bliss.
Feature server
OK, and why don't you list feature server as usable alternative? It works with theme packages also, and you can manage updates with that. You can use git, or manually upload your theme package (no source control at all, just upload the finished or modified theme).. You can release themes on your own Drupal site..
http://code.developmentseed.org/featureserver
theme released with feature server:
http://code.developmentseed.org/tao
Goal to have on d.o
A goal we have is to have what ever setup works on drupal.org. Removing a version control system from the loop isn't too big a deal (I don't think). It's not how we implement it. It's how do we deal with version control where we start with CVS.
VCS in general are often a
VCS in general are often a obstacle to many. It is however an extremely powerful tool in a web designer's toolbox. Do you remember last time you tweaked the CSS and the whole design just broke? With source control, you could just revert, or diff the previous commit and see what changes cause your fine tuned CSS to crash like a multi million airliner. This is a massive time saver and keeps you from having to set your undo buffer to a gazillion steps in order to be able to reverse changes with inadvertent effects.
Fredrik Jonsson (aka frjo) is planning a session on "Version control for designers" at DrupalCamp Stockholm Nov 11-12. Any designer who thinks version control is a scary beast should be there!
stockholm syndrome
im gonna be in stockholm :)
at least to make sure that fredrik is gonna publish his notes.
... oooh and to have host a couple of sessions - really looking forward to it :)
More Education
I see a theme popping up. We need more education in general. Education on VCS is sorely lacking.
!
Great post! You read my mind! Drupal.org ugently needs more documentation and a better overview. I think it's a mess.
Missing alternative...
During yesterday's DforD meeting, I suggested compiling a list of "CVS mentors" who could do all the command-line legwork for designers. (This is discussed in this document on the DforD project site: How designers can release themes on Drupal.org using CVS.) I'll be the first to volunteer to do all the CVS work for any designer who wants to add a new theme to Drupal.org or update an existing one.
What annoys me about this ongoing argument isn't that we're stuck with CVS. It's that most designers will be unhappy with any version control system — SVN, Bazaar, Git, whatever. Designers don't want to learn version control, and telling each other we don't have to learn is defeatist and makes us look like whiners.
That said, I think it's unfair to force designers to learn version control. (That's why I've volunteered as a "mentor." I hope other CVS-savvy folks will join me.) I think it's equally unfair, however, so say that designers must learn. There are GUIs, and we can build tools to make Drupal's CVS easier to use. My colleague David Strauss, for example, is working on a proposal for a module that will allow people to upload a zip file and post it as a release on Drupal.org.
We are professional web designers and developers. Version control is a vital tool — it would be irresponsible of a professional to build a website without it. Manual backups are useful only in catastrophic cases: a deleted directory, server hard drive crash, etc. Designers owe it to themselves, their clients, and the Drupal community to keep an open mind and make an effort to learn.
Besides, the fundamental problem isn't version control. Why aren't there more themes for Drupal? It's not because CVS is difficult. It's because Drupal designers, like developers, spend 95% of their time working on client-specific projects. While many modules can be developed for general use and released on Drupal.org, themes are almost never eligible for general use because they (1) contain a client's copyrighted or trademarked branding or (2) are laced with custom overrides, templates, and other client-specific changes that a "general" Drupal theme would never need. Themes aren't contributed because they are almost always custom-built.
We designers simply don't have time or resources to build "generic" themes. Developers can build modules on client time; themers rarely have that opportunity. Bemoaning CVS is like complaining about the steering on a car without an engine. Let's fix the engine first. Let's make a commitment to building themes before we complain about how difficult it is to release them.
Nailed it!
Todd,
I think you really nailed it in your last two paragraphs.
As a developer by trade, themer/designer by heart, I still hate CVS, SVN, and pretty much all version control, but know just enough to be dangerous, and can manage to commit to D.O, and other areas.
I recently post a blog on why there aren't more "great" contributed themes, and THIS is where you nailed it... the complexity that goes into creating an awesome theme that doesn't fit a specific use case for a client, or in my own experience, redesigning and theming my blog every 6 months, I always say that "I'm going to release this theme", and it never happens, because at some point, I break the mold and start making customizations that will NOT work in a contrib theme for anyone buy myself, and my specific implementation.
It wasn't until I started working on my Omega theme that I began to truly understand what did go into trying to complete a theme to release to the general public that might scratch a few more itches than just my own.
While CVS is tough to master for lots of people (Designers AND Developers alike) I think there are other issues that make it tough for designers to complete themes to release for Drupal.
And while I'm NOT a CVS expert, if someone is so amazing a designer/themer that they have a buttload of themes laying around that SHOULD be commited, I'd be glad to help with that as well.
Blog link?
Can you post a link to the blog you mentioned above? I'm in the middle of drafting something similar, and I'd rather complement your points instead of repeating them.
todds blog post
i added a link to your blog post in the resources, seems that we might can get this ship flying someway or another :)
Link to post I mentioned
Here's the post I mentioned on my blog that turned into more of a rant on the topic: himerus.com/blog/himerus/why-there-arent-more-great-drupal-contributed-themes-availalbe-community
Is it even possible?
Which leads to a very important but oft-avoided question:
Is it even possible to develop a truly "generic" theme that anyone can just drop into their site that does not then "look like Drupal"? How do you have a generic theme that doesn't look generic?
I don't even know if that's possible.
yes
I believe it is possible to make a generic theme that doesn't look like Drupal.
The harder question is how to design for content that doesn't exist yet. And how to make a Drupal theme that works with any configuration of blocks. I believe all these questions are just a high-level design question that can be answered successfully.
I've been thinking and designing around those question for months now. Hopefully once I have something to show, others will think my attempt succeeds in: 1) not looking like Drupal, and 2) flexibly working for many different layouts of content. We'll see!
Ok is no so easy
I have a lot of questions after I read the article but... I going to try first to make all the things and after if I have something for ask or something than I don´t understand so good I come back and ask you OK... At the moment thanks for the information.
Pingback
I do a lot of Development for
I do a lot of Development for Drupal, and I agree that CVS is an awful, awful thing that should die and be replaced with something more modern and user friendly (GIT, BZR, HG, or even SVN) and sensible. They moved all Mozilla projects off of CVS to Mercurial/HG last year, and that was successful (though I believe they had to convert to SVN first as HG will import SVN repos, but not CVS); why can't they do that or something similar for Drupal?
Dealing with CVS puts me off so much, especially when I am used to modern systems like GIT and HG, which I use daily, and trying to check code into Drupal feels like I am editing a CONFIG.SYS file or writing a smiley face that bounces around the screen on a Commodore 64 - antiquated.
Nice design BTW!