Apache Administrative Workflow
This proposal is written for the Google's Summer Of Code2005.

About Me

name: Peter Tagunov
contact: Peter.Tagunov@gmail.com
age: 19
education: student of the Moscow State University ( Faculty of Computational Mathematics and Cybernetics ), Russia
expirience: I worked with Perl, PHP, MySQL. My basic programming skills are quite good ( I've created several big projects on C++ with OpenGL and I studied "Algorithmic Languages", "The Architecture of a Computer and Assembler Language", "Operating Systems" and "Computer Graphics" courses in the university ).
I also have a basic understanding of open-source developing principles and the logics of the xml..

The Problem

Creating accounts for new ASF committers currently is multi-stage manual process. The goal of this project is to automate this burdensome and error-prone process as much as possible.

Structure Of The System

I propose to implement ASF Workflow management system as a web application consisting of the following screens.

Implementation Details

I propose to implement the system as s series of Perl CGI scripts running over https on Apache 2. We can use built-in Apache sertificate authentication together with custom-made cookie-based password authentication. To generate PDF we can generate xsl:fo file directly by Perl script and then run it through FOP. I intend to store account requests information in a plain-text file, one request by line. Since the amount of data to be stored is relatively small ( request id, name, e-mail, login ) plain-text format should be enough. Each time a to-be committer fills out the Get CLA form the values entered are stored in file named request_id.txt in "one key=value per line" plain text format, for instance

name=Peter Tagunov
address=Foo Bar, Moscow, Russia
CLA_received_by=Some Board_Member

It is the responsibility of the board member and secretary receiving the signed CLA to verify that name/address/etc on paper match those he/she sees on Account Browsing and to correct those in Account Data Management. (A discrepancy can arise if the to-be committer fills out the Get CLA for multiple times and the singed CLA he sends is not the latest one that was sent to him. )

It is techically feasible to directly control SVN access previlleges form the SCM Access Management. I'm going to consider implementing such access control after all other higher-priority features are compleate.

SVN and CVS repository names can be collected directly from the file system.

ASF workflow system should have access to a list of preexsisting ASF accounts to enforce login name uniqueness. ( to-be committer choses his login name the time he fills Get CLA )

If desired the application will include a monthly cron job reporting account request pending longer then a week to infrastructure maling list.


.tar.gz file with a collection of Perl scripts, static HTML pages, CSS files and images.


Open SSL

Shedule and Milestones

On the 27th of June I'll finish all my endyear exams and immidietly start coding.

The Task

by Dirk-Willem van Gulik

{{{ Procedure 1 - CLA

-> A so called PMC chair can go to a website using a certificate/password and

-> email is send inviting the user to go to a URL, copy goes to PMC.

-> On a certain web site the user fills out some details for the CLA. name, address, etc.

-> As a result of this he gets emailed a PDF with in it a form which has the above data already entered and contains a barcode and a tracking number.

-> user ssigns this form with a pen.

-> user faxes this pdf to an ASF (board) member, gives it to a board member or goes by snail mail.

-> board member checks fax, logs on to the site, with a certificate/password, enters the number of the FAQ, the date he recevied it. This is tracked.

-> the PMC chair gets a message that we have the paperwork for the user.

-> the infrastructure PMC gets a message that the account can be added

-> the board member mails by snail mail the message to the secretary.

-> secretary marks when received + filed (date etc). This is tracked as well.


-> PCM chair now goes to the website; enters the username and selects which SVN repository the user should get access to. In a field called 'evidence' he cuts and paste the URL's or messageID of the relevant votes from the mailing list.

-> The PMC gets a message that the user is going to be added as having XS to these lists.

-> the infrastructure PMC gets a message that the account can be activated for such and such svn repository.

And along with this we want an interface that does

-> where is a request; was it filed, received, what date.

so we can always find out what happened.

Ideally the above should be generic enough to also cope with 2 similar forms; that of the CCLA and the software grant. }}}

PeterTagunovAsfWorkflowProposal (last edited 2009-09-20 23:36:33 by localhost)