Re: [kde-artists] Re: KDE 4.6.3 tarballs (try#1 part1) uploaded
A Domingo, 8 de Maio de 2011 18:36:19 Eike Hein você escreveu: On 05/08/2011 02:13 PM, Andrea Scarpino wrote: On 28 April 2011 18:23, Dirk Muellermuel...@kde.org wrote: Hi, I just finished the first set of KDE 4.6.3 tarballs. Missing are kdeedu, which migrated completely into seperate modules in git and I have to reassemble it again. I also need to figure out how to regenerate kdeplasma-addons. Please let me know of any issues with those tarballs. Seems that none of us noticed the new icons in the oxygen-icons tarball. Is this change intentional? I don't think new icons should be shipped with minor releases. Also they are inconsistent, see the KDE bug #272756. This happens every time because oxygen-icons doesn't keep a proper 4.6 branch. Last time it happened with the new MIME type icons, which was also a glaring release quality issue. It's clearly not intentional either; the artwork team was very unhappy when the new MIMEs got into the tarball before 4.6.0. Unless the artwork team starts using branches properly IMHO the only solution is to keep oxygen-icons at .0 each time and give up on point releases for it. It's not possible for the release tagger to sort things out on an icon-by-icon basis. In this case I guess things would have to fall back to the 4.6.2 tarball. Yes please, and sorry for the inconvinience If some new icons are important to some application that is not on the main kde release sicle i will let you guys know ... oxygen guy, I make the pretty pictures ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
A Friday 27 March 2009 23:49:32, Sebastian Kügler escreveu: On Friday 27 March 2009 10:05:11 Riccardo Iaconelli wrote: On Thursday 26 March 2009 16:00:22 Dirk Mueller wrote: On Thursday 19 March 2009, Cyrille Berger wrote: I talked with Casper (over irc) on what would be needed for releasing oxygen icons. Unless I missed something, it's tag, export and upload (mail kde- packager ?), and he seemed ready to do it himself. I'm willing to do the packaging myself, but I need the information where to find the oxygen icons for KDE 4.2.2. You're not really telling me that I should use the trunk version of oxygen icons, right? What is the version number of the oxygen icons? where can I find the version that matches KDE 4.2 branch? Ok, I didn't talk with Casper or Nuno here, so take my word with a grain of salt here, but... why not? It's icons, we shouldn't have any regressions, and we have decided to split the release exactly to provide the most fresh icons possible. But then, I'm not sure if we want to break packaging scripts in a minor release. I think removing the icons from branch and shipping them from kdesupport is a bad idea. With this kind of structural changes to a stable branch, we're making it harder for packagers to ship our updates and bugfixes, they're now either stuck with putting the icons back into the old location and ship this, or offer the icons as separate package, which creates more work for these poor people. Shipping Oxygen separately might be interesting for third party applications to use the icons, the names are standardized and they don't depend on neither KDE nor Qt (in fact they depend on being rendered with Inkscape ;)). We need to consider that Oxygen is part of a stable platform. Even if we fix the apps that we ship together with Oxygen, that still means that we might screw some third party apps that suddenly loose icons in a x.y.z bugfix and translation update. It's fine to update the Oxygen icons also in a stable cycle, the large majority of the updates to Oxygen is probably a 100% safe to backport. For trunk, we can make these changes, but we need to consider the above points just as well. Backwards compatibility is just as important across major cycles (4.2 - 4.3) releases. I don't really see why putting Oxygen into kdesupport would mean that users get updates more often. I think it'll work the other way, branch is shipped every month, that means improvements to Oxygen can be shipped to the user usually in less than four weeks. By putting in them kdesupport (which is less visible and might not be updated by packagers along with a x.y.z release) the likely effect is that Oxygen is overall updated *less* often. Well my issue is another as nothing to do with the issues so far. its about control, we are creating a new kde3.x mess couse aplications are creating their hown versions of the same icons, and not teling any one they do so, couse well they dont have 2. second i have alrady done a couple of duplicated icons with slightly difrent names couse well i forgot i did icon a for app B and icon c for app D and a=c just that they dont. i have no idea of how many icons we have done so far no idea of what apps are using couse its out of the oxygen directory its scatered all around kde svn. this is a solution to that issue, no one came up with a beter one.. -- Oxygen coordinator ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: oxygen icons moved
A Saturday 28 March 2009 00:55:32, Sebastian Kügler escreveu: On Saturday 28 March 2009 01:27:58 Nuno Pinheiro wrote: Well my issue is another as nothing to do with the issues so far. its about control, we are creating a new kde3.x mess couse aplications are creating their hown versions of the same icons, and not teling any one they do so, couse well they dont have 2. I see. I don't see another solution than to make it easy to ship all icons from one canonical source. Maybe we should have a mechanism to download missing icons automatically, so Oxygen is shipped as webservice. Or at least educating application developers better. Realistically, there will always be the problem of people not passing their modifications up, it's just too easy to change the name and ship it, while passing it back upstream is hard. This doesn't mean that what Oxygen ships should be clean. Am I assuming correctly that the only regressions caused by icons is when an icon gets a different name and needs to be moved? second i have alrady done a couple of duplicated icons with slightly difrent names couse well i forgot i did icon a for app B and icon c for app D and a=c just that they dont. i have no idea of how many icons we have done so far no idea of what apps are using couse its out of the oxygen directory its scatered all around kde svn. That sucks :/. So to you as icon developer, there should be One Canonical Place To Put All Icons... yeap this is a solution to that issue, no one came up with a beter one.. Let's try to find a better one then :) I don't see in how far putting icons into kdesupport would solve that problem? the idea was to put every single icon there Or is the problem the size of Oxygen? I can imagine that you don't want to ship every single special application icon in the world in the kdebase tarball. yeap in the end it will be quite a large group it allready is and im gessing about arround 100 are outside already, In that case, it would make sense to ship it separately. This change (which is the point of this discussion) is made already. Still, that's not something we should change in a bug fix update as Andreas pointed out as well. Realy im fine with anything as long as it works, by working i meen having some way of geting a complete overview of the intire icon set, with i dont right now, and nor do developers, a developer serching for an specific icon for his app as no place to go and look for all of them unless he instales every single app out there that ships oxygen icons, and heven if he does he cant be sure its realy an oxygen icon or a icon some application developer found some ware and put it in his install oxygen directory... I have no perfect anser for this but I can complain about it I have spoken about this to the other icon designers we all agrea that a centralized place for all icons is beter... -- Oxygen coordinator ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
