Re: Proposals for Sub Packages

From: 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

« previous php.pear.dev (#41954) next »