[development] Update.php re-design

[Nabil Alsharif]

Great. This is going to be my first contribution to drupal and I don't
know what the process for submitting such changes is. Do I open an issue
and attach patches? Or do I have to sign up for a cvs account and commit
via cvs? 

Would it be better to submit (patches or commit) partial but working
changes, or should I wait until it's all done and then submit one big
change?

On Mon, 2009-03-02 at 10:22 -0500, Moshe Weitzman wrote:
> This makes sense, and I encourage you and others to proceed. There is
> no good reason it has not been done so far.
> 
> On Mon, Mar 2, 2009 at 10:24 AM, Nabil Alsharif <nabil at gobrighttree.com> wrote:
> > There seems to be a couple of projects that are trying to make
> > update.php command line friendly, non of which seem to be going that
> > well:
> > http://drupal.org/node/194107
> > http://acquia.com/blog/drupal-cli-utils
> >
> > The issue that I see is that update.php is tightly coupled with the UI.
> > What I would like to do is pull the functions that preform the updates
> > out of update.php so that it would be possible to have a different UIs
> > to modules (Web interface, cli). There are two main reasons I would like
> > to do this:
> > 1. It would make the projects mentioned above much easier to implement.
> > 2. The projects mentioned above have there own implementation of
> > update.php that is independent of that way drupal updates the modules.
> >
> > I hope to endup with something along the lines of update.inc that holds
> > the function for preforming the updates (i.e get_updates, do_update,
> > db_add_column.. etc) and update.php that has the current UI for
> > updates.
> >
> > Is there any reason that this hasn't been done before? More importantly
> > does any one have any good reason to not separate preforming the updates
> > from the UI?
> >
> > --
> > ----------------------------------
> > Nabil Alsharif
> > Bright Tree
> > 573-499-1244
> >
> > This message is for the designated recipient only and may contain
> > privileged, proprietary, or otherwise private information. If you have
> > received it in error, please notify the sender immediately and delete
> > the original. Any other use of the email by you is prohibited. Please
> > consider the environment before printing this email or its
> > attachment(s).
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.drupal.org/pipermail/development/attachments/20090302/53a46be5/attachment.pgp