Are we solving the wrong problem?

The only issue with allowing straight uploads and no CVS, is the only quality control we currently have Drupal.org is the cvs account process - if you can just upload a zip or tar.gz, then you don't go through that process. However, we've been discussing in the security team (and I think there's an RFP somewhere) that new projects go through a very basic security review before the first official release can be posted - that would solve this entirely, and mean we just need to change one Drupal.org process and enable an existing feature. Which seems pretty good to me.

IIRC the ftp.osuosl.org process works as follows:

1) create tarball on drupal.org

2) rsync

I don't think tthe files on ftp.d.o are backuped, but the ones on d.o should.

Wow, where did this come from? I hate the idea of using FTP for contributing themes.

What's wrong with CVS (or at least another drupal.org-hosted version control system)? It works well and keeps the quality reasonably high.

The idea came from the recent design4drupal camp in Boston. It is a way to lower the barrier to entry for designers to contribute to the community. CVS can be a bit of a bear to even the computer savvy let alone a designer that has barely touched a command line.

I'm not sure how I feel about the idea, but the idea didn't even start there -- I've heard it from almost every designer I've talked to who was interested in kicking around new themes and contributing them. The idea of FTPing or web-uploading a zipped theme package has been rolling around for a few years now.

Hm. I'm not sure. A hybrid where some themes are available only by FTP and some are available in CVS seems like it would make command-line deployments a complete B.

Or did I misunderstand?

@psynaptic: Well, using CVS while dismissing version control workflow in favor of tarball uploads is actually no improvement or quality standard. It just feeds stuff into CVS, the only goal being that releasing tarballs (...themes) works for those people who do not want to learn version control. That approach will lead to unusable version history, and while it's not that cool to lack history, skipping CVS altogether is better than abusing it for something that will yield ugly and misleading results.

Gerhard Killesreiter did not suggest that files are uploaded via FTP, that is just what drupal.org does by itself to guarantee safe and distributed storage with its set of download mirrors. File upload would still happen by means of a regular upload form, very much like the one that has been planned by this module.

Using project_release's own file upload mechanism has a bunch of advantages:

• No abuse of CVS (see above).
• project_release already has release file management and form validation built in, why work around when the problem can be solved properly and upstream?
• Significantly less work to do than implementing this module in a remotely clean fashion.
• Improvements benefit all users of the project and project_release modules, rather than the limited drupal.org use case tackled by this module.
• Users don't need to hand out their confidential CVS password to other websites.

cvs.module (a.k.a. cvslog), which powers drupal.org's CVS integration, unconditionally replaces the file upload form with the multi-step CVS release integration form. Both end up with a file being created and stored in project_release's file table, so technically it doesn't make a difference if a release is using CVS or not.

Version Control API (with project node integration) already has the capability to make file upload forms and version control integrated forms live side by side - I'm not sure what code I put into it to enforce version control integration (or not), but I put a good amount of effort into it to make sure it works with both cases. As much as I dislike telling other people to contribute to my modules, I think the easiest way to get tarball uploads on drupal.org is to help with the Version Control API deployment. Improving cvs.module is still an option too, of course.

I can't currently find a corresponding issue in the project or cvslog issue queues, but I *think* I remember dww talking about a "dual mode" (both file upload and CVS releases) being a welcomed feature. Anyways, so much for my 2 cent on this issue.

hurray for jpetso...

- if you're not actually *using* CVS, what's the point of using CVS?

- project_release itself provides file uploads. cvslog form_alters all of that out of the way and hijacks the release node form and turns it into a multi-step wizard (historical note: it's been doing that since the 4.7.x days -- the horror). it seems silly to hack around something that's already a hacked modification of what's ultimately a simple node creation form with a file upload. if the goal is to convert a themer's .zip or .tgz into a release node, why go through 2 intermediary steps?

however: i'm deeply worried that if we start allowing this for themes, it's going to open a pandora's box. certainly, the translators will want this, too. and, i'll bet $5000 that there will be "lazy developers" that will want to start doing it for their modules, too. and, i'll bet another $5000 that advanced developers will say "screw CVS, I'm developing my code exclusively in bzr, and when I want to cut a d.o release, I'll just export a .tgz and upload it to a release node"....

"what's wrong with that?", you ask... let me count the ways:

a) the d.o packaging script is really smart. it prevents a lot of errors automatically, and it's a good place to enforce certain things (file layouts for translations, .info file attributes needed by update status for modules and themes, etc). if everyone starts being responsible for doing all this work either manually or automating it themselves, they're going to mess up (a lot).

b) we're talking about digital signing of releases and tarballs so that things like core being able to update your contribs on a site by the press of a button isn't the horrifying nightmare of "oh crap, i wonder what code my site is actually using".

c) it's a *lot* harder to roll patches against a tarball than the latest code in CVS.

d) it's a *lot* harder for the security team to grep through all of contrib for related security bugs when we find a particular kind of problem that might effect N different modules/themes. "cvs co contributions" is a crapload easier than "write a script to download every tarball or .zip file and unpack them all".

... i'm sure I could keep going, but it's 1:20am where I'm currently sitting, and I've had an exhausting few days, so I'm not in a good mental space to continue.

As much as I'd like to lower the barrier to contribute on some levels, I'm terrified of doing so on others. I genuinely hope there are good answers to these concerns, I just don't see them right now.

I think that dww's con list makes it clear that this approach isn't going to work. We need to hook back into CVS.

Could someone help articulate the FUD around tying a file upload field to CVS processes? I see complaints like:

- unusable version history: why? why can't the file upload form have a "log message" / "release notes" box? You still can browse the repository and get diffs. And this is really no more evil than people who work out of a Git repository and periodically sync a bunch of commits over to Drupal CVS (*cough* jpetso *cough* ;))
- It's an "abuse" of CVS: Clarify, please? AFAICS this is going to use exactly the same CVS commands that we would use from the command line; just automated and behind the scenes.
- limited drupal.org use case: This is true for now. But the project page clearly states that once the initial proof of concept is working, the author intends to generalize it, and this will naturally mean integrating more closely with the same generalized tools that Drupal.org wants to move to. And IMO, it's best for this to happen after SoC is over anyway, since there's already a lot of activity going on to manage.
- if you're not actually *using* CVS, what's the point of using CVS? For all of the people who *are* using CVS, as well as the package validation scripts, as well as the ease of rolling patches, as well as basically the opposite of everything you mentioned in your reply of why this would suck if we went the straight file upload route. :)

# Significantly less work to do than implementing this module in a remotely clean fashion.
# Users don't need to hand out their confidential CVS password to other websites.

I do concede that those are true.

However, we're balancing this with fighting an absolutely ridiculously stupid barrier of entry. If you hang around in #drupal for any length of time, you will realize that most of our developers (even the really good ones) at best know the bare minimum of CVS to scrape by, and at worst can't figure it out at all. And these are people who live in code 24/7, to most of whom version control systems are part of their toolset -- just not CVS. It's entirely unreasonable to expect people who are aces in Photoshop, XHTML, and CSS to master something as arcane as CVS when our developers can't even do it. We know for a fact this requirement is actively prohibiting people in the community from contributing, which to me is completely unacceptable. I am willing to deal with an awful lot of downsides if it means that designers can be a bigger part of this community (although the password one is quite concerning, I do admit).

Derek's pandora's box argument also applies. The next obvious place for this to go is translations (and possibly documentation, if we ever get that single-sourcing stuff down). It might even apply to module developers someday. Yes. Absolutely. But, again: What's the problem? If you remove all of the cons Derek listed that are related to bypassing CVS, you're not left with any from what I can see. So let's not bypass CVS. Then everyone wins, no?

I'm very open to hearing arguments for why a form executing CVS commands on behalf of a user will ruin Christmas, but let's stop using loaded language like "abuse" and stick to objective, technical arguments, ok? :)

unusable version history: why?

Because if the maintainers don't review diffs before committing, upload a single tarball instead of continuous changes and rename files and directories without some inhibition threshold, diffs won't be very helpful in their actual purpose to show reviewers which changes happened where and why.

And this is really no more evil than people who work out of a Git repository and periodically sync a bunch of commits over to Drupal CVS (*cough* jpetso *cough* ;))

Show me *one* commit that does any harm to the my modules' history. Unlike the versioncontrol_git developers, I stick with drupal.org CVS as the canonical upstream and I sync per commit, not per release. Don't laugh at me for lowering *that* barrier to entry in a perfectly legitimate way. (Even with versioncontrol_git, there's a usable history in another place, as opposed to tarball uploads where it isn't created in the first place.)

I totally understand the need for tarball uploads, and I'm not in any way opposed to achieving that functionality; in fact, I support it (which is why I commented here). I thought that non-CVS uploads make more sense, however Derek's points are (as always) very true. If he prefers the commit-via-tarball-upload solution - obviously, the current status quo is not an option - then I'm going to support that too. The question is not whether we want to allow tarball uploads because it's going to be worked on either way, the question is just the way in which the problem is attacked.

Also, I still think "abuse" is the right word, as you're using a version control system to reach a different goal (tarball releases) without caring about the version control aspect (= proper diffs and continuous history). Hopefully you'll agree that doing it this way is not the way that CVS is meant to be used, but there's no offence in that, and I'm fine with an auto-committer module too.

RE: commit history

What simple_committer is proposing to do will actually preserve a better sense of history than the people who would be using it would have done otherwise. The value of an accurate commit history is a concept they don't even understand. These are people who are accustomed to creating directory copies as backups, and move into version control as just a better backup system. They'll forgo commit messages, and commit at arbitrary stages (like once per day). I've even encountered developers who have never used Diff.

What we'd need to solve this problem is either 1) better, clearer and straight forward documentation, 2) a process that will slowly introduce them to the concepts.

As a whole, Drupal's contrib doesn't have a perfect history. I, and my coworkers are trying hard to provide every commit to Drupal's CVS, but it is very tedious and we do it very rarely. I'm in the process of creating a script that will re-commit all of Git's commits back to CVS, then I plan on setting up a place that'll automatically re-commit our Git projects every night.

@ceardach, regarding Git scripts: In case you don't know about http://github.com/sdboyer/drupal-git-scripts/tree/master yet, please take a look at it. Also, some Git users are lurking in #drupal-vcs, in case you want to discuss stuff with smart people like sdboyer or neclimdul (I also hang around in there). Although that's going a bit off-topic now, sorry for that.

subscribe...