Requirements
ceardach - June 14, 2009 - 18:23
| Project: | Simple Committer |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
Description
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?
#1
Long Term Goals
30 Days
#2
#3
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.
#4
" * 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.
#5
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.
#6
The CVS credentials are already stored in the database so it should not be too hard to use them for cvs write operations.
#7
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.
#8
IMO, secure storage of credentials is a requirement. We can't have this module bypassing community processes put into place to prevent abuse.
#9
Alrightie. So secure storage of credentials is required for an alpha release.
30 Days (Alpha 1 Release)
#10
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