Posted by catch on March 8, 2008 at 8:39pm
Added to official ideas list at http://drupal.org/node/234735
(draft project outline).
Contributing a theme to Drupal.org currently requires a CVS account. This isn't good for getting new designers and themers involved. So this project would involve creating a UI so that themes can be uploaded via a browser, yet still have a project page and versions. Some developers are likely to want to continue managing their themes directly from CVS of course.
Comments
Great Idea
This is a great idea. While I'm now quite comfortable with CVS there is at least one theme I ported back in the 4.x days that never made it to d.o in part because of not being able to get it uploaded easily.
--
Blog: Adding Understanding | Drupal Developer Search | Drupal Services: Brauer Ranch
--
Blog: Joshua Brauer dot com
my only concern is the lack
my only concern is the lack of ability to track changes from one version to the next because we lack atomic commits that refer to WHY each change was made. This least the best practice put forward by VCS systems really helps downstream merges. I do agree this does lower the barrier to entry for designers so to the extent it gets them onboard i agree with it. id just hate to see it become to successful and lose that good info when im merging that describes WHY things were changed, annotations, etc. ;)
FWIW this is my similar complaint to individuals who develop on their HEAD and BRANCH releases simultaneously and just constantly merge changes en masse back to head or the branch with the ominous "sync with head" message instead of a double commit (that actually explains the changes). while ti agree the double work isnt the best option it is why i normally advocate either an empty head (pointer to branch), or stale branches. Then again who besides a couple of us actually track cvs projects and branches so maybe it s a nonstarter.
slight change then
I can't edit the original post for some reason (WSOD), so here's an update on how I think this should be worded:
Create a web-based gui front end for the drupal.org project release system. This will allow people to contribute projects as file uploads as well as directly via cvs, with the initial purpose being for theme contributions.
This should include back end cvs integration (ideally using the existing vcs abstraction available for project module with cvs as the example implementation) and allow for uploads to be tied to releases (5.x-2.1 5.x-3.0-beta) via the GUI. That way code will still be checked into the repository to allow for cvs logs and diffs, but without requiring a cvs account to contribute and update.
On abstraction
Note that neither cvs.module nor the Version Control API do client-side operations currently, such as "cvs add" and "cvs commit". I specifically decided against including those in the Version Control API because client-side operations work on different data (working copies, as opposed to the server-side repository), introduce intermediate states (locally modified, added, not modified, exists on disk but not in the repository, ...) and generally need more assumptions from the Drupal side than is needed for server-side stuff.
So my preference would be a separate module that takes some hints from Version Control API's data structures and overall design, but is functionally independent. The CVS (or <insert-your-favorite-VCS-here>) integration could still be done in the CVS/Subversion/<whatever> backend.
That said, I'm still not comfortable with using this for anything else than themes, because it discourages atomic functionality changes in favor of large code drops with lots of changes at once, and that's what really kills logs and diffs, not the underlying technology.
themes only
I agree it should be limited to themes (at least for quite a long time), but I also think we'll get a better GSoC project if it has the capability to handle modules. Thanks for the notes on Version Control API.
i agree
Right, it should definitely be able to handle all kinds of projects. In fact, different kinds of projects are only distinguished by a single taxonomy term, and it will probably be a bit more effort to have a themes-only version, compared to allowing this functionality for every project on the site.
hmm..
It's my guess that people releasing distinct versions of a theme would continue to do so in cvs, and most of the people using the upload interface otherwise wouldn't be contributing themes at all. So I don't think we'd lose anything compared to what we already have. Also, themes are probably the only area of Drupal where people happily go in and hack stuff around - which makes merging later changes tricky anyway (Zen between 0.6 and 1.0 for example, and this is a theme which actually uses the release system). With easy sub-theming in D6 maybe this'll be less of an issue, but primarily I see an initial upload, and then a major version upgrade if we're lucky for most stuff contributed like this.
Obviously we'd still want the code to get into cvs via the ui so it can be checked out, patched, adopted and maintained by people will cvs access but I'd rather see a few people who start of like this being lured into revision control goodness as they get more involved, than most never getting started at all.
I just checked out OSWD's upload interface - they just have a couple of text fields for notes, and a zip upload. However they also have a list of rules for uploads and an editorial team monitoring submissions, and no upgrade necessary...
Issue tracking?
The problem with themers being hesitant to upload their first theme using a cvs account also counts for beginning developers of course. I think if the themer is seriously committed to following up on the issue queue, he will also take an hour or 2 (or 3 or 4) to get familiar with csv. For the same reason we don't want beginning coders to just upload their module in a .zip and "release" new versions by uploading a new .zip. For other users to bring in their own patches to the theme, this would also be a discouragement. For these reasons I vote -1.
Knowing how to handle CVS
Knowing how to handle CVS does not a good maintainer make. See the hundreds of tiny crappy modules that are in CVS that are not being maintained at all. So, I don't think that's a valid argument to hold against designers/themers that want to contribute.
And I agree with catch that themes will get hacked up beyond a patchable state quite easily. So, for themes I think that yes, we should lower the barrier of entry and provide an easier way for designers to contribute. Even if they only want to give back with just an initial upload and no intention to maintain it as a project. (Might be useful to somehow explicitly label it as such ?)
I'm a designer and trying to get my head around version control in general. It's not 2 or 3 or 4 hours. It takes 2 or 3 or 4 days to get it, and I consider myself quite the geeky designer… That's too much to ask from a designer who just wants to give back a nice stylesheet and some graphics.
css only themes
More than that, with D6 we're looking at potentially hundreds of css only themes - so .info .css a few pngs - not even copy/pasted tpl.php files. I don't see any reason to require cvs for that at all to be honest (although, again, it'd nice to have it checked into cvs in the background so you could look through at diffs if you wanted to).
CVS
I'm one of those part time developers with a crappy module or three in CVS, and my issue is, every time I come back to do development, I have to reread all of that CVS stuff again because otherwise I don't use it. It sure is a barrier to me maintaining my projects as much as I should, something simpler would be nice.
Dave
What is simpler? Do you
What is simpler? Do you have something particular in mind?
So issue track but no cvs?
OK so your idea is to have an issue track, just like any other project, but not to have cvs access? There will be people who do want to use cvs for their themes, or who currently use it. How do you see this? You can have some kind of checkbox to enable cvs access for your themes? Or for some of their themes only? It might also be confusing for people who enable cvs access to see that their current upload is removed...
I see the valid points in this proposal but I think it's really important to lay out a good workflow and perhaps some wireframes before this task can get accepted.
wmostrey - just to make it
wmostrey - just to make it clear this wasn't my idea originally (although I don't remember where it came from) - I just thought it'd be a decent GSoC project for someone. The idea is this goes on our list of stuff for students to pick from and they write up a formal proposal.
I reckon the best option would be a web based gui that checks the theme into cvs so that eventually someone with cvs access (either the original uploader or a new maintainer) could take it over. I'm hoping any GSoC student who takes it on would spec it out in depth in their proposal.
Why limit this to themes?
This is a really good idea. Why limit this to themes, though?
The barrier to entry as a developer here is much too high and one of those barriers in the equirement to learn CVS. I was just talking to an accomplished developer at Drupalcon and he thought he'd committed his module to CVS when it turned out he hadn't. Later in the conversation, he admitted that he didn't like using CVS and probably hadn't uploaded his module correctly. Knowing the difference between branching and tagging shouldn't be necessary (in my opinion) in order to contribute to drupal.org.
If there's an easier way for themes to be uploaded via a browser, let's extend that to other projects (modules, profiles, etc.) as well.
Please, no
I strongly disagree with the parent comment.
Code should always be managed by revision control. It's one thing to give themers an easy way to upload graphics plus a little HTML, but modules? I mean, we're talking about programmers here! Like, people who are actually involved with software development. Those should really know how to use revision control systems, and if they don't, they absolutely need to learn.
Remember why PHP is feared for its security? Not because it's a bad language, but because it's easy enough to be used by people who don't understand software development in the first place. People who combine code snippets they saw elsewhere, without understanding their actual meaning. I know I sound harsh, but that's the type of "developers" that will submit their modules when they previously didn't because they couldn't handle CVS.
Every software developer must be able to use revision control, and if they don't, they can learn it. I'm against allowing code from people who cannot or don't want to learn stuff like this, because all of those are bad software developers and will get us more trouble than useful modules. Also, revision control has real advantages that we don't want to miss (like commit logs and diffs, to name just a few), it would be stupid to throw that away.
Well I think what
Well I think what christefano is suggesting (and what I'd like even if just for themes) is a web-based gui for cvs which just abstracts everything but still gives us branches and tags. This might even result in better use of the release system than we currently have by people who at the moment leave things at -dev for years ("upload this new revision of the module as version 5.x-2.1" for example).
I like this
I suspect we'd see a lot more themes being contributed if themers didn't have to learn CVS. If this could be expanded to modules without losing the version control, that would be even better. As a moduler developer who really hates CVS, I would absolutely love to be able to upload a zip of the current version of the module along with a message of what I changed and have the system figure out what files have changed, which directories moved, which files have been added or deleted, etc, and just take care of making it all nice in CVS. That may be a bit much to ask, but I can dream. :) Back themes, though, I agree that they aren't updated that much anyway, so why not just let them upload a zip and be done with it.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Merging
The problem with any uploader is merging. I guess it's a lesser problem with themes but once you have two maintainers on a module you need to do some sort of merging...
chx: I think once a project
chx: I think once a project gets to the point of two active maintainers, they'd hopefully be using revision control properly anyway.
I went ahead and approved this...
It's on the official ideas list now. I also cross-posted to the Issue tracking and software releases group, in case dww wants to chime in on what a horrible idea this is or why it won't work. ;)
However, I think for themers this is a much-needed resource. I tend to be in agreement with those who've said that for modules this is a bit contentious. But as long as this is coded properly, we could eventually expand its use if we so desired.
Prototype?
I spoke with webchick, catch, and chx about this a bit in IRC and I'm still not hot on this idea. While I see the urge to allow people to avoid using cvs (I am not a cvs fan myself), I'm not convinced that it's really all that hard to use cvs as a developer. I recently created my first module on d.o, and though I have been using cvs to check out code from d.o for a while now, I have never before used cvs to commit code to any repository at all. I followed the CVS quickstart guide and had only one minor glitch that was related to my environment, not the instructions in the guide. I realize that things get more complicated when branches and tags are needed, and I haven't yet needed to do those things, but I think that if people will just follow the instructions we have they would find that CVS isn't as difficult to use as they think.
I have a few worries about the kind of system proposed here:
1. It will be necessary to maintain it. Our CVS related infrastructure team consists only of a few people right now (as far as I know) and is already stretched pretty thin. Keeping a system like this working (and potentially adding new features) will only stretch them thinner, unless new people also get on board with helping out. However, since a lot of this kind of maintenance requires pretty high level access to the servers, my guess is that adding too many new people to help out is not going to happen.
Anything new that is CVS specific only locks d.o into using CVS that much more. I realize that some of this proposal could be abstracted, but obviously some of it will be CVS specific. I doubt that we'll be changing the RCS that we use in the near future, but this just makes it harder to do so (at least if it's implemented on d.o).
Project* is in quite a state of flux right now and may be for some time in the future. We're currently not even using the Version Control API integration that jpetso wrote last summer because the integration of that with the project module and project releases module isn't finished. Things might settle down by the summer, but it's hard to tell. So the project* side of things could be a moving target, and that might be frustrating for the student.
Even though I have worries about this, I do think it's an interesting idea. Are there any prototypes of this? Are any other software collaboration sites using something like this that we could look at and see how they have implemented it? I realize that the Drupal community can be groundbreaking in many aspects, but if this hasn't been done already somewhere else there might be a reason...
Node revision
This idea comes from a site I'm working on, which also deals with less computer-savy people. We use the node revision system. It's certainly less then VCS but it's in Drupal core and it works. Adapt the technology to it's end users.
For example:
1. have a 'theme' content type and 'theme files' which will nodereference to the 'theme' content type (i.e. one node per file).
2. Instead of deleting the node, it will be unpublished.
3. The project*, IMO, is less intimidating and I think themers can use it.
The GSoc project can deal with:
* building this system.
* Creating a UI/ flow that won't freak out people - as the CVS does so well ;)
* Maintaining a connection between nodes and CVS?
I'm not sure I understand
So, are you suggesting that themes on drupal.org go from being projects (as they are currently) to being an entirely new content type which would happen to work with this CVS front end? That would be a pretty big change and would make themes a different beast than other project types (modules, profiles, etc.).
Node revision on top of CVS
Just to play with the idea. The problems we are dealing here is:
1. themeres are intimidated by the CVS.
2. We needs to maintain a CVS, that programmers and themers who do like CVS can us.
The 'node revision' can come on-top of the CVS (i.e. there will always be a CVS, but not necessarily there will be a node revision).
We can create actions -(e.g. a themmer submitted a file, let the system preform a checking/ update. In this case every file will of course change the revision number).
The project* node itself can be the main content type, and will have 'file' content type that will refer to it.
disadvantages:
* Files are duplicated. One in the node revision and one in the CVS.
* The pain of growing a new beast ;)
Advantages:
* Themeres will have to deal with single nodes, without dealing with any CVS aspect. they don't even need to know what CVS is.
* CVS is kept.
You may also say that this system can be applied also on module and profiles, however I myself agree with Jakob that it better not.
Does it make sense? (I won't be insulted if not :P)
[EDIT: Related?]
VCS backend for nodes would be great
And probably worthy of typing up as a separate project in its own right.
I don't like the idea of using it for code at all, but using it for stuff like the handbook so you could checkout the Drupal 5 version or the Drupal 6 version would be awesome.
Lots of issues with synching though..
Interested student
I am interested about taking on this project as a student (and the more I read peoples ideas here, the more I like it!) What would be the best: something that is basically a web-based frontend to CVS or a completely new system (that 'syncs' with CVS or whatever)? Or building on something else that is already there? Or all three? Perhaps a frontend only would be too small for a SoC project and would need to be combined with something else - I'm still learning about CVS so if I'm getting anything wrong please correct me.
Partially done
If you check out:
http://sourceforge.net/project/showfiles.php?group_id=8968&package_id=90...
You'll find this CVS Web client, which claims to do at least part of what we want. However it seems to be missing some critical features, but maybe it is a starting point.
Features (from the FEATURES.txt included with this script):
Add and delete file (And as binary) [No, neither]
Launch a arbitrary CVS command.[No]
Lock a file for edits (becomes owner) [Yes]
Locking should be compatible with reserved checkouts scheme (ie. uses cvs admin -l) [Yes]
Owner can unlock a file after having done an edit [Yes]
Owner can unlock a file after not having done an edit [Yes]
Owner can download a further copy of a file checked out for edit [Yes]
Only the HEAD revision can be locked for edits [Yes]
Only the HEAD revision can be checked in.[Yes]
Owner can see the version number of the file checked out and the proposed version number for the new version [No, not yet]
When owner checks in file he is asked for a comment. The comment can be blank. [NO - MAJOR DEFICIENCY]
The interface can be used to perform tagging.[No]
Comments can be edited after submitted [No]
CVS puts real user names in the cvs log [NO - MAJOR DEFICIENCY]
Non-owner cannot unlock a file [Yes]
Non-owner can see who has got the file out [Yes]
No authentication is required; users can choose who they are based on a list of users. If user name is passed in by the web server then this overrides selection of user name by the user. If user name is not passed in by web server, user can choose user name by user=username parameter. If user name is still not passed in user name is set by cookie. [Yes]
When users first identify themselves a cookie is sent to the browser.[Yes]
CVSwebedit will repeatedly prompt for a user name until one is provided. [Yes]
Only recognised user names will be accepted. [Yes]
User names are listed in a flat file on disk together with a fullname (first name, Surname alias). User names are usually used in listings. [Yes]
All output sent to the browser is first sent to a log file. [Yes, via do_log]
Diagnostics are saved.[No]
Long term logging is implemented [No]
All incorrect usages of cvsweb result in the usage page being shown.[Yes]
All correct usages of cvsweb are listed on the usage page. [Yes]