pmadhyastha at acm
Apr 5, 2008, 10:12 PM
Post #1 of 5
(332 views)
Permalink
|
|
GSOC Proposal: Bricolage Installer v-4 --- Pranava Swaroop S
|
|
Hi All,
I have been hacking around the bricolage for sometime now. I had also
tried my hand in a simple script with Module::Build and
Module::Install. After initial failures with Module::Build and with
the advice from David, Module::Build seems to be better than
Module::Install. I have made the necessary changes to the proposal and
I am posting the Version 4 of the proposal here again. I have also
made the changes in the GSOC application.
Kindly comment wherever I have made faults.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------
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.
----------
WHY?
----------
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.
-----------
HOW?
---------
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 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'. Locale::Maketext::Gettext would be used to merge gettext
and maketext and other related modules would be used.
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.
There would be a test suite (as suggested by David) by using the
David's FSA::Rules packages for the whole build set. This would be
very helpful for the process of testing the system.
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.
To summarize here is what I am going to do:
--- 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
When?
----------
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 30 -Creation of new modules for installation
especially cpan, distribution specific modules etc. 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. I would also be creating a script to
automatically to download default modules for the faulty packages of a
particular distribution.
-------------MIDTERM EVALUATION -------------------------------------
Phase II
--July 01 - July 15 -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 15 - July 31 - Upgrade and testing modules. This would also
involve a complete and thorough testing of the modules.
--August 01 - August 11 -Documentation and Bug catching
--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.
-----------
Why Me?
------------
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.
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.
-------------------------
Possible Mentors
-----------------------
David Weller (Theory)
Vivek Khurana (no_mind)
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.pdf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thanking you.
Regards,
Pranav
|
