pmadhyastha at acm
Apr 6, 2008, 6:28 AM
Post #1 of 2
(202 views)
Permalink
|
|
GSOC Proposal: Bricolage Installer v-5 --- Pranava Swaroop S
|
|
Hi all,
I have made the changes which Vivek had pointed out. The CPAN - TEST
modules are relatively new to me, as I have not used them till now. I
request all of you to please correct me if at any place in the
proposal I have made an error. All the changes also have been made in
the GSOC application too.
-------------------------------------------------------------------------------------------------------------------
----------------------------------------------------
Pranava Swaroop
pmadhyastha[at]acm.org Nick: kakashi_
----------------------------------------------------
----------------------------
ABSTRACT
-----------------------------
I quote from "Bricolage" website:
"Bricolage, an open-source enterprise-class content management system,
greatly simplifies the complex tasks of creating, managing, and
publishing the vast libraries of content essential to any
organization."
I wish to take the improvement of the installer and the development of
the modules associated with Bricolage as a part of the Google's Summer
of Code initiative. The main objective here is to ease out
the process of installation and to make the installer more user
friendly, at the same time, making the installer noise free and
flexible for the developers too, which should result in hassle free
update and maintenance. The effort should simplify the whole process
of installation and which would gel beautifully with the afore
mentioned quote.
------------------------------------------------
Benefits to the Perl/Open Source Community
-------------------------------------------------
Looking as it is, there are many problems which entangle the installer
in bricolage. The code of bricolage is quite a bit rough, which makes
the maintenance and bug resolving a tough task.
There are many problems which are reported with respect to the
installer/updater failures. The installation of CPAN modules is yet
another challenge. There are many instances when the automated
installation of the CPAN modules doesn't work. It mostly puts users'
system at the cost of the internet, and every time a new module
release comes out the software might no longer install/upgrade
successfully.
And most of the times, proper guidance to the user is not provided in
case of failures when a particular installation goes wrong.
There are instances when the default modules installed for Apache,
Postgresql are not stable or may not provide the required conditions
for Bricolage to install, in such a case the installer fails suddenly,
echoing a re-installation of the core package(apache/postgresql) message.
Getting installation right is very important.Users get frustrated
quickly by a failed installation. Many won't take a second look.
Henceforth rejuvenating the installer would certainly help an easy
installation and management from both the users end as well as the
developers end.
-------------------------
Project Details
-------------------------
Perl has a provided mature mechanism for the process of installation
by providing CPAN modules. This is the major ingredient in the
creation of the build script and daughter modules - build set which
would be done by using the perl installation toolchain.
'The TOOLCHAIN'
I would be using Module::Build, which performs performs several
actions during compilation, testing, and installation of modules. The
reasons for Module::Build are:- it is pure perl; no make; no shell
commands; easier to customize and cleaner internals. All of which it
came to light when I made a sample install script using both
module::build as well as module::install. However there would be a
small change in the process of installation at the user's end. The
user would be using 'perl Build.PL' instead of the default 'perl
Makefile.PL'. All the features of Module::Build, especially the
command line options which ease out the task would be thoroughly
commented in the Documentation.
There would be other modules which inherit Module::Build, these are
Module::Build::Base<-- this would do the installation in a default
manner. Module::Build::Compat this would help resolve the
compatibility issue with Makefile.PL when the issue arises.
Module::Build::TestReporter would be used to help users report test
failures, the discussion of which is further provided.
Module::Build::Platform::Default initially would be used to install,
after the successful building of the module further divisions into the
Make of the platform would be made.
'Other Processes'
Firstly, the build set would detect if all the required modules are
present in the 'Operating Environment and the distribution' under
consideration. Secondly, if the modules are not present then it would,
if possible, by using sub-scripts, try to install them; else echo the
most appropriate message. If the case is with the CPAN modules, the
script would call sub-scripts to do the installation. These
sub-scripts would be made in such a way that it not only supports the
normal cpan.pm based installation but also the new CPAN++ based
installation. The build script should be capable of detecting the OS
and the Distribution and follow the the Distro's default layout, since
every platform needs custom code. This would be implemented by using a
separate set of modules for each OS/Distro.
The next major part is of the Database Management set, this set also
is an important part. I propose to rebuild the manager. The script
would be able to detect the DB and then there would be specific
subscripts which would be doing the job of calling the DB, creating
the users tables and other DB related tasks as well as backing up and
restoring the DB in case of an upgrade. There is also a huge response
for making custom command line options which the user can provide,
this would be implemented by using 1.> a .conf file which should be
edited by the user or 2.> use direct command line options.
Thirdly, a tool for the purpose of upgrade would be rewritten to
make it more modular. This would again take care of all the data loss
by making clones as is the process being followed now.
Finally, a script made to log would be created in-order to keep a log
of the whole process of installation, which would be very helpful in
the event of a failure of installation both for the user as well as
the panel of developers. I would also make it automatically transfer
the log to the mailing list in-case of failure.
In all the above cases a large portion of the script already
exists, but has many problems. So the task would be to re-sculpt the
whole process of installation. I will try to write almost all the
scripts/modules in perl. Non-Code deliverables will include
documentation for all the scripts and modules mentioned above.
'TESTING'
I propose an on-the-fly testing process in which the each module would
be tested as and when it is coded completely <--- Unit testing. Though
CPAN has a lot of modules for unit testing, modules that I would
prefer are Test-AtRuntime, Test-Script and Test-Compile.
There would be a test suite (as suggested by David) by using the
David's FSA::Rules packages for the whole build set.
After each successful 'logical' install, the installation would be
verified with the correct install.
------------------------
Deliverables:
------------------------
--- 1 ---Build Set - A refreshingly new looking build set with new
added features as mentioned above.
--- 2 ---Database Module - Re-sculpting the database module to suit 1
--- 3 ---Upgrade Modules
--- 4 ---Testing modules using FSA::Rules
--------------------------
Project Schedule
--------------------------
The project would roughly be spaced out as follows:
The breakup of the schedule is made in roughly fortnight format to
accompany a 10 day for the coding process and 5 days for testing and
validation process.
--April 11 - May 01 - Get friendly with mentors and the Perl
community, so that I can understand the ethics of the community.
--May 01 - May 27 - Familiarize self with the complete bricolage package.
Phase I
BUILD SET ONLY
--May 28 - June 15 - Creation of the parent build file and sub
modules,which mainly involve a re-write. The parent build file would
be implementing the Module::Build. There would be careful validation
of the install in each new step.
--June 16 - June 22 - Creation of new scripts for installation of cpan
modules. This is a relatively difficult task as it would involve
careful evaluation of the existing cpan installation module, reviewing
all the pre-requisites for a CPAN++ installation and building the new
modules with constant testing.
--June 23 - June 27 - Creation of a script to automatically to
download default modules for the faulty packages of a particular
distribution.
--June 28 - June 30 - Testing the installation modules and verifying
the installation process.
-------------MIDTERM EVALUATION -------------------------------------
Phase II
--July 01 - July 07 - Creation of Database related modules. This would
basically involve a re-write of the scripts in a more modular way, and
intrinsically beautifying them.
--July 08 - July 15 - Upgrade and implementation of testing modules.
--July 15 - July 20 - Script for the process of logging and automated
bug report.
--July 21 - July 31 - Documentation and extensive testing.
--August 01 - August 11 -Bug catching and fixing bugs
--August 11 - August 18 - Fix Bugs
-------------FINAL EVALUATION----------------------------------------
--August 18 onwards contribute further and maintain the install part.
-----POSSIBILITIES OF ROADBLOCKS---------------------------------
There is least possibilities of road-blocks as I would be starting
early <-- to understand the whole bricolage framework. This would ease
out the pressure.
But in the worst possible case when there is an unavoidable
circumstance, there are three approaches:
I would first try my level best to resolve the issue on my own in the
given time.
I would request my mentor to kindly suggest me a good way of getting out of it.
I would leave the module undone, for a temporary period and would
proceed with other modules. I would again comeback to faulty module
and would work on it. If for some reason the module fails to work, I
would restore the old module to work with the newly built packages.
-----------
BIO
------------
I am a third-year undergraduate at the Malaviya National Institute of
Technology, Jaipur, India. I am pursuing my B.Tech. in Computer
Engineering at the institute. I have been passionate about computers
since my childhood and have been a free software advocate for around 3
years now.
I have contributed to several open source projects, the most prominent
among them have been Gentoo, Apertium and Mozart. These projects have
helped me clear most of my concepts in C and Perl. I also am
interested in Natural Language Processing, where I have mostly used
perl for the purpose of Regular Grammars. These I believe are the
essential requirements for this projects. I have also created a small
content management system and an Online Judge(code Testing Platform)
with perl.
----------------------
Eligibility
----------------------
As per the GSOC requirements, I fulfill all the needed requirements. I
am completely eligible for the Google Summer of Code, 2008 program. I
have all the necessary paper work to prove.
Finally, I would like to express my deep commitment to this project.
You can find more details about me and the projects that I am
currently involved in, at my website. Please don't hesitate to contact
me if any part of this proposal is not clear to you.
---------------------------------
References and Likely Mentors
---------------------------------
I have been in contact with David Weller (Theory) and Vivek Khurana
(no_mind), both have shown an interest in mentoring me. Additionally
my proposal has been commented by Bharder (yukonbob), Marshall Roch
and Eric L. Wilhelm.
Thank you for considering this proposal, and for your time!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Email: pmadhyastha[at]acm.org
IRC Nick: kakashi_
My CV : http://pranava.rspan.in/resume.pdf
My Website: http://pranava.rspan.in/
Latest Version is available at: http://pranava.rspan.in/bricolage_prop.txt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thanking You.
Regards,
Pranav
|
