[gentoo-dev] RFC: remove php4 from depend.php and others

[gentoo-dev] RFC: remove php4 from depend.php and others

[Matti Bickel]

[-- Attachment #1.1: Type: text/plain, Size: 397 bytes --]

Hi,

yet another patch from Ole in a bid to rid the php eclasses from some
long forgotten code. The patches should be self-explanatory - just rip
out everything related to dev-php4 :)

Comments welcome.

All the work will go into our overlay (slotting branch:
http://git.overlays.gentoo.org/gitweb/?p=proj/php.git;a=tree;h=refs/heads/slotting;hb=slotting)
before migration to the tree.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 02_remov_php4_from_depend.php.patch --]
[-- Type: text/x-patch; name="02_remov_php4_from_depend.php.patch", Size: 4081 bytes --]

diff --git a/eclass/depend.php.eclass b/eclass/depend.php.eclass
index 681e6dd..c194449 100644
--- a/eclass/depend.php.eclass
+++ b/eclass/depend.php.eclass
@@ -18,57 +18,6 @@
 
 inherit eutils phpconfutils
 
-# PHP4-only depend functions
-
-# @FUNCTION: need_php4_cli
-# @DESCRIPTION:
-# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
-# with cli SAPI.
-need_php4_cli() {
-	DEPEND="${DEPEND} =dev-lang/php-4*[cli]"
-	RDEPEND="${RDEPEND} =dev-lang//php-4*[cli]"
-	PHP_VERSION="4"
-}
-
-# @FUNCTION: need_php4_httpd
-# @DESCRIPTION:
-# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
-# with either cgi or apache2 SAPI.
-need_php4_httpd() {
-	DEPEND="${DEPEND} =virtual/httpd-php-4*"
-	RDEPEND="${RDEPEND} =virtual/httpd-php-4*"
-	PHP_VERSION="4"
-}
-
-# @FUNCTION: need_php4
-# @DESCRIPTION:
-# Set this after setting DEPEND/RDEPEND in your ebuild if the ebuild requires PHP4
-# (with any SAPI).
-need_php4() {
-	DEPEND="${DEPEND} =dev-lang/php-4*"
-	RDEPEND="${RDEPEND} =dev-lang/php-4*"
-	PHP_VERSION="4"
-	PHP_SHARED_CAT="php4"
-}
-
-# common settings go in here
-uses_php4() {
-	# cache this
-	libdir=$(get_libdir)
-
-	PHPIZE="/usr/${libdir}/php4/bin/phpize"
-	PHPCONFIG="/usr/${libdir}/php4/bin/php-config"
-	PHPCLI="/usr/${libdir}/php4/bin/php"
-	PHPCGI="/usr/${libdir}/php4/bin/php-cgi"
-	PHP_PKG="$(best_version =dev-lang/php-4*)"
-	PHPPREFIX="/usr/${libdir}/php4"
-	EXT_DIR="$(${PHPCONFIG} --extension-dir 2>/dev/null)"
-
-	einfo
-	einfo "Using ${PHP_PKG}"
-	einfo
-}
-
 # PHP5-only depend functions
 
 # @FUNCTION: need_php5_cli
@@ -158,7 +107,6 @@ need_php() {
 need_php_by_category() {
 	case "${CATEGORY}" in
 		dev-php) need_php ;;
-		dev-php4) need_php4 ;;
 		dev-php5) need_php5 ;;
 		*) die "Version of PHP required by packages in category ${CATEGORY} unknown"
 	esac
@@ -174,8 +122,6 @@ has_php() {
 	# Detect which PHP version we have installed
 	if has_version '=dev-lang/php-5*' ; then
 		PHP_VERSION="5"
-	elif has_version '=dev-lang/php-4*' ; then
-		PHP_VERSION="4"
 	else
 		die "Unable to find an installed dev-lang/php package"
 	fi
@@ -396,17 +342,6 @@ has_concurrentmodphp() {
 require_pdo() {
 	has_php
 
-	# Do we have PHP5 installed?
-	if [[ "${PHP_VERSION}" == "4" ]] ; then
-		eerror
-		eerror "This package requires PDO."
-		eerror "PDO is only available for PHP 5."
-		eerror "You must install >=dev-lang/php-5.1 with USE=\"pdo\"."
-		eerror "pdo USE flags turned on."
-		eerror
-		die "PHP 5 not installed"
-	fi
-
 	# Was PHP5 compiled with internal PDO support?
 	if built_with_use =${PHP_PKG} pdo || phpconfutils_built_with_use =${PHP_PKG} pdo ; then
 		return
@@ -436,15 +371,6 @@ require_php_cli() {
 
 	local PHP_PACKAGE_FOUND=""
 
-	# Detect which PHP version we have installed
-	if has_version '=dev-lang/php-4*' ; then
-		PHP_PACKAGE_FOUND="1"
-		pkg="$(best_version '=dev-lang/php-4*')"
-		if built_with_use =${pkg} cli || phpconfutils_built_with_use =${pkg} cli ; then
-			PHP_VERSION="4"
-		fi
-	fi
-
 	if has_version '=dev-lang/php-5*' ; then
 		PHP_PACKAGE_FOUND="1"
 		pkg="$(best_version '=dev-lang/php-5*')"
@@ -480,15 +406,6 @@ require_php_cgi() {
 
 	local PHP_PACKAGE_FOUND=""
 
-	# Detect which PHP version we have installed
-	if has_version '=dev-lang/php-4*' ; then
-		PHP_PACKAGE_FOUND="1"
-		pkg="$(best_version '=dev-lang/php-4*')"
-		if built_with_use =${pkg} cgi || phpconfutils_built_with_use =${pkg} cgi ; then
-			PHP_VERSION="4"
-		fi
-	fi
-
 	if has_version '=dev-lang/php-5*' ; then
 		PHP_PACKAGE_FOUND="1"
 		pkg="$(best_version '=dev-lang/php-5*')"
@@ -522,13 +439,6 @@ require_sqlite() {
 		return
 	fi
 
-	# Do we have pecl-sqlite installed for PHP4?
-	if [[ "${PHP_VERSION}" == "4" ]] ; then
-		if has_version 'dev-php4/pecl-sqlite' ; then
-			return
-		fi
-	fi
-
 	# If we get here, then we don't have any SQLite support for PHP installed
 	eerror
 	eerror "No SQLite extension for PHP found."

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: 03_removed_all_traces_of_php4.patch --]
[-- Type: text/x-patch; name="03_removed_all_traces_of_php4.patch", Size: 1532 bytes --]

diff --git a/eclass/php-pear-lib-r1.eclass b/eclass/php-pear-lib-r1.eclass
index 5c58dce..f5fdd7f 100644
--- a/eclass/php-pear-lib-r1.eclass
+++ b/eclass/php-pear-lib-r1.eclass
@@ -33,17 +33,7 @@ php-pear-lib-r1_src_install() {
 	addpredict /var/lib/net-snmp/
 	addpredict /session_mm_cli0.sem
 
-	case "${CATEGORY}" in
-		dev-php)
-			if has_version '=dev-lang/php-5*' ; then
-				PHP_BIN="/usr/$(get_libdir)/php5/bin/php"
-			else
-				PHP_BIN="/usr/$(get_libdir)/php4/bin/php"
-			fi ;;
-		dev-php4) PHP_BIN="/usr/$(get_libdir)/php4/bin/php" ;;
-		dev-php5) PHP_BIN="/usr/$(get_libdir)/php5/bin/php" ;;
-		*) die "Version of PHP required by packages in category ${CATEGORY} unknown"
-	esac
+	PHP_BIN="/usr/$(get_libdir)/php5/bin/php"
 
 	cd "${S}"
 
diff --git a/eclass/php-pear-r1.eclass b/eclass/php-pear-r1.eclass
index f1b1c55..d1bb86f 100644
--- a/eclass/php-pear-r1.eclass
+++ b/eclass/php-pear-r1.eclass
@@ -60,17 +60,7 @@ php-pear-r1_src_install() {
 	addpredict /var/lib/net-snmp/
 	addpredict /session_mm_cli0.sem
 
-	case "${CATEGORY}" in
-		dev-php)
-			if has_version '=dev-lang/php-5*' ; then
-				PHP_BIN="/usr/$(get_libdir)/php5/bin/php"
-			else
-				PHP_BIN="/usr/$(get_libdir)/php4/bin/php"
-			fi ;;
-		dev-php4) PHP_BIN="/usr/$(get_libdir)/php4/bin/php" ;;
-		dev-php5) PHP_BIN="/usr/$(get_libdir)/php5/bin/php" ;;
-		*) die "Version of PHP required by packages in category ${CATEGORY} unknown"
-	esac
+	PHP_BIN="/usr/$(get_libdir)/php5/bin/php"
 
 	cd "${S}"
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] RFC: remove php4 from depend.php and others

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On 07/10/2010 01:22 AM, Matti Bickel wrote:
> Hi,
> 
> yet another patch from Ole in a bid to rid the php eclasses from some
> long forgotten code. The patches should be self-explanatory - just rip
> out everything related to dev-php4 :)
> 
> Comments welcome.
> 

The standing policy is still not to remove any public functionality from
eclasses. If we decide to start removing functionality the council
should set common rules for it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] RFC: remove php4 from depend.php and others

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
> On 07/10/2010 01:22 AM, Matti Bickel wrote:
> > Hi,
> > 
> > yet another patch from Ole in a bid to rid the php eclasses from some
> > long forgotten code. The patches should be self-explanatory - just rip
> > out everything related to dev-php4 :)
> > 
> > Comments welcome.
> > 
> 
> The standing policy is still not to remove any public functionality from
> eclasses. If we decide to start removing functionality the council
> should set common rules for it.

Just adding a note on this one- the original technical reason for 
this policy (portage inability to run from just the saved env dump) 
is no longer an issue.

If people want to allow eclasses to have fluid APIs (specifically 
removal of functionality), that's a discussion that needs to start on 
the dev level.

Anyone got strong opinions on this one?
~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Allow eclasses to have fluid APIs (was: [gentoo-dev] RFC: remove php4 from depend.php and others)

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On 07/10/2010 10:34 AM, Brian Harring wrote:
> If people want to allow eclasses to have fluid APIs (specifically 
> removal of functionality), that's a discussion that needs to start on 
> the dev level.
> 
> Anyone got strong opinions on this one?

The argument was presented a long time before: we can't care about
things not in our tree, there might be thousands of twisted ways our
eclasses are used we can't control. If nothing is broken in gentoo-x86,
we as developers should be allowed to make the change. To ensure the
change is indeed not breaking stuff, RFCs to -dev are a requirement.

Everybody who copied and re-used our eclasses should be reading -dev (or
at least -dev-announce), anyway. Not our fault if they run an open
system (as in, I've not nailed all my versions down and use a static
tree) and do not keep up with it.

Now, I'm aware that RFC and implementation periods should depend on the
impact of the change - if I'm proposing to alter eutils, I better wait
some time AFTER a conclusion has been reached, so everybody can adapt.

That 'should' above is intentional - prescribing a fixed time period for
every possible change does not give devs enough flexibility and
implementation time may be a subject during RFC anyway. To continue the
eutils example: if I keep a custom overlay which depends on the removed
functionality, I will speak up and ask you defer the change 14 days so I
can fix my overlay.

Similarly, if somebody still uses the php4 bits in depend.php eclass,
please speak up and allow me to convince you of the php5 ways :-)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]

On Sat, 10 Jul 2010 01:34:37 -0700
Brian Harring <ferringb@gmail.com> wrote:

> On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
> > The standing policy is still not to remove any public functionality from
> > eclasses. If we decide to start removing functionality the council
> > should set common rules for it.
> 
> Just adding a note on this one- the original technical reason for 
> this policy (portage inability to run from just the saved env dump) 
> is no longer an issue.
> 
> If people want to allow eclasses to have fluid APIs (specifically 
> removal of functionality), that's a discussion that needs to start on 
> the dev level.
> 
> Anyone got strong opinions on this one?

I don't believe there ever was such a policy, except for pkg_{pre,post}rm
because of the mentioned technical limitations (which were fixed in portage
2-3 years ago now).  If there is such a policy then I've violated it on
several occasions :).  In fact, isn't the generally accepted method of
deprecating an eclass to remove all functionality and replace it with a
message in global scope and a "# @DEAD" tag?

I don't see the advantage of keeping unmaintained broken code no one should
use around in eclasses.  You can argue that removing eclass functionality can
potentially break ebuilds in overlays, but if you follow that line of
reasoning then really we should never remove any package from the tree
because it may be a dependency of something, somewhere.

So I'd like to see a policy that treats public functions in eclasses the same
as the last rites policies for package removal:  minimum 30 day deprecation
period, mail to dev-announce, etc.


-- 
fonts, gcc-porting,                                   and it's all by design
toolchain, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Doug Goldstein]

On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Sat, 10 Jul 2010 01:34:37 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>
>> On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
>> > The standing policy is still not to remove any public functionality from
>> > eclasses. If we decide to start removing functionality the council
>> > should set common rules for it.
>>
>> Just adding a note on this one- the original technical reason for
>> this policy (portage inability to run from just the saved env dump)
>> is no longer an issue.
>>
>> If people want to allow eclasses to have fluid APIs (specifically
>> removal of functionality), that's a discussion that needs to start on
>> the dev level.
>>
>> Anyone got strong opinions on this one?
>
> I don't believe there ever was such a policy, except for pkg_{pre,post}rm
> because of the mentioned technical limitations (which were fixed in portage
> 2-3 years ago now).  If there is such a policy then I've violated it on
> several occasions :).  In fact, isn't the generally accepted method of
> deprecating an eclass to remove all functionality and replace it with a
> message in global scope and a "# @DEAD" tag?
>
> I don't see the advantage of keeping unmaintained broken code no one should
> use around in eclasses.  You can argue that removing eclass functionality can
> potentially break ebuilds in overlays, but if you follow that line of
> reasoning then really we should never remove any package from the tree
> because it may be a dependency of something, somewhere.
>
> So I'd like to see a policy that treats public functions in eclasses the same
> as the last rites policies for package removal:  minimum 30 day deprecation
> period, mail to dev-announce, etc.
>
>
> --
> fonts, gcc-porting,                                   and it's all by design
> toolchain, wxwidgets                        to keep us from losing our minds
> @ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
>

To be honest, the MythTV eclasses have been an ever evolving set of
eclasses for ages now. Ever since it was declared that its now safe to
remove eclasses from the tree since Portage saves eclasses and its
env, therefore it wouldn't cause a problem.

If I really need to go to the council with every change, considering
it must be debated on the ML for at least X number of days prior to
going to the council, I'd more likely just remove MythTV from the tree
and maintain it in an overlay. I don't invest a lot of time in the
MythTV ebuilds, but they work for a large majority of people. And when
a new version comes out it requires some retooling and it just works
for everyone.

So basically, you guys decide.. am I pulling them out of the tree or
am I leaving them in?

-- 
Doug Goldstein

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

On 07/11/2010 08:02 AM, Doug Goldstein wrote:

> If I really need to go to the council with every change, considering
> it must be debated on the ML for at least X number of days prior to
> going to the council, I'd more likely just remove MythTV from the tree
> and maintain it in an overlay. I don't invest a lot of time in the
> MythTV ebuilds, but they work for a large majority of people. And when
> a new version comes out it requires some retooling and it just works
> for everyone.
> 

When someone proposes this I'll let you know. What's under discussion is
allowing removals to the public API of eclasses by following a
documented process (that doesn't involve council approval).

> So basically, you guys decide.. am I pulling them out of the tree or
> am I leaving them in?
> 

If you decided to drop maintenance of MythTV in main tree, wouldn't it
be a better service to users to try and find a new maintainer (who would
possibly merge stuff from your overlay)?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Doug Goldstein]

On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 07/11/2010 08:02 AM, Doug Goldstein wrote:
>
>> If I really need to go to the council with every change, considering
>> it must be debated on the ML for at least X number of days prior to
>> going to the council, I'd more likely just remove MythTV from the tree
>> and maintain it in an overlay. I don't invest a lot of time in the
>> MythTV ebuilds, but they work for a large majority of people. And when
>> a new version comes out it requires some retooling and it just works
>> for everyone.
>>
>
> When someone proposes this I'll let you know. What's under discussion is
> allowing removals to the public API of eclasses by following a
> documented process (that doesn't involve council approval).
>
>> So basically, you guys decide.. am I pulling them out of the tree or
>> am I leaving them in?
>>
>
> If you decided to drop maintenance of MythTV in main tree, wouldn't it
> be a better service to users to try and find a new maintainer (who would
> possibly merge stuff from your overlay)?
>
> Regards,
> Petteri
>
>

Simply put, the council's purpose is not to say "oh we have to stop
development and have a 4 week debate about everything minor". The
council's purpose is to help decide between different technical
solutions and encourage people to move forward on one unified path.
The council's purpose is not to HINDER development as your responses
clearly suggest you would like to hinder eclass development but
instead to promote positive development.

Someone along the years the council lost its way and has felt that it
needs to stick its fingers into places that it really doesn't belong.
Its really become like the upper management at a large company that
slows its developers down, instead of helping make them more
efficient.

-- 
Doug Goldstein

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Doug.

On 11-07-2010 16:03, Doug Goldstein wrote:
> On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
>> On 07/11/2010 08:02 AM, Doug Goldstein wrote:
>>
>>> If I really need to go to the council with every change, considering
>>> it must be debated on the ML for at least X number of days prior to
>>> going to the council, I'd more likely just remove MythTV from the tree
>>> and maintain it in an overlay. I don't invest a lot of time in the
>>> MythTV ebuilds, but they work for a large majority of people. And when
>>> a new version comes out it requires some retooling and it just works
>>> for everyone.
>>>
>>
>> When someone proposes this I'll let you know. What's under discussion is
>> allowing removals to the public API of eclasses by following a
>> documented process (that doesn't involve council approval).
>>
>>> So basically, you guys decide.. am I pulling them out of the tree or
>>> am I leaving them in?
>>>
>>
>> If you decided to drop maintenance of MythTV in main tree, wouldn't it
>> be a better service to users to try and find a new maintainer (who would
>> possibly merge stuff from your overlay)?
>>
>> Regards,
>> Petteri
>>
>>
> 
> Simply put, the council's purpose is not to say "oh we have to stop
> development and have a 4 week debate about everything minor". The
> council's purpose is to help decide between different technical
> solutions and encourage people to move forward on one unified path.
> The council's purpose is not to HINDER development as your responses
> clearly suggest you would like to hinder eclass development but
> instead to promote positive development.

There seems to be some misunderstanding going on as we (Gentoo) haven't
approved (in prior councils terms or in the current one which hopes to
have its first meeting in the coming week or the following) any rules
about eclass changes having to be discussed or approved by the council.

> Someone along the years the council lost its way and has felt that it
> needs to stick its fingers into places that it really doesn't belong.
> Its really become like the upper management at a large company that
> slows its developers down, instead of helping make them more
> efficient.

About the issue in discussion, Petteri was recalling that contrary to
what anyone new to Gentoo might conclude from the current discussion,
the issue of eclass deprecation has been subject to at least 2 separate
discussions in the past 2 or 3 years and that in the last round there
was a proposal for setting minimal deprecation time frames.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMOfNWAAoJEC8ZTXQF1qEPsuQP/ApDmnJ8hNybSBzSOack2HIu
0IpIPgRV43s6SGLQuZH8sh2Svuzxlx7nMEb5/i+NkFrqnBp0p843onQorN2iO0a4
95k6CE23GRIaJKaOuNduAhI6Okme6/dVAaDhHzXRCwke+Sbbeohn8gnvZyu/fb3/
M/YTCXsz9Iur6ucs3pGNbE5aakJMwM6Su/h6QB4FjA+J0D9K9oHLf6aC70CKyH+e
Tw71UnGsb84lvd7kGsbRNn+RNEkRjvGQNA87y8Pau/q8YEmzH660zyg6tiMwLRnq
B1DaHYisVI6v9WAV7pRj6uAHYe52raeAZvFg025JNyo25tRbLpL9x+65lRF+yVVk
kc93rCMZsfgCsZoNWDK2QZWSrqYLTUHdbin66eNzxciqWBfoK3plBMp+CDg9iJb3
dSKBz2Ixsv5GWm6IcZM9wEzX34Wk+SJlj4ZPiD8iHOFT1kU4G3FmOcrI00ijXM/p
dAPMfz82uWFlaRwOMrfMJzq2Uy8SvU+8s68D7LKFUQP2e0xPsbBi6WF9lDPXys80
x073GzXDq+MfyQYxn1VLRwXHAhJNKbyGvy0Unm8scKr3+HzTZY8+G4Uvt/OAfg+4
YLorgdiRsGm4ecr4Y2DCydMk6TumS/915lmtePmNDdZ+s2lVTGem2cKVc8EJI42z
91KjRH4dYEj968oOenST
=G61A
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On 07/11/2010 07:37 PM, Jorge Manuel B. S. Vicetto wrote:

> 
>> Simply put, the council's purpose is not to say "oh we have to stop
>> development and have a 4 week debate about everything minor". The
>> council's purpose is to help decide between different technical
>> solutions and encourage people to move forward on one unified path.
>> The council's purpose is not to HINDER development as your responses
>> clearly suggest you would like to hinder eclass development but
>> instead to promote positive development.
> 

Original rules (as they were when I joined 2005):

You are only allowed to add to the public API of an eclass.

Eclass removal addition:

Since then council has approved the ability to fully remove eclasses:
http://www.gentoo.org/proj/en/council/meeting-logs/20090528-summary.txt

Under discussion:

Extend the rules to allow developers to remove functions from the API of
an eclass. To me this seem exactly like: "The council's purpose is to
help decide between different technical solutions and encourage people
to move forward on one unified path."

> 
> About the issue in discussion, Petteri was recalling that contrary to
> what anyone new to Gentoo might conclude from the current discussion,
> the issue of eclass deprecation has been subject to at least 2 separate
> discussions in the past 2 or 3 years and that in the last round there
> was a proposal for setting minimal deprecation time frames.
> 

There's already an approved process for eclass removal (see link above).
If we allow removal of functions I think there should a similar set of
rules as for eclass and package removal.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Sun, Jul 11, 2010 at 07:47:24PM +0300, Petteri RRRty wrote:
> On 07/11/2010 07:37 PM, Jorge Manuel B. S. Vicetto wrote:
> 
> > 
> >> Simply put, the council's purpose is not to say "oh we have to stop
> >> development and have a 4 week debate about everything minor". The
> >> council's purpose is to help decide between different technical
> >> solutions and encourage people to move forward on one unified path.
> >> The council's purpose is not to HINDER development as your responses
> >> clearly suggest you would like to hinder eclass development but
> >> instead to promote positive development.
> > 
> 
> Original rules (as they were when I joined 2005):
> 
> You are only allowed to add to the public API of an eclass.
> 
> Eclass removal addition:
> 
> Since then council has approved the ability to fully remove eclasses:
> http://www.gentoo.org/proj/en/council/meeting-logs/20090528-summary.txt
> 
> Under discussion:
> 
> Extend the rules to allow developers to remove functions from the API of
> an eclass. To me this seem exactly like: "The council's purpose is to
> help decide between different technical solutions and encourage people
> to move forward on one unified path."

From my stance, I firmly believe the council doesn't really need to be 
involved here.  This is QA's domain- specifically to decide tree 
policy.

The only question here is essentially "at what point do we stop 
caring about older portage versions".  portage 2.1.4.4 went stable 
(carrying that support) 06/01/08.  Frankly I'd argue the council's 
original decision while bound to eclasses, should've been bound to the 
2.1.4.4 release- specifically "you can't remove eclasses/functionality 
until 2 years after 2.1.4.4".

So... I firmly view this as QA's domain (they set the rules for most 
other tree policies).  Leave it to them to decide.  I realize from 
the standpoint of following the rules, this will require the council 
to state "yeah, we're backing out of this, it's now QA's domain", but 
this is my view on what should be done.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Doug Goldstein]

On Sun, Jul 11, 2010 at 11:37 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Doug.
>
> On 11-07-2010 16:03, Doug Goldstein wrote:
>> On Sun, Jul 11, 2010 at 7:49 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
>>> On 07/11/2010 08:02 AM, Doug Goldstein wrote:
>>>
>>>> If I really need to go to the council with every change, considering
>>>> it must be debated on the ML for at least X number of days prior to
>>>> going to the council, I'd more likely just remove MythTV from the tree
>>>> and maintain it in an overlay. I don't invest a lot of time in the
>>>> MythTV ebuilds, but they work for a large majority of people. And when
>>>> a new version comes out it requires some retooling and it just works
>>>> for everyone.
>>>>
>>>
>>> When someone proposes this I'll let you know. What's under discussion is
>>> allowing removals to the public API of eclasses by following a
>>> documented process (that doesn't involve council approval).
>>>
>>>> So basically, you guys decide.. am I pulling them out of the tree or
>>>> am I leaving them in?
>>>>
>>>
>>> If you decided to drop maintenance of MythTV in main tree, wouldn't it
>>> be a better service to users to try and find a new maintainer (who would
>>> possibly merge stuff from your overlay)?
>>>
>>> Regards,
>>> Petteri
>>>
>>>
>>
>> Simply put, the council's purpose is not to say "oh we have to stop
>> development and have a 4 week debate about everything minor". The
>> council's purpose is to help decide between different technical
>> solutions and encourage people to move forward on one unified path.
>> The council's purpose is not to HINDER development as your responses
>> clearly suggest you would like to hinder eclass development but
>> instead to promote positive development.
>
> There seems to be some misunderstanding going on as we (Gentoo) haven't
> approved (in prior councils terms or in the current one which hopes to
> have its first meeting in the coming week or the following) any rules
> about eclass changes having to be discussed or approved by the council.
>
>> Someone along the years the council lost its way and has felt that it
>> needs to stick its fingers into places that it really doesn't belong.
>> Its really become like the upper management at a large company that
>> slows its developers down, instead of helping make them more
>> efficient.
>
> About the issue in discussion, Petteri was recalling that contrary to
> what anyone new to Gentoo might conclude from the current discussion,
> the issue of eclass deprecation has been subject to at least 2 separate
> discussions in the past 2 or 3 years and that in the last round there
> was a proposal for setting minimal deprecation time frames.
>
> - --
> Regards,
>
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / KDE / Elections

Jorge,

I remember very clearly as you and I were both council members at the
time. My point is that this discussion does not need to even happen
and the council shouldn't even remotely be involved here.

Let developers develop.

-- 
Doug Goldstein

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-07-2010 21:56, Doug Goldstein wrote:
> On Sun, Jul 11, 2010 at 11:37 AM, Jorge Manuel B. S. Vicetto
> <jmbsvicetto@gentoo.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Doug.
>>
> Jorge,
> 
> I remember very clearly as you and I were both council members at the
> time. My point is that this discussion does not need to even happen
> and the council shouldn't even remotely be involved here.

Doug,

you probably mean you and Petteri were council members. I'm serving my
first term as a council member.
I read Petteri's comment as a developer comment. At most, as the lead
recruiter for a few years now. I didn't read it as coming from a council
member.

> Let developers develop.

No arguing from me about it.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMOlh8AAoJEC8ZTXQF1qEPFwEP/0YveY/B/uoPHdT8339zD8t2
Wnbu8q0qleKx7H4Kq+Dnovay4OwrUl6YVAnyKuNtf/1Ls/QZ3tpCPfPo3lJ1nZIw
eXB89Ph1+n5mvd2L8MVylcKtgyqLKSicfpY7yTFNPNtZm11RXp6O8Qg6sS34veA+
ublbzXbI45goKpmEzuqAcM/8xzKddy0ejdPEssql97CePioGF+AtBDafSSdgQJBK
8FCqRidSyQwRYE337xEmR6QUm2E+8dB9moaxSs4P1Q/+JR9yLknj1J01h9cVZs5o
m0oV7MDWDi7u7qupPh2e8IwRGpUpNiSyZ+WDLrB4DS/eMLherkwwBPzXjFJu6NAA
+d3VIYKVorSaESZQlO3+5YoxwE/hF5VmBVbwS73YLQtn+igzEpVVTtKA6I6uJpMc
lXx1jS/OnSfj6/hsd7XzJVoqsGIPCmvrQHGXBZ6Sgb4ISyV4bguU0hrrBegmKBPS
h0Yuy9STc0z/RpQ9oFi+Sd83RTSde5bhHzMwP+9wJIDR1lC22xmybKdf9CRtPgdi
/QxqsdaDdSl/E4vuGNZ4suo0KpklwRgkUjzeUOMEPDeDzFP6DvwKNxZzptjPDKmA
vLXos9pIUd712iWX9i6ESTr/0ctKS1aUB+Uc22gRsD40igU3hCHVIAO/GaU1DsJh
8Xm0ewkaOqVK3N30MHSX
=u13q
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On 07/12/2010 12:56 AM, Doug Goldstein wrote:

> I remember very clearly as you and I were both council members at the
> time. My point is that this discussion does not need to even happen
> and the council shouldn't even remotely be involved here.
> 

I assumed the best way to change policy would be to ask council to rule
on it. Of course we could just see if we can get a consensus fast
without council.

>
> Let developers develop.
> 

So instead of making current rules better just screw them?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others

[Doug Goldstein]

On Mon, Jul 12, 2010 at 3:54 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> On 07/12/2010 12:56 AM, Doug Goldstein wrote:
>
>> I remember very clearly as you and I were both council members at the
>> time. My point is that this discussion does not need to even happen
>> and the council shouldn't even remotely be involved here.
>>
>
> I assumed the best way to change policy would be to ask council to rule
> on it. Of course we could just see if we can get a consensus fast
> without council.

There is no change of policy and there is no reason for the council to
be involved. He can change the eclass how he needs and that's the end
of the story. The council does not need to be involved at every
potential crossroad. The council only needs to be involved when a
potential technical issue arises. No technical issue, proceed ahead.
No need for the council to road block.

e.g. if its not in the "rule" book you can do it.

This is vastly different then your interpretation of the council's
mandiate, Petteri, which is "if its not in the rule book go ask
permission".

Hence my point of saying let developers develop instead of telling
them they need to ask permission and wait 4 weeks while it gets on an
agenda list everytime they want to commit to the tree or blow their
nose or boot up their computer.

-- 
Doug Goldstein