Lets define how we should build this project, so we can break it up into tasks and assign them.

First of all... this will be a module. Since Jay Batson wants to be able to add this functionality to a general Drupal design website, this will need to be a plugable feature set.

Secondly, there will be long term goals and short term goals (30 days). The long term goal is to make this flexible enough that other people will be able to utilize this functionality for their own projects using any version control system. Short term is both focused on CVS for Drupal.org with limited functionality, ultra simplified functionality that will be flexible enough to grow into the long term goals.

What are your recommendations for the requirements?

Comments

ceardach’s picture

ceardach commented

Long Term Goals

  • Configure which repository the module is integrating with
    • Pick which version control system to support (CVS, SVN, Baazar, Git)
    • Configuration for where to commit an uploaded project based on the project's type
  • Allow users to upload a zipped/tarred project
    • Allow the user to manage multiple projects
    • Allow a user manage simple major releases
    • Each new file upload commits to the dev version of a major release branch
    • The user can initiate an action to tag a minor release on a major release branch
  • Unzip/untar the uploaded file and commit it to the VCS
    • Store the user's repository authentication securely
    • Commit as user
  • Link release management with project module
    • If the website has the project module enabled, allow the ability to link simple committer with project releases
  • Documentation for Drupal.org Integration
    • How to create the project page on Drupal.org
    • How to create a project release page on Drupal.org

30 Days

  • Allow users to upload a zipped/tarred theme
    • Allow the user to manage multiple projects
    • Support only one major release branch for a project (6.x-1.x OR 5.x-1.x)
    • Each new file upload to a project is a new release
  • Unzip/untar the uploaded file and commit it to the CVS
    • Commit as a stock committer to Drupal.org CVS (CVScommitter? simple_committer?)
  • Documentation for Drupal.org Integration
    • How to create the project page on Drupal.org
    • How to create a project release page on Drupal.org
ceardach’s picture

ceardach commented
Status: Active » Needs review
ceardach’s picture

ceardach commented

I should also note, that the 30 day goal will only support committing themes. The long term goal will allow flexibility to choose what path to commit to based upon tokens garnered from the "project's" node.

gerhard killesreiter’s picture

gerhard killesreiter commented

" * Commit as a stock committer to Drupal.org CVS (CVScommitter? simple_committer?)"

I am not happy with this. Currently, the cvs application process is used to make sure that the author understands the bare neccessities of secure Drupal coding. And yes, this affects themers too. Removing this barrier (yes, it is meant to be one) does IMO not make sense.

ceardach’s picture

ceardach commented

" * Commit as a stock committer to Drupal.org CVS (CVScommitter? simple_committer?)"

I am not happy with this. Currently, the cvs application process is used to make sure that the author understands the bare neccessities of secure Drupal coding. And yes, this affects themers too. Removing this barrier (yes, it is meant to be one) does IMO not make sense.

Do you have any alternative recommendations?

We can put storing CVS credentials securely into the first phase of development, but that'll likely push us past the "30 days" phase.

killes@www.drop.org’s picture

killes@www.drop.org commented

The CVS credentials are already stored in the database so it should not be too hard to use them for cvs write operations.

ceardach’s picture

ceardach commented

The CVS credentials are already stored in the database so it should not be too hard to use them for cvs write operations.

For a d.o specific integration this could work. However, due to the overhead of developing a module that requires access to d.o's database, and getting a new feature added to d.o (especially with the redesign overhead), we should figure out something more modular.

We can probably store the credentials in a hash, it'll just take a little bit of time to develop that.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

IMO, secure storage of credentials is a requirement. We can't have this module bypassing community processes put into place to prevent abuse.

ceardach’s picture

ceardach commented

Alrightie. So secure storage of credentials is required for an alpha release.

30 Days (Alpha 1 Release)

  • Allow users to upload a zipped/tarred theme
    • Allow the user to manage multiple projects
    • Support only one major release branch for a project (6.x-1.x OR 5.x-1.x)
    • Each new file upload to a project is a new release
  • Unzip/untar the uploaded file and commit it to the CVS
    • Store the user's repository authentication securely
    • Commit as user
  • Documentation for Drupal.org Integration
    • How to create the project page on Drupal.org
    • How to create a project release page on Drupal.org
arhak’s picture

arhak commented

Support only one major release branch for a project (6.x-1.x OR 5.x-1.x)

doesn't makes sense
having major/minor versions against Drupal versions 5/6/7/8 would be as difficult as having major/minor versions at free will, i.e. 6.x-1.x, 6.x-2.x, 7.x-1.x, 7.x-2.x, etc

You may include into the major/minor version support having any kind of major/minor version
including suffixes like alpha/beta/rc, I will contribute the code for discriminating which branch/tag needs to be created/updated or if there is non-sense like attempting to commit a 6.x-1.0-beta2 after an 6.x-1.0-rc1 already exists