| 1 |
On Sat, Mar 21, 2009 at 2:51 PM, Patrick Lauer <patrick@g.o> wrote: |
| 2 |
> On Saturday 21 March 2009 22:26:41 Alec Warner wrote: |
| 3 |
>> >> > > Introducing a policy encouraging moving things that definitely |
| 4 |
>> >> > > aren't in the least bit likely to be a system dep on a bump, sure. |
| 5 |
>> >> > > Making 1 or 2 the default for new packages, sure. But rewriting |
| 6 |
>> >> > > existing things? That's just an accident waiting to happen. |
| 7 |
>> >> > |
| 8 |
>> >> > What kind of accident do you expect to happen? |
| 9 |
>> >> |
| 10 |
>> >> The same kind that always happens when lots of ebuilds get changed. |
| 11 |
>> > |
| 12 |
>> > ... lots of new features and a few bugs that get fixed the next day? Hey, |
| 13 |
>> > that sounds quite bad. And maybe some new herd testers? How rude! |
| 14 |
>> |
| 15 |
>> I don't see the correlation between EAPI bumps and new herd testers. |
| 16 |
> |
| 17 |
> Well, ciaran said that the same thing happens that always happens when lots of |
| 18 |
> ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice |
| 19 |
> herd testers plus a new dev or two, so I am confused too. Maybe ciaran can |
| 20 |
> explain what he meant to say so we don't have to come to unexpected |
| 21 |
> conclusions (that would actually be a quite nice change to the average |
| 22 |
> discussion - saying what you mean instead of hinting at star constellations |
| 23 |
> and the importance of meat loaf) |
| 24 |
> |
| 25 |
>> > So what technical reason(s) do we have to keep archaic EAPIs around |
| 26 |
>> > forever? |
| 27 |
>> None, luckily this is more than a technical project ;) |
| 28 |
> |
| 29 |
> Stop confusing me, antarus, I thought you were against removing eapi0 and now |
| 30 |
> you support the removal? ;) |
| 31 |
|
| 32 |
Editing 20000 ebuilds is not 'technical' in nature, its grunt work. |
| 33 |
It is a social problem, not a technical one. |
| 34 |
I also haven't stated my support in either direction since you have |
| 35 |
provided no specific arguments as to why we should do this; there is |
| 36 |
nothing to argue against. |
| 37 |
|
| 38 |
> |
| 39 |
> Anyway. Most of the "porting" effort (assuming no other issues sneaking in) |
| 40 |
> would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on |
| 41 |
> version bumps. There's no rush to get it killed now now now, but in a year we |
| 42 |
> might be at EAPI 5, and then I don't want to be the one writing the docs that |
| 43 |
> split apart what features are where and what syntax is valid and all that. |
| 44 |
|
| 45 |
Or we might be at EAPI 3; we have no EAPI roadmap and I don't like |
| 46 |
guessing. Again I'm looking for specifics here. You are asking the |
| 47 |
community to do a lot of work for relatively little gain; because you |
| 48 |
haven't specified what the gain is. So I ask again "What specific |
| 49 |
problems does this solve?" |
| 50 |
|
| 51 |
> |
| 52 |
> So phasing out eapi0 would be an obvious step towards making things simpler |
| 53 |
> for those of us that don't enjoy studying lists and tables ... |
| 54 |
> |
| 55 |
> |
| 56 |
> Patrick |
| 57 |
> |
| 58 |
> |
| 59 |
> |
Archives