On Tuesday 12 November 2013 22:53:18 Thomas Zander wrote: > All these may actually exclude the stuff that is used to create the > deliverables. If you use gimp to draw, the gimp file is imporant, but the > "asset" and "deliverable" is typically used for the png you export. > So I'm assuming we want the source-materials, and in that case those names > may not be the best.
Yeah, that's exactly the problem I had with "deliverables" - you can play the game that the deliverables of a FOSS project *are* source materials, but sadly we just don't live in a world where that reads intuitively ... > What about calling them; "source materials". Or "Product source materials"? Hmm, nice idea ... let's briefly check it against a tricky case, though: - With the Oxygen icons, the original source materials are SVG source. - However, we also store rasterized forms in SVN. - Those rasterized forms are often further hand-optimized, i.e. you can't recreate trivially them from the SVG source. Our goal therefore must be to make sure both of these forms are in the repo - does "source materials" apply sufficiently to "hand- optimized PNGs cut from SVGs", or is there a loophole there? I toyed with variations of "source and release materials" for a while, but that has the problems that it (a) ends up creating loopholes for aux assets not put into tarballs in the end and (b) can easily start reading on the tarballs themselves, becoming confusing. Let's try it out in full for now in order to keep an overview: "All source materials are hosted on infrastructure available and writable by all KDE contributor accounts." I think it's an improvement overall - but not sure about Oxygen. Cheers, Eike _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
