On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <j...@gentoo.org> 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 over a head for noncompliance. Just point out that newer EAPIs make things easier, and they'll happily use the new EAPIs if they agree. If they don't agree, who cares? You don't need a policy to tell somebody to do something in their own interest. The main reason for policy is to get people to do things that are in the interests of others. >> The downsides are several - you're taking code that works and fiddling >> with it, perhaps creating code that doesn't work. You're forcing that >> development to take place in the newest EAPI, which is also the >> version which the everybody has the least experience with (likely less >> documentation online as well). > > devmanual is fine. I didn't say that the devmanual wasn't fine. I said that there is less documentation available online for newer EAPIs. Documentation doesn't consist ONLY of the devmanual. Code examples in the form of all the other ebuilds in the tree count as well, as do mailing list posts, forums, blogs, and any of a bazillion other historical records, which being historical all use older EAPIs. > >> 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 contain other bugs, since they don't get touched at all (since >> touching them triggers the new policy). > > You dont need to touch the old ebuild, but if you are touching it for example > a version bump, a bug fix etc you should be able to do the EAPI bump as long > as > you have done the ebuild quizzes ;) The point is that maintainers will be less likely to do the version bump or the bug fix in the first place, if they have to rewrite half of the ebuild to do it. If I have a bug and I can fix one line of an ebuild to fix it, then I'm much more likely to find the time to do it than if I have to rewrite half of it. Also, not everybody maintaining packages has actually done the ebuild quizzes. Sure, the person committing the changes has, but we're trying to get non-developers to contribute as well. If somebody submits a patch that works, do we want the dev to just commit it, or do we want them to say, "sorry, you have to re-write half the ebuild if you want me to accept that patch?" Keep in mind that if the dev had the time to rewrite it themselves they would have likely already fixed it themselves. > > Essential part of software development is refactoring to get the code in a > modern state. That only makes sense if you need to make substantial changes to software, such that the investment in refactoring is going to pay off. Few refactor code for its own sake. However, I am not saying that we should make it a policy that maintainers NOT be allowed to use newer EAPIs, but only that it should be up to individual discretion. Keep in mind that we're not paying developers, and we always have more work to be done than people to do the work. In order to make this work we need to lower barriers to contribution. If a developer has an hour to spend on Gentoo, would you rather see them fixing bugs that actually impact people, or rewriting ebuilds to use newer EAPIs, possibly creating more bugs that actually impact people. Keep in mind that as volunteers devs get to pick what they work on, which means that they're less motivated to spend that hour doing anything for Gentoo if it needs to be spent on stuff they don't want to do. I'm all for enforcing quality rules that actually have an impact on end users - lots of shoddy work doesn't help anybody. However, having rules that don't actually improve things for end users just results in less work getting done, and in the end a poorer user experience. Rich
