On Sep 6, 2012 10:18 AM, "Michael Orlitzky" wrote:
>
> On 09/05/2012 05:29 PM, Brian Harring wrote:
> >
> > Yes, I stated it because I view it as useful/sane.
> >
> >> and isn't a compromise at all.
> >
> > I think you're mistaken in assuming a compromise is the required
> > outcome of this. Give
On Thu, Sep 6, 2012 at 1:16 PM, Michael Orlitzky wrote:
> From a developer's perspective, it's obviously better to be able to do
> whatever you want. But for users it'd be nice to be able to request a
> bump to EAPI5 and not get told to buzz off.
It is easy. Don't ask for a bump to EAPI5. Ask f
On 09/05/2012 05:29 PM, Brian Harring wrote:
>
> Yes, I stated it because I view it as useful/sane.
>
>> and isn't a compromise at all.
>
> I think you're mistaken in assuming a compromise is the required
> outcome of this. Given the choice between something productive, and
> something not pr
On Thu, Sep 6, 2012 at 1:03 PM, Michael Orlitzky wrote:
> If there's really no reason, why would anyone bother to file a bug for
> it? It's better for developers than the must-bump policy, and better for
> users than what we have now.
What change is even being proposed? If there is an issue that
On 09/05/2012 12:15 PM, Mike Gilbert wrote:
> On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky wrote:
>> On 09/04/2012 05:06 PM, Brian Harring wrote:
As a compromise, it could be made policy that "bump to EAPI=foo" bugs
are valid. If someone would benefit from such a bump, he can fi
On Tue, Sep 04, 2012 at 09:03:55PM -0400, Michael Orlitzky wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
> >>
> >> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> >> are valid. If someone would benefit from such a bump, he can file a bug
> >> and know that it won't b
On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>
>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>> are valid. If someone would benefit from such a bump, he can file a bug
>>> and know that it won't be closed WONT
On 09/04/2012 05:06 PM, Brian Harring wrote:
>>
>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>> are valid. If someone would benefit from such a bump, he can file a bug
>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>> under no more pressure th
On Sun, Sep 02, 2012 at 10:36:13AM -0400, Michael Orlitzky wrote:
> On 09/02/2012 09:46 AM, Rich Freeman wrote:
> > On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel
> > wrote:
> >> What I dont actually understand at all is why bumping the EAPI should be so
> >> complicated or involved that it e
On Sun, 2 Sep 2012 14:54:12 -0300
Alexis Ballier wrote:
> On Sun, 02 Sep 2012 14:03:07 +0200
> hasufell wrote:
>
> > On 09/02/2012 12:52 PM, Vaeth wrote:
> > > Rich Freeman wrote:
> > >
> > >> If I thought that bumping the EAPI would make my life as a
> > >> maintainer easier I'd just do it -
On Sun, 2 Sep 2012 15:23:58 +0200
"Andreas K. Huettel" wrote:
> To be honest I personally consider that ("eapis are not ordered") an
> abomination, and my personal wish would be to keep them large-scale
> ordered with (among one major version) unordered sub-versions
> ("4-xxx") if needed. or at l
On Sun, 02 Sep 2012 14:03:07 +0200
hasufell wrote:
> global epatch_user has a downside which I think was not even really
> discussed here unless I missed something. It could introduce many
> bogus bug reports which are caused by user-applied patches, cause
> it's easier now and you don't need to d
On Sun, 02 Sep 2012 14:03:07 +0200
hasufell wrote:
> On 09/02/2012 12:52 PM, Vaeth wrote:
> > Rich Freeman wrote:
> >
> >> If I thought that bumping the EAPI would make my life as a
> >> maintainer easier I'd just do it - I wouldn't need a policy to
> >> tell me to do it.
> >
> > It is not onl
On 09/02/2012 09:46 AM, Rich Freeman wrote:
> On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel
> wrote:
>> What I dont actually understand at all is why bumping the EAPI should be so
>> complicated or involved that it even deserves so much resistance...
>
> Ok, it REALLY annoys me when people
On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel wrote:
> What I dont actually understand at all is why bumping the EAPI should be so
> complicated or involved that it even deserves so much resistance...
Ok, it REALLY annoys me when people pull out this kind of a line
in an argument... If it i
> Bottom line is that what a developer MUST do is a matter of what
> people will bother to complain to Devrel about, and what Devrel will
> bother to enforce. For the most part this boils down to common sense.
Err... if that's the part you worry about, I'm personally completely happy if
we just
> >
[...]
> > standards. So, we declare that gcc-4.5 has to be enough for everyone,
> > we'll just keep it in tree forever and dont bother anymore with all
> > these superfluous "does not build with gcc-4.7" bugs.
>
> That is not an appropriate analogy, as I'm not suggesting that we
> refuse to s
On Sun, Sep 2, 2012 at 8:03 AM, hasufell wrote:
> PMS is a fraction of what is to consider when writing an ebuild. It does
> not include QA policies, gentoo policies and whatnot.
True, although at least somebody bothers to write PMS down...
Much of the rest is word of mouth, posts on mailing lis
On 09/02/2012 12:52 PM, Vaeth wrote:
> Rich Freeman wrote:
>
>> If I thought that bumping the EAPI would make my life as a maintainer
>> easier I'd just do it - I wouldn't need a policy to tell me to do it.
>
> It is not only so much a question of whether it helps you as a
> maintainer but more
On Sun, Sep 2, 2012 at 6:52 AM, Vaeth wrote:
> So in any case, for the _user_ an EAPI bump is (with the current EAPIs)
> always a benefit. This should be worth to establish the policy currently.
Your example only cited cases where an EAPI bump to 5 has a benefit.
If that is the case, I'm fine wit
Rich Freeman wrote:
If I thought that bumping the EAPI would make my life as a maintainer
easier I'd just do it - I wouldn't need a policy to tell me to do it.
It is not only so much a question of whether it helps you as a
maintainer but more whether it helps the user. And this is the case
fo
On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel
wrote:
>
> Let's say, we as in Gentoo decide that we're completely sick of keeping all
> that old code out there adjusted to newer and newer gcc versions that are more
> and more critical towards minor details of the c++ standards. So, we declar
Am Freitag, 31. August 2012, 11:03:06 schrieb Andreas K. Huettel:
> Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
> > On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber wrote:
> > >> scarabeus suggested the change "dev should use latest eapi when
> > >> bumping"
> > >> to "dev must u
Am Freitag, 31. August 2012, 11:11:37 schrieb Fabian Groffen:
> On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote:
> > any fun to look up things in PMS anew everytime you edit something. (Was
> > the prayer to Paludis only required in EAPI=7 in src_prepare or in
> > EAPI=8 in pkg_preinst?) Thi
On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote:
> any fun to look up things in PMS anew everytime you edit something. (Was the
> prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in
> pkg_preinst?) This problem could however also be solved by selectively
> phasing
>
Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
> On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber wrote:
> >> scarabeus suggested the change "dev should use latest eapi when bumping"
> >> to "dev must use latest eapi when bumping if not forbidden by eclasses".
> >> He was asked to b
It's very simple. People will just ignore this if they disagree and
leave any "bump to EAPI-latest already" bugs unresolved forever.
On Thu, Aug 30, 2012 at 3:44 PM, Thomas Sachau wrote:
> Andreas K. Huettel schrieb:
>> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>>> Could you elaborate what the reasons FOR it are (not that I don't know
>>> any, but you brought it up) since this will add work for every developer
On Thu, 30 Aug 2012 16:05:52 -0400
Michael Mol wrote:
> Compile a list of existing ebuilds which depend on old EAPIs, and
> you've got a TODO list. (eclasses, I don't know; I don't know if
> eclasses explicitly express EAPI compatibility in metadata) Once that
> list is cleared, yes, you can assum
On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau wrote:
> Michael Mol schrieb:
>> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote:
>>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
The primary benefit to the policy that dev's should bump EAPI when
bumping ebuilds is s
Michael Mol schrieb:
> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote:
>> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
>>>
>>> The primary benefit to the policy that dev's should bump EAPI when
>>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>>> eventual
Andreas K. Huettel schrieb:
> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>> Could you elaborate what the reasons FOR it are (not that I don't know
>> any, but you brought it up) since this will add work for every developer
>> to check a) how the behavior of the new EAPI impacts the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 09:14 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius
> wrote:
>>
>> The primary benefit to the policy that dev's should bump EAPI
>> when bumping ebuilds is so that older inferior EAPIs can be
>> deprecated
On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
>>
>> The primary benefit to the policy that dev's should bump EAPI when
>> bumping ebuilds is so that older inferior EAPIs can be deprecated and
>> eventually removed from the tree.
>
Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
> Could you elaborate what the reasons FOR it are (not that I don't know
> any, but you brought it up) since this will add work for every developer
> to check a) how the behavior of the new EAPI impacts the current ebuild
> and b) how the b
On Thu, Aug 30, 2012 at 9:07 AM, Ian Stakenvicius wrote:
> I think you may miss the meaning of "should". It's not the same as
> "must".
Is it a policy or not? If it is a policy we can ignore at our own
discretion, then by all means pass it, and we can all do whatever we
like, as we already are.
On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius wrote:
>
> The primary benefit to the policy that dev's should bump EAPI when
> bumping ebuilds is so that older inferior EAPIs can be deprecated and
> eventually removed from the tree.
What is the benefit from removing the old EAPIs?
>
> Take, f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 09:04 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius
> wrote:
>> If you are rewriting a full ebuild as your solution, and the
>> ebuild you start with is EAPI<4 , then Markos would appreciate it
>> if you cha
On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius wrote:
> If you are rewriting a full ebuild as your solution, and the ebuild
> you start with is EAPI<4 , then Markos would appreciate it if you
> changed the ebuild to be EAPI=4 (or whatever the latest EAPI is) in
> addition to the fix. Otherwise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 08:30 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber
> wrote:
>>
>> EAPI 0 is more readable than EAPI 4? No benefit for maintainer?
>> No benefit for user who wants to read the ebuild? Realy?
>
> Then why mak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 30/08/12 08:37 AM, Michael Mol wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber
> wrote:
>
> [snip]
>
>>> Developers have only a limited amount of time, and this will
>>> eat into it. The result is likely to not be new shiny ebuilds
>>
On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber wrote:
[snip]
>> Developers have only a limited amount of time, and this will eat into
>> it. The result is likely to not be new shiny ebuilds that use the new
>> EAPIs, but rather old rusty ones that still use the old EAPI but also
>> which conta
On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber wrote:
>
> EAPI 0 is more readable than EAPI 4? No benefit for maintainer? No benefit for
> user who wants to read the ebuild? Realy?
Then why make it a policy?
If as you say there is a benefit to the maintainer, then you won't
have to hit them ove
> Could you elaborate what the reasons FOR it are (not that I don't know
> any, but you brought it up) since this will add work for every developer
> to check a) how the behavior of the new EAPI impacts the current ebuild
> and b) how the behvaior of inherited eclasses change depending on EAPI.
My
> I can't say I'm a big fan of this. This requires forcing changes to
> ebuilds that offer no actual benefit to either the maintainer or the
> end-users (changes that actually have some benefit to either are
> likely to be made anyway). The PM maintainers have chimed in that
> there is no benefit
On 08/30/2012 12:28 PM, Johannes Huber wrote:
> Hello gentoo devs,
>
> From last council meeting summary:
> [snip]
>> Open floor
>> ==
>> scarabeus suggested the change "dev should use latest eapi when bumping"
>> to "dev must use latest eapi when bumping if not forbidden by eclasses".
>>
On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber wrote:
>> scarabeus suggested the change "dev should use latest eapi when bumping"
>> to "dev must use latest eapi when bumping if not forbidden by eclasses".
>> He was asked to bring it up on the mailing lists, to get a better
>> definition of when
Hello gentoo devs,
>From last council meeting summary:
[snip]
> Open floor
> ==
> scarabeus suggested the change "dev should use latest eapi when bumping"
> to "dev must use latest eapi when bumping if not forbidden by eclasses".
> He was asked to bring it up on the mailing lists, to get a
> 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 trou
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 t
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
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 my
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 en
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 mostl
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 ebuild
В Втр, 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
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 so
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
-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 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 possib
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
-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 resp
-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 sub
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
>
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
-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 (given
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 prere
67 matches
Mail list logo
