-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I would like to upgrade tree-wide policy for EAPI usage in main tree.
Currently we say that developers can use any named version they wish or
find sufficient.
I would on other hand like to have all ebuilds to use Latest EAPI
version possible
On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
I would like to upgrade tree-wide policy for EAPI usage in main tree.
I have a great idea for you.
How about creating a project (possibly a subproject of QA or something
else) that would help people do that? In case of no response from
maintainers just
On Tue, Jan 25, 2011 at 01:13:06PM +0100, Paweł Hajdan, Jr. wrote:
On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
I would like to upgrade tree-wide policy for EAPI usage in main tree.
I have a great idea for you.
How about creating a project (possibly a subproject of QA or something
else)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 25.1.2011 13:13, Paweł Hajdan, Jr. napsal(a):
On 1/25/11 12:20 PM, Tomáš Chvátal wrote:
I would like to upgrade tree-wide policy for EAPI usage in main tree.
I have a great idea for you.
How about creating a project (possibly a subproject
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 25.1.2011 13:25, Markos Chandras napsal(a):
On Tue, Jan 25, 2011 at 01:13:06PM +0100, Paweł Hajdan, Jr. wrote:
How about creating a project (possibly a subproject of QA or something
else) that would help people do that? In case of no response
On Tue, Jan 25, 2011 at 01:32:27PM +0100, Tomáš Chvátal wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 25.1.2011 13:25, Markos Chandras napsal(a):
On Tue, Jan 25, 2011 at 01:13:06PM +0100, Paweł Hajdan, Jr. wrote:
How about creating a project (possibly a subproject of QA or
Am 25.01.2011 12:20, schrieb Tomáš Chvátal:
Hi,
I would like to upgrade tree-wide policy for EAPI usage in main tree.
Currently we say that developers can use any named version they wish or
find sufficient.
I would on other hand like to have all ebuilds to use Latest EAPI
version possible
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 25.1.2011 14:33, Thomas Sachau napsal(a):
Do you have some more arguments for your request? Most new developers will
have to know about all
EAPi versions anyway since they join an existing team with existing ebuilds,
which will mostly not
Am 25.01.2011 15:09, schrieb Tomáš Chvátal:
Dne 25.1.2011 14:33, Thomas Sachau napsal(a):
Do you have some more arguments for your request? Most new developers will
have to know about all
EAPi versions anyway since they join an existing team with existing ebuilds,
which will mostly not
use
On 1/25/11 1:29 PM, Tomáš Chvátal wrote:
Why would we need subproject for this.
The idea was that if you want to introduce a new policy, you should also
provide resources to make it possible. The below satisfies most of that.
QA team itself is done to help developers with this tasks. So if
В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет:
Do you have some more arguments for your request? Most new developers
will have to know about all EAPi versions anyway since they join an
existing team with existing ebuilds, which will mostly not use the
newest EAPI.
As an argument
2011-01-25 15:34:58 Thomas Sachau napisał(a):
This means, that you either have to convince the python eclass maintainers to
reduce the complexity
of their eclass
There are plans to remove some EAPI-specific behavior by removing support for
old EAPIs.
E.g. when there are no remaining ebuilds
Am 25.01.2011 17:40, schrieb Peter Volkov:
В Втр, 25/01/2011 в 14:33 +0100, Thomas Sachau пишет:
Do you have some more arguments for your request? Most new developers
will have to know about all EAPi versions anyway since they join an
existing team with existing ebuilds, which will mostly not
On Tuesday 25 January 2011 20:13:40 Thomas Sachau wrote:
The (maybe inofficial) suggestion is already to use the latest EAPI in new
ebuilds. This is ok for
me, as long as it is a suggestion. The same goes for the migration of ebuilds
to the latest EAPI.
But i am against the idea to enforce
Hi,
I don'f feel very well with this idea especially because no matter how hard I
try I don't get comfortable with EAPI-3. No offense to our prefix guys, you
surely did a hell of a good job and EAPI-3 seems to really get you out of
quite some trouble you had with earlier EAPIs, but...
I for
2011-01-25 22:33:16 Lars Wendler napisał(a):
Hi,
I don'f feel very well with this idea especially because no matter how hard I
try I don't get comfortable with EAPI-3. No offense to our prefix guys, you
surely did a hell of a good job and EAPI-3 seems to really get you out of
quite some
On 25/01/11 22:33, Lars Wendler wrote:
Hi,
I don'f feel very well with this idea especially because no matter how hard I
try I don't get comfortable with EAPI-3. No offense to our prefix guys, you
surely did a hell of a good job and EAPI-3 seems to really get you out of
quite some
On Tue, 25 Jan 2011, Lars Wendler wrote:
I don'f feel very well with this idea especially because no matter
how hard I try I don't get comfortable with EAPI-3. No offense to
our prefix guys, you surely did a hell of a good job and EAPI-3
seems to really get you out of quite some trouble you
Just a friendly reminder from your QA team...please do not commit
ebuilds to the tree that are not using an EAPI that is not approved by
the council (in masked or unmasked ebuilds). This means that the only
EAPIs you can use in the tree are EAPI 0 and 1. If you want to use any
of the EAPI-2
19 matches
Mail list logo
