On Wed, Mar 25, 2009 at 12:13 PM, Ciaran McCreesh
wrote:
> On Wed, 25 Mar 2009 20:06:47 +0100
> Maciej Mrozowski wrote:
>> Considering average post count and Gentoo membership on that list,
>> I'm pretty convinced you're not entitled to decide who is wasting
>> developers' time.
>
> When you've g
On Wed, 25 Mar 2009 20:06:47 +0100
Maciej Mrozowski wrote:
> Considering average post count and Gentoo membership on that list,
> I'm pretty convinced you're not entitled to decide who is wasting
> developers' time.
When you've gained enough experience and knowledge to be able to
evaluate the mer
On Wednesday 25 of March 2009 15:19:36 Ciaran McCreesh wrote:
> > Being rude doesn't make you cool. (Nor make your points more
> > effective)
>
> That's not being rude.
[...]
(no comment)
> so you're doing them a
> discourtesy by wasting their time by repeatedly posting ideas you
> haven't though
On Wed, 25 Mar 2009 10:19:12 +0100
Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > Uhm. Do you think these ideas of yours through at all before posting
> > them?
>
> Being rude doesn't make you cool. (Nor make your points more
> effective)
That's not being rude. It's an attempt to bring your at
Ciaran McCreesh wrote:
Uhm. Do you think these ideas of yours through at all before posting
them?
Being rude doesn't make you cool. (Nor make your points more effective)
Either you think the entire tree should be switched to a new EAPI in
one go, in which case how on earth is that going to ge
On Tue, 24 Mar 2009 12:40:05 +0100
Luca Barbato wrote:
> I'd rather switch to git first, have eapi in separate branches then,
> make sure we can provide eapi-N compatibility/migration tree snapshots
> and then warn people so there will be a easy way to provide fallbacks.
Uhm. Do you think these
Patrick Lauer wrote:
[deprecating stuff]
I'd rather switch to git first, have eapi in separate branches then,
make sure we can provide eapi-N compatibility/migration tree snapshots
and then warn people so there will be a easy way to provide fallbacks.
Before that I'm afraid it would take too m
On Saturday 21 of March 2009 21:53:16 Patrick Lauer wrote:
> On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote:
> > On Sat, 21 Mar 2009 18:37:12 +0100
> >
> > Patrick Lauer wrote:
> > > To make our lives easier I would suggest deprecating EAPI0 and
> > > migrating existing ebuilds over some
Peter Alfredsen said:
> On Sun, 22 Mar 2009 09:41:58 +0100
>
> Matti Bickel wrote:
> > A general question, that just popped into my head when i was reading
> > this: if i touch a ebuild which has EAPI=0, should i bump it to
> > EAPI=2?
>
> Only if you take the time to read through it and test tha
On Sun, 22 Mar 2009 09:41:58 +0100
Matti Bickel wrote:
> A general question, that just popped into my head when i was reading
> this: if i touch a ebuild which has EAPI=0, should i bump it to
> EAPI=2?
Only if you take the time to read through it and test that your revised
ebuild will have the s
Peter Alfredsen wrote:
> I think we should start
> deprecating EAPI=0 usage *now* with a repoman warning whenever a new
> ebuild is committed that does not use EAPI=1 or EAPI=2. This warning
> should encourage use of the newest EAPI, EAPI=2.
A general question, that just popped into my head when
On Saturday 21 March 2009 19:03:45 AllenJB wrote:
> Patrick Lauer wrote:
> > Hi all,
> >
> > with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> > count them ;) ) EAPIs available or almost available. This is getting
> > quite confusing.
> > To make our lives easier I would s
Patrick Lauer wrote:
Hi all,
with the discussion about EAPI3 we have now 4 (or 7, depending on how you
count them ;) ) EAPIs available or almost available. This is getting quite
confusing.
To make our lives easier I would suggest deprecating EAPI0 and migrating
existing ebuilds over some time
On Sat, Mar 21, 2009 at 2:51 PM, Patrick Lauer wrote:
> On Saturday 21 March 2009 22:26:41 Alec Warner wrote:
>> >> > > Introducing a policy encouraging moving things that definitely
>> >> > > aren't in the least bit likely to be a system dep on a bump, sure.
>> >> > > Making 1 or 2 the default fo
On Sat, 21 Mar 2009 22:51:11 +0100
Patrick Lauer wrote:
> > >> The same kind that always happens when lots of ebuilds get
> > >> changed.
> > >
> > > ... lots of new features and a few bugs that get fixed the next
> > > day? Hey, that sounds quite bad. And maybe some new herd testers?
> > > How ru
On Saturday 21 March 2009 22:26:41 Alec Warner wrote:
> >> > > Introducing a policy encouraging moving things that definitely
> >> > > aren't in the least bit likely to be a system dep on a bump, sure.
> >> > > Making 1 or 2 the default for new packages, sure. But rewriting
> >> > > existing things
On Sat, 21 Mar 2009 18:37:12 +0100
Patrick Lauer wrote:
> To make our lives easier I would suggest deprecating EAPI0 and
> migrating existing ebuilds over some time to EAPI1 or higher until
> EAPI0 can be obsoleted at some point in the future.
> I would set the start of deprecation warnings about
On Sat, Mar 21, 2009 at 2:02 PM, Patrick Lauer wrote:
> On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote:
>> On Sat, 21 Mar 2009 21:53:16 +0100
>>
>> Patrick Lauer wrote:
>> > Because, as you have noticed before, developers get confused which
>> > eapi has which features available. And ea
On Sat, 21 Mar 2009 22:02:54 +0100
Patrick Lauer wrote:
> > So? When people do new things, they can move the EAPI forward.
> > That's not a reason to modify existing things.
>
> The added complexity of having a dozen eapis does not offer any
> benefits to the average developer.
There is no added
On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 21:53:16 +0100
>
> Patrick Lauer wrote:
> > Because, as you have noticed before, developers get confused which
> > eapi has which features available. And eapi1 is a superset of eapi0,
> > so we don't have to rewrite to
Alexey Shvetsov wrote:
Alec Warner wrote:
I am interested in the number of ebuilds at specific APIs in the tree,
do you have those numbers?
Basically, how much work is this (raw ebuild count)?
Total ebuilds 26209
EAPI0 ebuilds 22880
EAPI1 ebuilds 1855
EAPI2 ebuilds 1474
this numbers b
On Sat, 21 Mar 2009 21:53:16 +0100
Patrick Lauer wrote:
> Because, as you have noticed before, developers get confused which
> eapi has which features available. And eapi1 is a superset of eapi0,
> so we don't have to rewrite tons of things.
So? When people do new things, they can move the EAPI
On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 18:37:12 +0100
>
> Patrick Lauer wrote:
> > To make our lives easier I would suggest deprecating EAPI0 and
> > migrating existing ebuilds over some time to EAPI1 or higher until
> > EAPI0 can be obsoleted at some point
Alec Warner wrote:
> I am interested in the number of ebuilds at specific APIs in the tree,
> do you have those numbers?
> Basically, how much work is this (raw ebuild count)?
>
Total ebuilds 26209
EAPI0 ebuilds 22880
EAPI1 ebuilds 1855
EAPI2 ebuilds 1474
this numbers based on regexps =)
On Saturday 21 March 2009 19:37:12 Patrick Lauer wrote:
> Hi all,
>
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> count them ;) ) EAPIs available or almost available. This is getting quite
> confusing.
> To make our lives easier I would suggest deprecating EAPI0 and
On Sat, 21 Mar 2009 18:37:12 +0100
Patrick Lauer wrote:
> To make our lives easier I would suggest deprecating EAPI0 and
> migrating existing ebuilds over some time to EAPI1 or higher until
> EAPI0 can be obsoleted at some point in the future.
Uh. Why?
Introducing a policy encouraging moving thi
Alec Warner schrieb am 21.03.2009 20:45:
Be more specific, what actual problems have you encountered?
What are some other ways we could mitigate these issues (it seems like
tool improvements could be a big one here)?
Regarding the depreciation of EAPI's I think eclasses will probably
benefit
On Sat, Mar 21, 2009 at 10:37 AM, Patrick Lauer wrote:
> Hi all,
>
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you
> count them ;) ) EAPIs available or almost available. This is getting quite
> confusing.
Be more specific, what actual problems have you encountered?
Wha
Hi all,
with the discussion about EAPI3 we have now 4 (or 7, depending on how you
count them ;) ) EAPIs available or almost available. This is getting quite
confusing.
To make our lives easier I would suggest deprecating EAPI0 and migrating
existing ebuilds over some time to EAPI1 or higher unt
29 matches
Mail list logo
