| 1 |
On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <johu@g.o> wrote: |
| 2 |
|
| 3 |
[snip] |
| 4 |
|
| 5 |
>> Developers have only a limited amount of time, and this will eat into |
| 6 |
>> it. The result is likely to not be new shiny ebuilds that use the new |
| 7 |
>> EAPIs, but rather old rusty ones that still use the old EAPI but also |
| 8 |
>> which contain other bugs, since they don't get touched at all (since |
| 9 |
>> touching them triggers the new policy). |
| 10 |
> |
| 11 |
> You dont need to touch the old ebuild, but if you are touching it for example |
| 12 |
> a version bump, a bug fix etc you should be able to do the EAPI bump as long as |
| 13 |
> you have done the ebuild quizzes ;) |
| 14 |
|
| 15 |
I'm a proxy maintainer. Meaning I haven't done these quizzes. Heck, |
| 16 |
I've never even seen them. I catch bug reports, come up with a |
| 17 |
solution and pass it back to Markos, who then decides whether or not |
| 18 |
to put it in and give feedback. |
| 19 |
|
| 20 |
How would this impact me? |
| 21 |
|
| 22 |
> |
| 23 |
>> For a real-world analogy - look at the result of well-intended laws |
| 24 |
>> that require ADA compliance and such on building modifications. The |
| 25 |
>> result is often stuff like kids taking classes in modular trailers and |
| 26 |
>> such because in order to add an extension to the building you need to |
| 27 |
>> bring the entire building up to code (and not just the new part). The |
| 28 |
>> result isn't more elevators and ramps - but the use of hacked together |
| 29 |
>> solutions to work around the policy. |
| 30 |
> |
| 31 |
> Examples? |
| 32 |
|
| 33 |
Every single hack you've ever seen which was written to get a unit |
| 34 |
test to pass, but makes the code more difficult to modify or refactor |
| 35 |
in the future. |
| 36 |
|
| 37 |
> |
| 38 |
>> If it ain't broke, don't fix it. |
| 39 |
> |
| 40 |
> Essential part of software development is refactoring to get the code in a |
| 41 |
> modern state. |
| 42 |
|
| 43 |
As a professional software developer, I can say that the decision to |
| 44 |
refactor or not is couched deeply in the question of whether or not it |
| 45 |
makes sense to do it at that moment. Typically, you don't refactor |
| 46 |
unless time pressures are sufficiently low, or unless you can see some |
| 47 |
specific way that the refactor will save you time in the very near |
| 48 |
future. |
| 49 |
|
| 50 |
The latter condition will happen normally for a maintainer. But all |
| 51 |
maintainers are volunteers, which means time pressures are always |
| 52 |
high. (Especially if they have lives outside of Gentoo.) |
| 53 |
|
| 54 |
-- |
| 55 |
:wq |
Archives