Summary: | kde4.eclass should support EAPI=2 unitl migration is done | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petr Polezhaev <NightNord> |
Component: | Eclasses | Assignee: | Gentoo Quality Assurance Team <qa> |
Status: | VERIFIED INVALID | ||
Severity: | normal | CC: | maksbotan |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Petr Polezhaev
2011-04-07 18:32:51 UTC
Only thing that we as gentoo devs care about is main tree, specialy eapi support. (In reply to comment #1) > Only thing that we as gentoo devs care about is main tree, specialy eapi > support. Saying this you state that you don't care for user's comfort. I think that Sunrise is overlay that we *must* care about, or we would make users feel that their efforts can be made useless at any moment by any Gentoo Dev. Also, doing something harmful without notifying others, including your colleagues, is a bad idea and out of common etiquette. Giving that you are the one who done this change, I don't believe in your judgement, sorry. This is normal procedure in such cases that you should not judge your own actions. So I'm reopening bug until anyone from QA team who is not in KDE-team at same time will confirm this decision. BTW, other teams do deprecation warnings and notifications in their eclasses. Why kde-team is so different? Sunrise is NOT important part of the gentoo. The only important part of the gentoo is gentoo-x86 main tree. The eclasses were in testing for 4 months in the overlay where we tested various overlays and pinged maintainers, nobody obviously cared enough for sunrise, sad but it is up to users. EAPI is and always were dropped from eclasses with obvious 4 months ewarn or whatever period when no hits were found in main tree, just check the history. I am not saying altering or dropping functions should have same approach, but eapi drop usually just requires the altering of the eapi number unless the maintainers of the named eclass want to be huge PITA, so i am perfectly happy with current approach. Btw so your packages got marked as not supported by the eclass and you found during world update, but they were not removed or silently changed like would happen with functional remove. So just bug overlays maintainers to get it fixed. Leaving reopened so someone else close it. s/with obvious 4 months/without any obvious 4 months/ Also for the record QA don't enforce or overview any overlays. Usuall approach is that what is in overlay does not exist/bother us. It is like saying that we didn't bother to announce that we did some package move and suddenly some packages in your overlay have invalid dependencies. QA is generally not concerned with changes in Portage breaking or affecting an overlay. It cannot be expected for a dev to check all packages in all overlays for compliance with changes in an eclass. Unless it breaks the main tree, it's not considered a break. Having said that, a deprecation warning would have been handy, but honestly would not have likely changed anything. Unless someone is actively checking their package, even in sunrise, no one would have noticed until the first time someone tried to emerge it after the deprecation warning. And since weren't talking an overlay, not the main tree, that may have been a while if at all in a reasonable amount of time. News is also not the appropriate place for notification of changes in an eclass. News is meant for vital information to users pertaining generally to changes in a package that could break the use of their install (ex. potential breakage from a new version of say GCC), not for ebuild development changes. Finally, the changes were announced in the gentoo-dev ML. Sunrise: A heads up to Sunrise never hurts, but generally things get fixed quick when something like this happens. It's part of the process. It can get annoying, but there really isn't a much better way to deal with it. QA: Re-closing bug. [1] http://www.gentoo.org/proj/en/glep/glep-0042.html My turn: s/weren't/we are/ (In reply to comment #7) > Having said that, a deprecation warning would have been handy, but honestly > would not have likely changed anything. Unless someone is actively checking > their package, even in sunrise, no one would have noticed until the first time > someone tried to emerge it after the deprecation warning. It fails egencache, for example, or any other ebuild sourc'ing, including dependency checks. So, warnings would be noticed by users who added this ebuilds into sunrise as they are, probably, using them. > Finally, the changes were announced in the gentoo-dev ML. Yeah. And there were warnings into overlay. Not so much of "public announce" as for me... > Sunrise: A heads up to Sunrise never hurts, but generally things get fixed > quick when something like this happens. It's part of the process. It can get > annoying, but there really isn't a much better way to deal with it. There is. And there is a plenty of examples. > QA: Re-closing bug. Well, that's your decision, but, from user's point of view, such behaviour is not very stable-insuring, as overlays are the part of almost every user's system and their breakage has not so big difference in users' experience from main tree's breakage. And this is even worse, taking into account how simple and obvious was the way to prevent such situation. The maintainers of each overlay are responsible to keep their overlays working and compatible with the main tree. If they don't want that, then can always maintain their own eclasses. It makes absolutely no sense to ask us to take care of any single overlay that might exist in this universe or any other parallel universe. This bug has nothing to do with QA. If your overlays are broken then you should complain to their maintainers not to the gentoo developers. (In reply to comment #9) > (In reply to comment #7) > > Having said that, a deprecation warning would have been handy, but honestly > > would not have likely changed anything. Unless someone is actively checking > > their package, even in sunrise, no one would have noticed until the first time > > someone tried to emerge it after the deprecation warning. > It fails egencache, for example, or any other ebuild sourc'ing, including > dependency checks. So, warnings would be noticed by users who added this > ebuilds into sunrise as they are, probably, using them. > Which is great, if it fails straight away it forces people to notice it. In comparsion to function drop, you would actualy have to emerge the ebuild. Fwiw the qa warning would polute the deps calculation/egencache in the same way. Now your maintainers are just forced to act faster, bummer. (In reply to comment #10) > The maintainers of each overlay are responsible to keep their overlays working > and compatible with the main tree. It's very hard to achieve this goal if you don't know about any ongoing changes. Well, if you are a maintainer of some popular overlay than you, maybe, should be reading gentoo-dev maillist announcements. But if you are commiter to sunrise, which is "simple way for users to make their ebuild quality-assured and slightly more official (and trusted) than any other ebuild in overlay", you are probably not reading gentoo-dev maillist and you have no option of using your own eclasses. So, saying this, you mean that whole sunrise idea is a crap - if you are not a Full-Time Assured Gentoo Developer™ than your ebuilds are not quality assured, despite all complexity and QA high bar of sunrise commit procedure, and therefore could be broken at any moment without prior notification. So much of respect to those who commit into sunrise ;) Sunrise maintainers should take care of their ebuilds. Stalling the main tree changes just because of sunrise broken ebuilds makes no sense. Why is it so difficult to understand that main tree has higher priority than sunrise? I'm sorry, I'm removing the KDE Team, got tired of the bugmailspam. (In reply to comment #13) > Sunrise maintainers should take care of their ebuilds. Stalling the main tree > changes just because of sunrise broken ebuilds makes no sense. Why is it so > difficult to understand that main tree has higher priority than sunrise? Just to be clear: it was known in prior that support would be dropped and announcements was made. But only in semi-public way: only in gentoo-dev maillist and only in kde overlay. So everyone who don't follow gentoo-dev@ and hadn't kde overlay installed wasn't aware of upcoming changes. And I see just no objections why it wasn't added into in-tree eclass'es (maybe after than all in-tree ebuilds were fixed)? Why it's so difficult to understand that users don't care about your priorities? Well, when I see that some overlay has missing digest or whatever I say "This damn overlay X failed, again!", but when I saw error in sunrise I thought "This d... wait... Sunrise?!". Of course, sunrise failure is not so epic failure like sbcl missing digest in main tree from some days ago, but generally sunrise believed to be even more stable and polished than main tree. So, when I looked upon error message with more attention, I thought "This damn kde-team had failed, again!". Just try to understand my opinion: sunrise is more than just overlay. It's promoted by gentoo devs, it's looked upon by gentoo devs, it's told as only-true-overlay-for-every-good-and-healthy-ebuild, by gentoo devs too, yes. And my opinion is, that in this current situation, you were able to avoid this situation without any "stalling", but you just didn't bothered. And now you are trying to cover your own failure with some words about. And your words now are more harmful than your actions. Breaking sunrise by accident is pity, but ok - you've just forgotten about it. But talking on public that sunrise is nothing more than simple overlay and you may break it at any moment _without_prior_warning_ (THIS is important: warnings, not breakage itself) is much worse. Just try to remember that except you there is some other non-official developers with enough experience and quality bar, that just have not so much free time or have some other options against being official developers - sunrise commiters. And they should be respected too. And your current behaviour is just disrespectful, IMO. You are aware that both me and Markos work on sunrise. (well i used bit back but now i dont have time to help with reviews). The purpose of that overlay is to let users to contribute into one common place and help them understand how ebuild writting works, potentialy make them full developers. The stuff that is in that overlay is not getting any buildtime/runtime testing we just blindly trust what users contribute and give them proper informations how things should be done ebuild wise. It for sure does not have higher quality than project overlays where one of mandatory things is various buildtime testing and dependency scanning... Sunrise is just nice dumpground for users so you don't have to fetch multiple user overlays from untrusted sources, but still you should consider it overlay and not expect it to have that much higher quality over others. Andrian, one option for the sunrise overlay is to add the old eclass into the overlay until the ebuilds are migrated. That's not a perfect solution, but that will allow the overlay maintainers to update their ebuilds with time and not have the ebuilds in the overlay broken. As a side note, as a former KDE lead, there was a time where we had particular care with eclasses updates so as not to break other ebuilds, but that was related to genkdesvn which was a "competing" KDE overlay and not just an overlay with some random ebuilds using the KDE eclasses. |