[Vtigercrm-developers] adodb (deprecate PEAR), themed source cleanup bug days

[Jeff Kowalczyk]

Richie wrote:
> how do you propose we handle these separate operations at the svn level.
> Do we need to create separate branches?
>
> I visualize something like this:
> Pple form teams and work on independent features. Each team has a
> lead/point of contact.
> We merge these features at some point into the main trunk.

This is the right approach for feature branches and refactoring branches.

However, I think we're finding that the formatting of the vtigercrm source
is not currently conducive to branching and merging. The trouble is all
the long source lines, particularly in SQL query strings.

Merging is a complex topic that I don't really understand on a
computer-science level, but the practical lesson I've taken has been that
formatting source vertically, with more and shorter source lines, always
makes for better automatic merging.

If there's room in people's individual and the release schedules, and if
there's consensus to do a few days of slogging, a bug day or series of bug
days with some 'themes' such as:

- Format SQL statements according to Wiki conventions

- Format PHP source with some source beautification tool, or at least with
some simple guidelines such as max 80 character lines wherever possible.

- Finalize table-prefix strategy (maybe adodb managed configurable?)

- PEAR deprecation and ADODB use by convention (quoting, etc)

The motiviation for having themed bug day(s) is that these changes make a
temporary mess of the source, have an inevitable consequence of small
easily fixed syntax bugs, and create a 'merge boundary' across which diffs
are useless.

To mitigate this pain, it's better to get it over in a short time, when
everyone is focused on the same tedious objective.

If there's community enthusiasm for polishing up the source like this,
there would be ongoing benefits for the duration of vtigercrm's
development.

We could publish a few wiki pages so everyone knows what to do, and post
announcements indicating that for the next N days, nobody work on anything
except this cleanup theme.

We should get as many of the new faces authorized with svn commit access
before hosting a bug day. Enough helping hands may allow the 4.2 branch to
be beautified at the same time, if that were deemed wise.

It will all be worthwhile when we can finally work efficiently with
feature, refactoring and maintenance branches, like a project of this size
should.