GSOC Proposal: Bricolage Installer v-3 ---Pranava Swaroop S

Hi,

This is the version 3 of the proposal.
I hope this is fine!

--------------------------------------------------
Pranava Swaroop S
pmadhyasthaacm.org
--------------------------------------------------
------------------------------------------------------------
---------------------
REJUVENATING THE INSTALLER FOR BRICOLAGE
------------------------------------------------------------
----------------------
----------------
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 of the project 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
updation 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 'tough
to
understand', which makes it really difficult for the process
of
maintenance and resolving bugs.
 There are many problems which are reported with respect to
the
installer/updater failures. The CPAN modules installation is
another
big challenge. There are many instances when the automated
installation of the CPAN modules doesn't work.
It 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-installtion of the core
package(apache/postgresql).

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.
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 neo 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,
since this
manager is more specific. The current installer working fine
with the
postgresql only, but since there is a plan of implementing
other DBs
[h
ttp://bricolage.sourceforge.net/docs/Bric/FAQ.html]
henceforth a
generic level is called for. 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
upgradation. All the scripts in this set would be only in
perl. There
is also a huge response for making custom command line
options which
the user can provide, this would be implemented by using a
.conf file
which should be edited by the user.

Thirdly, a tool for the purpose of upgrade would be
rewritten to
account for the different changes that has been made above.

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
Davids FSA::Rules packages for the whole build set. This
would be very
helpful for the process of testing the system.
In the 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 ---Updgradation Modules
--- 4 ---Testing modules using FSA::Rules

When?
----------
The project would roughly be spaced out as follows:

--April 11 - May 01 - Get friendly with mentors and the Perl
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.
--June 16 - June 30 -Creation of new modules like cpan,
distribution
specific modules etc.
-------------MIDTERM EVALUATION
-------------------------------------
Phase II
--July  01 -  July 15  -Creation of Database related
modules.
--July  15 -  July 31 - Upgradation and testing modules
--August 01 - August 11 -Documentation and Bug catching
--August 11 - August 18 - Fix Bugs and make the Mentor Happy

-------------FINAL
EVALUATION--------------------------------------------------
-
--August 18 onwards contribute further and maintain the
install part.


-----------
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 opensource 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.

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.

Thank you for considering this proposal, and for your time!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
My CV     : http://pranava.rsp
an.in/resume.pdf
My Website: http://pranava.rspan.in/

Latest Version is available at: http://pra
nava.rspan.in/bricolage_prop.pdf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Best

Pranava

On Mar 30, 2008, at 07:58, Pranav wrote:

> 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 of the project
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
> updation and maintenance. The effort should simplify
the whole process
> of installation and which would gel beautifully with
the afore
> mentioned quote.

"Updation" is not an English word.

> Getting installation right is very important.Users get
frustrated
> quickly by a failed installation. Many won't take a
second look.

Yes, this is the key argument for improving the installer.

> 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.

Are you suggesting that Bricolage would also try to install
package  
for other dependencies such as PostgreSQL or
Apache/mod_perl?

> These
> sub-scripts would be made in such a way that it not
only supports the
> normal cpan.pm based installation but also the neo
CPAN++ based
> installation.

It doesn't need to be both, and honestly, CPAN.pm has
improved so much  
in the last couple of years that CPAN++ looks less
attractive. But I  
would recommend you use whichever you're more comfortable
using.

> 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.

There also needs to be an option to install everything in a
single  
directory. This is the default in the current installer, and
 
simplifies quite a few things for most users. See the
"s - single"  
option in inst/config.pl.

> The next major part is of the Database Management set,
this set also
> is an important part. I propose to rebuild the manager,
since this
> manager is more specific. The current installer working
fine with the
> postgresql only, but since there is a plan of
implementing other DBs
> [h
ttp://bricolage.sourceforge.net/docs/Bric/FAQ.html]
henceforth a
> generic level is called for.

Actually, in trunk, everything has been updated to support
both  
PostgreSQL and MySQL. So it's already generalized. That's
not to say  
that it couldn't use any refactoring, however.

> 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
> upgradation. All the scripts in this set would be only
in perl. There
> is also a huge response for making custom command line
options which
> the user can provide, this would be implemented by
using a .conf file
> which should be edited by the user.

Or use the command-line options, yes?

> Thirdly, a tool for the purpose of upgrade would be
rewritten to
> account for the different changes that has been made
above.

The upgrade bit is pretty independent of any of the above,
actually.

> 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.

That's nice.

> There would be a test suite (as suggested by david) by
using the
> Davids FSA::Rules packages for the whole build set.
This would be very
> helpful for the process of testing the system.
> In the 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.

This reminds me: Do you have any examples of Perl you've
written in  
the past, preferably in the form of modules and/or classes?
If not, do  
you have examples of modular code in another (preferably
dynamic)  
programming language? Modularization is key to writing a new
 
installer, IMHO (the current installer is not at all
modular, just a  
bunch of fugly Perl scripts).

> The project would roughly be spaced out as follows:
>
> --April 11 - May 01 - Get friendly with mentors and the
Perl  
> community 

Which means what, exactly?

> --May  01 - May 27-Familiarize self with the complete
bricolage  
> package.

Good. I imagine you'd start writing some code then, too,
eh?

> Thank you for considering this proposal, and for your
time!

Thank you for taking the time to submit it.

Best,

David