Re: Proposals for Sub Packages
| From: | Pierre | Date: | Thu, 23 Mar 2006 15:47:23 +0000 |
| Subject: | Re: Proposals for Sub Packages | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-41954@lists.php.net to get a copy of this message | ||
On Thu, 23 Mar 2006 09:30:13 -0500
scott@crisscott.com (Scott Mattocks) wrote:
> Hello,
>
> I just proposed Structures_Form which is a base form management class.
> This class requires a front end but the front end is not included in
> the package to make the package more light weight and flexible.
> Instead the front end should be installed as a sub package such as
> Structures_Form_Gtk2 or Structures_Form_CLI. Should the front end
> packages be proposed separately or are they considered part of the
> main package?
It is really up to you. For example, Validate introduces many sub
packages (locales, activities,...) without going through the proposal
phases. In the early days of Validate, we had one big package, to ease
the maintenance we splited them (like MDB2 did as well).
> For example, I created two proposals for PEAR_PackageUpdate. One for
> the base code and another for the PHP-GTK 2 front end. But recently
> there was a thread about Validate saying that Validate sub packages
> are added at the Validate maintainers discretion.
>
> I like the two proposal system because it draws attention to the fact
> that the packages are separate and everything gets more review, but
> what happens if the front end is not accepted but the back end is?
You can always ask review through the pear-dev list. This is how things
work for existing package.
Regards,
--Pierre