GSOC Proposal: Bricolage INSTALLER ---- Pranava Swaroop S

~~~~~~~~~~~~~~~
    Pranava Swaroop S
 pmadhyasthaacm.org
~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
REJUVENATING THE INSTALLER FOR BRICOLAGE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Greetings!

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. This project will help resolve most of
the
installer based problems of Bricolage.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Benefits to the Bricolage Community
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This project would simplify the whole process of
installation and
would gel beautifully to the afore mentioned quote. This
project will
also enhance the usage scope of Bricolage considerably.

~~~~~~~~~~~~
Deliverables
~~~~~~~~~~~~
1. Creation of an executable 'OS-Specific' configure file.

2. Creation of a perl script, replacing the existing
Makefile

3. Creation of a robust-user-friendly INSTALL file

4. A script to manage the database back-end while the
process of installation.

5. A separate upgrade script.

6. Re-organizing the perl scripts in order to smoothen the
process of
installation

Non-Code deliverables will include documentation for all the
scripts
and modules mentioned above.

~~~~~~~~~~~~~~~
Project Details
~~~~~~~~~~~~~~~
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 for the developers
too, which
should result in hassle free updation and maintenance.

The first part of the project involves the creation of a
'OS-Specific'
configure file, which requires (for unix based environments)
1.
autoconf, 2. libtool, 3. gettext, 4. m4; all of these come
along with
a standard version of unix based environments.
This configure script also checks for all the dependencies;
in case of
failure it readily echoes a verbose message to the user,
which may
also consist of the link to the right direction, also by
making it OS
specific it would point to the specifics of the package
needed for the
distribution.

There may be an issue of an CPAN modules, which may be
resolved by
switching to CPAN++, which is presently being resolved using
cpan.pm,
there by incrementing the minimum requirement to perl
v-5.10.

Creation of the INSTALL file, with certain options thrown as
default
and which can be changed by the user through the command
line.

Creation of a database manager which is accessed while the
process of
installation is being processed. This database manager
manages the
back-end of the DB and also creates the databases.

It is also a necessary that a separate upgrade script be
added, which,
helps in the process of up-gradation. This script can be
called from
the INSTALL script by passing a command line option into
INSTALL.

Another most important part of the whole process is
optimization of
the whole code(which is utilized during the process of
installation)
which would surely decrease the noise. This would further
increase the
ease of maintenance of the whole installation process.

Suggestions are welcome!
~~~~~~~~~~~~~~~~
Project Schedule
~~~~~~~~~~~~~~~~
The project is planned to be split across 6 major Phases:

1. Analysis (May 26 - May 31)(I would be happy if I could
start early):
This phase involves interaction with the mentor and the key
people
involved in similar projects  in order to exactly understand
the
requirements.

2. Development Part I (June 1 - June 15):
This phase will involve the creation of configure file.

3. Development Part II (June 16 - July 10):
This phase will involve the process of resolving CPAN
migration issues.

4. Development Part III (July 11 - July 25):
Creation of the INSTALL file.

5. Packaging (July 26 - August 5):
Creation of the minor modules => Database Manager and
Upgrade Manager.

6. Testing and Wrap-Up (August 5 - August 21):
Thoroughly test every aspect of the finished package. This
phase will
also include the development of non-code deliverables.

~~~
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 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/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~
    Pranava Swaroop S
  pmadhyasthaacm.org
 ~~~~~~~~~~~~~~~

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 REJUVENATING THE INSTALLER FOR BRICOLAGE
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Greetings!

 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. This project will help resolve most of
the
 installer based problems of Bricolage.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Benefits to the Bricolage Community
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 This project would simplify the whole process of
installation and
 would gel beautifully to the afore mentioned quote. This
project will
 also enhance the usage scope of Bricolage considerably.

 ~~~~~~~~~~~~
 Deliverables
 ~~~~~~~~~~~~
 1. Creation of an executable 'OS-Specific' configure file.

 2. Creation of a perl script, replacing the existing
Makefile

 3. Creation of a robust-user-friendly INSTALL file

 4. A script to manage the database back-end while the
process of installation.

 5. A separate upgrade script.

 6. Re-organizing the perl scripts in order to smoothen the
process of
 installation

 Non-Code deliverables will include documentation for all
the scripts
 and modules mentioned above.

 ~~~~~~~~~~~~~~~
 Project Details
 ~~~~~~~~~~~~~~~
 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 for the developers
too, which
 should result in hassle free updation and maintenance.

 The first part of the project involves the creation of a
'OS-Specific'
 configure file, which requires (for unix based
environments) 1.
 autoconf, 2. libtool, 3. gettext, 4. m4; all of these come
along with
 a standard version of unix based environments.
 This configure script also checks for all the dependencies;
in case of
 failure it readily echoes a verbose message to the user,
which may
 also consist of the link to the right direction, also by
making it OS
 specific it would point to the specifics of the package
needed for the
 distribution.

 There may be an issue of an CPAN modules, which may be
resolved by
 switching to CPAN++, which is presently being resolved
using cpan.pm,
 there by incrementing the minimum requirement to perl
v-5.10.

 Creation of the INSTALL file, with certain options thrown
as default
 and which can be changed by the user through the command
line.

 Creation of a database manager which is accessed while the
process of
 installation is being processed. This database manager
manages the
 back-end of the DB and also creates the databases.

 It is also a necessary that a separate upgrade script be
added, which,
 helps in the process of up-gradation. This script can be
called from
 the INSTALL script by passing a command line option into
INSTALL.

 Another most important part of the whole process is
optimization of
 the whole code(which is utilized during the process of
installation)
 which would surely decrease the noise. This would further
increase the
 ease of maintenance of the whole installation process.

 Suggestions are welcome!
 ~~~~~~~~~~~~~~~~
 Project Schedule
 ~~~~~~~~~~~~~~~~
 The project is planned to be split across 6 major Phases:

 1. Analysis (May 26 - May 31)(I would be happy if I could
start early):
 This phase involves interaction with the mentor and the key
people
 involved in similar projects  in order to exactly
understand the
 requirements.

 2. Development Part I (June 1 - June 15):
 This phase will involve the creation of configure file.

 3. Development Part II (June 16 - July 10):
 This phase will involve the process of resolving CPAN
migration issues.

 4. Development Part III (July 11 - July 25):
 Creation of the INSTALL file.

 5. Packaging (July 26 - August 5):
 Creation of the minor modules => Database Manager and
Upgrade Manager.

 6. Testing and Wrap-Up (August 5 - August 21):
 Thoroughly test every aspect of the finished package. This
phase will
 also include the development of non-code deliverables.

 ~~~
 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 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/

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi PRANAV, thanks for taking the time to put this together
and submit  
it to the list. I really appreciate your interest in helping
to make  
Bricolage better!

On Mar 28, 2008, at 15:23, PRANAV wrote:

> ~~~~~~~~~~~~~~~
>    Pranava Swaroop S
>  pmadhyasthaacm.org
> ~~~~~~~~~~~~~~~
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> REJUVENATING THE INSTALLER FOR BRICOLAGE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Greetings!
>
> 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. This project will help resolve most
of the
> installer based problems of Bricolage.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Benefits to the Bricolage Community
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This project would simplify the whole process of
installation and
> would gel beautifully to the afore mentioned quote.
This project will
> also enhance the usage scope of Bricolage
considerably.
>
> ~~~~~~~~~~~~
> Deliverables
> ~~~~~~~~~~~~
> 1. Creation of an executable 'OS-Specific' configure
file.

Um, what? No configure please. Just a Perl build script
would be  
great. Like you mention here:

> 2. Creation of a perl script, replacing the existing
Makefile

This can then load OS-specific configuration information
from a file.  
Is that what you meant? I would no be executable, then.

> 3. Creation of a robust-user-friendly INSTALL file

This is just documentation you're talking about, yes?

> 4. A script to manage the database back-end while the
process of  
> installation.
>
> 5. A separate upgrade script.

These already exist. How would you change them?

> 6. Re-organizing the perl scripts in order to smoothen
the process of
> installation

How so?

> Non-Code deliverables will include documentation for
all the scripts
> and modules mentioned above.

Excellent.

> ~~~~~~~~~~~~~~~
> Project Details
> ~~~~~~~~~~~~~~~
> 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 for the
developers too, which
> should result in hassle free updation and maintenance.

Yeah!

> The first part of the project involves the creation of
a 'OS-Specific'
> configure file, which requires (for unix based
environments) 1.
> autoconf, 2. libtool, 3. gettext, 4. m4; all of these
come along with
> a standard version of unix based environments.

Say what? No no, I don't think we need any of that stuff.
There is a  
Perl build toolchain that would fit much better, and will
run across  
platforms. It consists of Module::Build and
Locale::Maketext. The  
latter is already used by Bricolage for localization. For
library and  
dependency detection, we can make use of App::Info. I'd
rather not get  
into the Unix C build tool chain at all if we can avoid it,
partly  
because I don't understand it at all (and I think that few
in this  
community do), and partly because Bricolage is not an
application that  
needs to be compiled. That is to say, the way its
installation works  
is completely different than, say, the way PostgreSQL or
Apache  
compiling and installation work.

> This configure script also checks for all the
dependencies; in case of
> failure it readily echoes a verbose message to the
user, which may
> also consist of the link to the right direction, also
by making it OS
> specific it would point to the specifics of the package
needed for the
> distribution.
>
> There may be an issue of an CPAN modules, which may be
resolved by
> switching to CPAN++, which is presently being resolved
using cpan.pm,
> there by incrementing the minimum requirement to perl
v-5.10.

We need to support 5.8.x for a while. Not that I'm against
this, mind  
you, it just might be a year or so before it's a reasonable
thing to do.

> Creation of the INSTALL file, with certain options
thrown as default
> and which can be changed by the user through the
command line.

Don't really follow you here.

> Creation of a database manager which is accessed while
the process of
> installation is being processed. This database manager
manages the
> back-end of the DB and also creates the databases.

What's to manage other than the creation of the database?

> It is also a necessary that a separate upgrade script
be added, which,
> helps in the process of up-gradation. This script can
be called from
> the INSTALL script by passing a command line option
into INSTALL.

Yeah, not dissimilar to the way the current installer
works.

> Another most important part of the whole process is
optimization of
> the whole code(which is utilized during the process of
installation)
> which would surely decrease the noise. This would
further increase the
> ease of maintenance of the whole installation process.

Well, I have to admit that I'm not too concerned about the
performance  
of the installer. It's more the quality of the code and the
way that  
it's organized that's a problem. If the installer were
rewritten to be  
highly modular and easy to hack on and/or expand, but was
slower, I  
could not care less.

> Suggestions are welcome!
> ~~~~~~~~~~~~~~~~
> Project Schedule
> ~~~~~~~~~~~~~~~~
> The project is planned to be split across 6 major
Phases:
>
> 1. Analysis (May 26 - May 31)(I would be happy if I
could start  
> early):
> This phase involves interaction with the mentor and the
key people
> involved in similar projects  in order to exactly
understand the
> requirements.

This is good, because based on the above, I think you'll
need to first  
spend some time becoming familiar with the standard Perl
build chain,  
and revise your plans around that.

> 2. Development Part I (June 1 - June 15):
> This phase will involve the creation of configure
file.
>
> 3. Development Part II (June 16 - July 10):
> This phase will involve the process of resolving CPAN
migration  
> issues.

Any idea what this would involve?

> 4. Development Part III (July 11 - July 25):
> Creation of the INSTALL file.
>
> 5. Packaging (July 26 - August 5):
> Creation of the minor modules => Database Manager
and Upgrade Manager.
>
> 6. Testing and Wrap-Up (August 5 - August 21):
> Thoroughly test every aspect of the finished package.
This phase will
> also include the development of non-code deliverables.

The schedule looks okay, but as I say, your proposed
approach seems a  
bit off the mark to me, in terms of meeting the needs of
this  
community and its culture. It also needs a fair bit of
expanding,  
which means, I think, that you need to play around a bit
with the  
current installer to see how and why it's painful for users.
And I  
mean before you submit your proposal to Google.

I don't mean to be too tough on you, but there are a lot of
gaps that  
need filling in here, in your knowledge of Bricolage and its
current  
installer, the Perl build chain, and the expectations of
Bricolage  
users in general.

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

Nice. For an installer I wrote recently, BTW, I used my own
FSA::Rules  
module to handle the decision tree. It worked quite nicely,
and was  
fairly straight-forward to test.

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

Thank you for taking the time to put it together and end it
in. I look  
forward to your next iteration!

Best,

David

On Sat, Mar 29, 2008 at 03:53:58AM +0530, PRANAV wrote:
> ~~~~~~~~~~~~~~~
>     Pranava Swaroop S
>   pmadhyasthaacm.org
>  ~~~~~~~~~~~~~~~
> 
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  REJUVENATING THE INSTALLER FOR BRICOLAGE
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Greetings!
> 
>  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. This project will help resolve
most of the
>  installer based problems of Bricolage.
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Benefits to the Bricolage Community
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  This project would simplify the whole process of
installation and
>  would gel beautifully to the afore mentioned quote.
This project will
>  also enhance the usage scope of Bricolage
considerably.


I had a brief chat w/ Theory and no_mind on IRC in
#bricolage (irc.perl.org) and I'll post the jist of those
thoughts here, as suggested in irc.


>  ~~~~~~~~~~~~
>  Deliverables
>  ~~~~~~~~~~~~
>  1. Creation of an executable 'OS-Specific' configure
file.

This sounds good to me; I've played a bit with the current
installer, and tweaked it for my local conditions, but don't
recall (as I'm typing this) exactly what I did, or what the
mechanism was (ie: changing a global Perl variable, tweaking
an ENV variable, adjusting code)... anyway, in principle, no
matter what the mechanism, this sounds good.

>  2. Creation of a perl script, replacing the existing
Makefile

This sounds fine enough, but something that I'm not clear
about comes up later in the description of Point 1, above.
Point 1 is below described as using part the auto* suite of
tools (libtool, autoconf, m4 macros, etc)... all this
generates Makefiles, so I wonder why move away from
Makefiles here, and toward them in Point 1? Might we be
served well enough with strictly Makefiles (driven by auto*
or not), or stick strictly with Perl (and consider it a
prerequisite that one needs to bootstrap the process; I'm
not 100% a fan of this, since not all *nix distros ship w/
Perl, but...)

>  3. Creation of a robust-user-friendly INSTALL file
> 
>  4. A script to manage the database back-end while the
process of installation.
> 
>  5. A separate upgrade script.

David seems to have a good handle on how the current upgrade
scripts work, and I'm not sure if he's a fan of them, or
not, but I find them to be difficult -- one has to move back
and forth between "versions" of them to get the
upgrade done properly, and to me the method was completely
un-intuitive. A review/refactor of the method would be nice,
in my opinion.

>  6. Re-organizing the perl scripts in order to smoothen
the process of
>  installation
> 
>  Non-Code deliverables will include documentation for
all the scripts
>  and modules mentioned above.

POD++ 

Best of luck with this submission!

Regards,


>  ~~~~~~~~~~~~~~~
>  Project Details
>  ~~~~~~~~~~~~~~~
>  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 for the
developers too, which
>  should result in hassle free updation and
maintenance.
> 
>  The first part of the project involves the creation of
a 'OS-Specific'
>  configure file, which requires (for unix based
environments) 1.
>  autoconf, 2. libtool, 3. gettext, 4. m4; all of these
come along with
>  a standard version of unix based environments.
>  This configure script also checks for all the
dependencies; in case of
>  failure it readily echoes a verbose message to the
user, which may
>  also consist of the link to the right direction, also
by making it OS
>  specific it would point to the specifics of the
package needed for the
>  distribution.
> 
>  There may be an issue of an CPAN modules, which may be
resolved by
>  switching to CPAN++, which is presently being resolved
using cpan.pm,
>  there by incrementing the minimum requirement to perl
v-5.10.
> 
>  Creation of the INSTALL file, with certain options
thrown as default
>  and which can be changed by the user through the
command line.
> 
>  Creation of a database manager which is accessed while
the process of
>  installation is being processed. This database manager
manages the
>  back-end of the DB and also creates the databases.
> 
>  It is also a necessary that a separate upgrade script
be added, which,
>  helps in the process of up-gradation. This script can
be called from
>  the INSTALL script by passing a command line option
into INSTALL.
> 
>  Another most important part of the whole process is
optimization of
>  the whole code(which is utilized during the process of
installation)
>  which would surely decrease the noise. This would
further increase the
>  ease of maintenance of the whole installation
process.
> 
>  Suggestions are welcome!
>  ~~~~~~~~~~~~~~~~
>  Project Schedule
>  ~~~~~~~~~~~~~~~~
>  The project is planned to be split across 6 major
Phases:
> 
>  1. Analysis (May 26 - May 31)(I would be happy if I
could start early):
>  This phase involves interaction with the mentor and
the key people
>  involved in similar projects  in order to exactly
understand the
>  requirements.
> 
>  2. Development Part I (June 1 - June 15):
>  This phase will involve the creation of configure
file.
> 
>  3. Development Part II (June 16 - July 10):
>  This phase will involve the process of resolving CPAN
migration issues.
> 
>  4. Development Part III (July 11 - July 25):
>  Creation of the INSTALL file.
> 
>  5. Packaging (July 26 - August 5):
>  Creation of the minor modules => Database Manager
and Upgrade Manager.
> 
>  6. Testing and Wrap-Up (August 5 - August 21):
>  Thoroughly test every aspect of the finished package.
This phase will
>  also include the development of non-code
deliverables.
> 
>  ~~~
>  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 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/

>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 

Brad Harder,
Method Digital Logic
http://www.methodlogic.net

On Mar 28, 2008, at 19:21, bharder wrote:

>> 5. A separate upgrade script.
>
> David seems to have a good handle on how the current
upgrade scripts  
> work, and I'm not sure if he's a fan of them, or not,
but I find  
> them to be difficult -- one has to move back and forth
between  
> "versions" of them to get the upgrade done
properly, and to me the  
> method was completely un-intuitive. A review/refactor
of the method  
> would be nice, in my opinion.

The current upgrade system is pretty dated, and upgrade
scripts can be  
a bitch to write, but the underlying idea is pretty sound.
Rails  
migrations are not a whole lot different, to be honest, just
a lot  
more sugary.

But if you could talk more about your pains with it, it
would  
certainly help with the implementation of a new version.

Best,

David

On Fri, Mar 28, 2008 at 07:11:14PM -0700, David E. Wheeler
wrote:
> Hi PRANAV, thanks for taking the time to put this
together and submit  
> it to the list. I really appreciate your interest in
helping to make  
> Bricolage better!
> 
> On Mar 28, 2008, at 15:23, PRANAV wrote:
> 
> >~~~~~~~~~~~~~~~
> >   Pranava Swaroop S
> > pmadhyasthaacm.org
> >~~~~~~~~~~~~~~~
> >
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >REJUVENATING THE INSTALLER FOR BRICOLAGE
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >Greetings!
> >
> >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. This project will help resolve
most of the
> >installer based problems of Bricolage.
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >Benefits to the Bricolage Community
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >This project would simplify the whole process of
installation and
> >would gel beautifully to the afore mentioned quote.
This project will
> >also enhance the usage scope of Bricolage
considerably.
> >
> >~~~~~~~~~~~~
> >Deliverables
> >~~~~~~~~~~~~
> >1. Creation of an executable 'OS-Specific'
configure file.
> 
> Um, what? No configure please. Just a Perl build script
would be  
> great. Like you mention here:
> 
> >2. Creation of a perl script, replacing the
existing Makefile
> 
> This can then load OS-specific configuration
information from a file.  
> Is that what you meant? I would no be executable,
then.
> 
> >3. Creation of a robust-user-friendly INSTALL file
> 
> This is just documentation you're talking about, yes?
> 
> >4. A script to manage the database back-end while
the process of  
> >installation.
> >
> >5. A separate upgrade script.
> 
> These already exist. How would you change them?
> 
> >6. Re-organizing the perl scripts in order to
smoothen the process of
> >installation
> 
> How so?
> 
> >Non-Code deliverables will include documentation
for all the scripts
> >and modules mentioned above.
> 
> Excellent.
> 
> >~~~~~~~~~~~~~~~
> >Project Details
> >~~~~~~~~~~~~~~~
> >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 for the
developers too, which
> >should result in hassle free updation and
maintenance.
> 
> Yeah!
> 
> >The first part of the project involves the creation
of a 'OS-Specific'
> >configure file, which requires (for unix based
environments) 1.
> >autoconf, 2. libtool, 3. gettext, 4. m4; all of
these come along with
> >a standard version of unix based environments.
> 
> Say what? No no, I don't think we need any of that
stuff. There is a  
> Perl build toolchain that would fit much better, and
will run across  
> platforms. It consists of Module::Build and
Locale::Maketext. The  
> latter is already used by Bricolage for localization.
For library and  
> dependency detection, we can make use of App::Info. I'd
rather not get  
> into the Unix C build tool chain at all if we can avoid
it, partly  
> because I don't understand it at all (and I think that
few in this  
> community do), and partly because Bricolage is not an
application that  
> needs to be compiled. That is to say, the way its
installation works  
> is completely different than, say, the way PostgreSQL
or Apache  
> compiling and installation work.

$AboveComment++

This is purely shuffling files around, and it's not big
enough to warrant the auto* suite. Question, though, David
-- not everything includes Perl in it's base install --
would you consider using Makefiles (maintained by hand, like
the current Perl implementation), or just keep using Perl
and leave the responsibility of getting Perl on the machine
in question to the admin of that machine?

It's a question of how "pure" one wants to make
the install...

> >This configure script also checks for all the
dependencies; in case of
> >failure it readily echoes a verbose message to the
user, which may
> >also consist of the link to the right direction,
also by making it OS
> >specific it would point to the specifics of the
package needed for the
> >distribution.
> >
> >There may be an issue of an CPAN modules, which may
be resolved by
> >switching to CPAN++, which is presently being
resolved using cpan.pm,
> >there by incrementing the minimum requirement to
perl v-5.10.
> 
> We need to support 5.8.x for a while. Not that I'm
against this, mind  
> you, it just might be a year or so before it's a
reasonable thing to do.
> 
> >Creation of the INSTALL file, with certain options
thrown as default
> >and which can be changed by the user through the
command line.
> 
> Don't really follow you here.
> 
> >Creation of a database manager which is accessed
while the process of
> >installation is being processed. This database
manager manages the
> >back-end of the DB and also creates the databases.
> 
> What's to manage other than the creation of the
database?
> 
> >It is also a necessary that a separate upgrade
script be added, which,
> >helps in the process of up-gradation. This script
can be called from
> >the INSTALL script by passing a command line option
into INSTALL.
> 
> Yeah, not dissimilar to the way the current installer
works.
> 
> >Another most important part of the whole process is
optimization of
> >the whole code(which is utilized during the process
of installation)
> >which would surely decrease the noise. This would
further increase the
> >ease of maintenance of the whole installation
process.
> 
> Well, I have to admit that I'm not too concerned about
the performance  
> of the installer. It's more the quality of the code and
the way that  
> it's organized that's a problem. If the installer were
rewritten to be  
> highly modular and easy to hack on and/or expand, but
was slower, I  
> could not care less.
> 
> >Suggestions are welcome!
> >~~~~~~~~~~~~~~~~
> >Project Schedule
> >~~~~~~~~~~~~~~~~
> >The project is planned to be split across 6 major
Phases:
> >
> >1. Analysis (May 26 - May 31)(I would be happy if I
could start  
> >early):
> >This phase involves interaction with the mentor and
the key people
> >involved in similar projects  in order to exactly
understand the
> >requirements.
> 
> This is good, because based on the above, I think
you'll need to first  
> spend some time becoming familiar with the standard
Perl build chain,  
> and revise your plans around that.
> 
> >2. Development Part I (June 1 - June 15):
> >This phase will involve the creation of configure
file.
> >
> >3. Development Part II (June 16 - July 10):
> >This phase will involve the process of resolving
CPAN migration  
> >issues.
> 
> Any idea what this would involve?
> 
> >4. Development Part III (July 11 - July 25):
> >Creation of the INSTALL file.
> >
> >5. Packaging (July 26 - August 5):
> >Creation of the minor modules => Database
Manager and Upgrade Manager.
> >
> >6. Testing and Wrap-Up (August 5 - August 21):
> >Thoroughly test every aspect of the finished
package. This phase will
> >also include the development of non-code
deliverables.
> 
> The schedule looks okay, but as I say, your proposed
approach seems a  
> bit off the mark to me, in terms of meeting the needs
of this  
> community and its culture. It also needs a fair bit of
expanding,  
> which means, I think, that you need to play around a
bit with the  
> current installer to see how and why it's painful for
users. And I  
> mean before you submit your proposal to Google.
> 
> I don't mean to be too tough on you, but there are a
lot of gaps that  
> need filling in here, in your knowledge of Bricolage
and its current  
> installer, the Perl build chain, and the expectations
of Bricolage  
> users in general.
> 
> >~~~
> >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 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.
> 
> Nice. For an installer I wrote recently, BTW, I used my
own FSA::Rules  
> module to handle the decision tree. It worked quite
nicely, and was  
> fairly straight-forward to test.
> 
> >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!
> 
> Thank you for taking the time to put it together and
end it in. I look  
> forward to your next iteration!
> 
> Best,
> 
> David
> 

-- 

Brad Harder,
Method Digital Logic
http://www.methodlogic.net

On Fri, Mar 28, 2008 at 07:25:19PM -0700, David E. Wheeler
wrote:
> On Mar 28, 2008, at 19:21, bharder wrote:
> 
> >>5. A separate upgrade script.
> >
> >David seems to have a good handle on how the
current upgrade scripts  
> >work, and I'm not sure if he's a fan of them, or
not, but I find  
> >them to be difficult -- one has to move back and
forth between  
> >"versions" of them to get the upgrade
done properly, and to me the  
> >method was completely un-intuitive. A
review/refactor of the method  
> >would be nice, in my opinion.
> 
> The current upgrade system is pretty dated, and upgrade
scripts can be  
> a bitch to write, but the underlying idea is pretty
sound. Rails  
> migrations are not a whole lot different, to be honest,
just a lot  
> more sugary.
> 
> But if you could talk more about your pains with it, it
would  
> certainly help with the implementation of a new
version.

Well, it was some time ago (couple years?) -- and  I ran
into a hitch, and had to navigate the system and try to
resolve my "issue".

Forgive me, I don't completely understand the principles at
work with it, but if I had to describe it based on what I
_think_ happens

* It runs the upgrade scripts in order, except when it
doesn't.

There is some "doubling back" where "previous
versions" of scripts are re-run on the DB, where they
must check for state to do the proper work... I found it to
be confusing at the time.

> Best,
> 
> David

-- 

Brad Harder,
Method Digital Logic
http://www.methodlogic.net

On Mar 28, 2008, at 19:26, bharder wrote:

> $AboveComment++
>
> This is purely shuffling files around, and it's not big
enough to  
> warrant the auto* suite. Question, though, David -- not
everything  
> includes Perl in it's base install -- would you
consider using  
> Makefiles (maintained by hand, like the current Perl  
> implementation), or just keep using Perl and leave the 

> responsibility of getting Perl on the machine in
question to the  
> admin of that machine?

I can't think of a single distribution the Bricolage runs on
that  
doesn't ship with Perl, aside from Windows. I have no
problem  
requiring Perl before anything else happens. But I'd be okay
with a  
shell script or something that wrapped around the Perl
script, and  
hollered "install Perl before going further!" if
Perl wasn't installed.

Truly, Perl, PostgreSQL or MySQL, and Apache + mod_perl all
need to be  
installed before the installer can do anything.

Best,

David

On Mar 28, 2008, at 19:30, bharder wrote:

> Forgive me, I don't completely understand the
principles at work  
> with it, but if I had to describe it based on what I
_think_ happens
>
> * It runs the upgrade scripts in order, except when it
doesn't.
>
> There is some "doubling back" where
"previous versions" of scripts  
> are re-run on the DB, where they must check for state
to do the  
> proper work... I found it to be confusing at the time.

Sounds like a bug, really.

Best,

David

On Fri, Mar 28, 2008 at 07:34:35PM -0700, David E. Wheeler
wrote:
> On Mar 28, 2008, at 19:26, bharder wrote:
> 
> >$AboveComment++
> >
> >This is purely shuffling files around, and it's not
big enough to  
> >warrant the auto* suite. Question, though, David --
not everything  
> >includes Perl in it's base install -- would you
consider using  
> >Makefiles (maintained by hand, like the current
Perl  
> >implementation), or just keep using Perl and leave
the  
> >responsibility of getting Perl on the machine in
question to the  
> >admin of that machine?
> 
> I can't think of a single distribution the Bricolage
runs on that  
> doesn't ship with Perl, aside from Windows. I have no
problem  

*BSD -- ship perl as packages, not in base install.

> requiring Perl before anything else happens. But I'd be
okay with a  
> shell script or something that wrapped around the Perl
script, and  
> hollered "install Perl before going further!"
if Perl wasn't installed.
> 
> Truly, Perl, PostgreSQL or MySQL, and Apache + mod_perl
all need to be  
> installed before the installer can do anything.

This could be a chance for an OS-sensing script to say: OK,
we're running "apt-get update; apt-get install
perl", or "pkg_add
ftp://www.freebsd.org/blahblahlbah/perl.tgz" -- I'm
being a bit of a devils advocate here, and not sure if we
even want to go down this path for a GSoC project, though.

> Best,
> 
> David
> 

-- 

Brad Harder,
Method Digital Logic
http://www.methodlogic.net