The idea of splitting the gitorious repo is good IMHO. In many cases people just don't have the bandwidth to download the whole repo only to change a couple of lines. If it is more modular, then it is easier to manage and lighter to download. In fact, only distribution related artwork should be housed at gitorious. Other artwork has been going to github as set up by Jos. I also really like the idea of having an owncloud instance for our team. As Richard points out, we don't always produce artwork related to the distribution and we end up making a lot of drafts, proposals and other artwork that requires refinement. For that end, having an owncloud would be easier to manage, especially for new users who might be used to services like Dropbox to share their content. At the same time, having this instance would have to be a "per user" folder and then a folder where final artwork is pushed to. I have no idea how to do this so I welcome any suggestions on how to make an owncloud managing diagram. I proposed the cloud idea to Jos some time ago and if anyone can make it a reality, let's go for it! As far as what we could do for distro artwork for the next release, I intend to propose ideas on the ML later this week. We can check in what position we all are to make these changes or add new ones. :D Thanks guys! Andy (anditosan) On Fri, Nov 22, 2013 at 11:35 AM, Richard Brown wrote:

On 22 November 2013 19:16, Stephan Kulow wrote:

...

Am 22.11.2013 18:34, schrieb Michal Hrusecky:

...

Hi,

I'm trying to convince people to put all our git repos in one place (move people who are still on gitorious to github) and I run accross art repository[1]. Is there still something valuable/needed or is everything moved already to github?

In the later case, I would like to propose to delete this repository...

Apart from that I noticed that artwork repo is quite huge... Have you ever thought about splitting it? We can split it into submodules and put some simple usage script in so you could still clone everything but you could also clone only parts of it and save some space. All that while keeping history.

What do you think about that?

I already moved branding out of it for that reason.

Greetings, Stephan

Hmm, splitting isn't a half bad idea.

My personal opinion is that GitHub isn't the best tool for many of our artists contributing to openSUSE, especially when we often need to share drafts (like we're going to need to do for the next release, which I think is gonna need a nice art refresh :))

GitHub's preference for 'small(er)' file sizes can be quite a hindrance, plus git doesn't necessarily come naturally to those contributors who don't also commit code

I've looked around for a solution, and I'd like to trial using an ownCloud instance - I think it will do the job quite nicely, and the combination of both a 'sync' client, 'live access' clients (any WebDAV client) and the web interface should make it possible for see and contribute stuff to what is currently in the GitHub artwork repo (where features like code review aren't needed)

What does everyone think about this? If its popular with the team, I'll pull a finger out and speak to someone from the infrastructure team about the viability

Of course, I think it should go without saying that I think -branding should stay as it is, where it is, in GitHub

In short

* Yes, delete gitorious/artwork unless someone else screams they're still using it * Splitting further sounds like a great idea, but I'd like to consider a more 'artist appropriate' tool like ownCloud first * Whatever we decide to do for artwork, lets leave branding where it is.

Thoughts? -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

-- Andy (anditosan) -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

...

* Yes, delete gitorious/artwork unless someone else screams they're still using it

Agree with that

...

* Splitting further sounds like a great idea, but I'd like to consider a more 'artist appropriate' tool like ownCloud first

Yep, I think that we need another more apropiate tool for artwork, maybe ownCloud, sounds good.

...

* Whatever we decide to do for artwork, lets leave branding where it is.

+1 2013/11/22 Victor Hck :

...

...

* Yes, delete gitorious/artwork unless someone else screams they're still using it

...

...

* Splitting further sounds like a great idea, but I'd like to consider a more 'artist appropriate' tool like ownCloud first * Whatever we decide to do for artwork, lets leave branding where it is.

-- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

Bruno Friedmann - 21:30 22.11.13 wrote:

...

...

I've looked around for a solution, and I'd like to trial using an ownCloud instance - I think it will do the job quite nicely, and the combination of both a 'sync' client, 'live access' clients (any WebDAV client) and the web interface should make it possible for see and contribute stuff to what is currently in the GitHub artwork repo (where features like code review aren't needed)

Will really an owncloud instance help ? (Where is it hosted, Who manage it, Who can fix it (think upgrade update there's a lot with owncloud) Behind owncloud, we have to manage also its file versionning system. Who will be able to checkout the complete revision ? How will be managed the changelog about files ...

Do artists really need git like versioning? For branding for sure, but the rest? All those release materials we have in separate directories keeping old materials as well for reference... And when I imagine artist, I don't really think that git and VCS comes naturally, more like manual versioning in terms of directories... Didn't meant it in any disrespectful way, but artists are graphical people and things like git are oriented more towards us - programmers. So maybe versioning is not needed, just having a backup around in case somebody accidentally deletes everything might be enough... Just my two cents :-) -- Michal Hrusecky -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

On 23 November 2013 19:39, Bruno Friedmann wrote:

Okay you made a point, but I pick it back

svg is only text, so perfect for versioning tools :-)

Yet another reason svg is really important for the branding- package, and why I think branding- is best left in git If we move to something like ownCloud for artwork, I'd expect to use all of its features for versioning/file restoration, etc to give us as much of that capability as possible, while retaining an ease of use and lower technical barrier for our artists that GitHub doesn't doesn't have I've been thinking about this for some time, and I dont think there is *one perfect tool* for everything and all of us (ie. branding AND artwork), so my preference is to lean towards ease of use and accessibility for our artists who use the artwork repo - we want them worrying about things that look good, (design, aethetics, etc) not how to do a git clone Splitting the artwork github into many pieces is a cool solution for the problem of 'boy it takes a long time to clone', but why fix just that when this might be an excuse to make it easier all, especially new artwork contributors? :) -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

On Sat, 23 Nov 2013 14:58:19 -0700 Andres Silva wrote:

This doesn’t mean that artists cannot do GIT, it simply means that our workflow works better with something that is not related to version control.

Version control, like git, is useful for some files, like SVG, as you can see changes in a text, and mostly useless for anything else. Sufficient version control for graphics is what wiki (MediaWiki) provides. You have: * file versions and thumbnails for each version * you can list current versions of all files * you can put files in categories, ie. tag them * you can create custom galleries, and so on.

We change and create so much that keeping up with GIT simply adds an extra layer of complexity to the work. I would assume that very few artist that do graphical design actually use git as their preferred place for project storage.

To use git one has to learn quite a few commands and know how it actually works. It is not as simple as file upload. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

On Fri, 2013-11-29 at 11:19 +0100, Ludwig Nussel wrote:

Richard Brown wrote:

...

On 23 November 2013 19:39, Bruno Friedmann wrote:

...

Okay you made a point, but I pick it back

svg is only text, so perfect for versioning tools :-)

Yet another reason svg is really important for the branding- package, and why I think branding- is best left in git

If we move to something like ownCloud for artwork, I'd expect to use all of its features for versioning/file restoration, etc to give us as much of that capability as possible, while retaining an ease of use and lower technical barrier for our artists that GitHub doesn't doesn't have

I haven't seen svn mentioned in this thread. Did anyone consider it? The way it works makes it more suitable also for binary files. It's mature and easy to use for non geeks. It's even possible to mount svn repos via webdav, hiding even more the versioning system behind it without losing it's benefits. Since svn is on SLES there might even be a chance to convince the opensuse sysadmins to allow someone to host the repo on opensuse infrastructure.

cu Ludwig

Oh mmmmm that idea could have legs :) I like it -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

Rajko - 16:09 29.11.13 wrote:

On Fri, 29 Nov 2013 11:22:53 +0100 Richard Brown wrote:

...

Oh mmmmm that idea could have legs :) I like it

Hopefully it will have both legs, left and right :)

I don't remember that anyone mentioned specific requirements for web service for artists.

This is what I can see as necessary (listed in no particular order):

* Act as another place (directory) on a local computer where artist can put files, edit content and save it. + It allows work even when web is not present (offline mode). + It does not require web based applications to edit images. - User have to save files and sync work before changes are visible.

ownCloud can do that.

* Version control. + Prevents loss of work, as the most recent version doesn't remove older. - Smaller changes will take more room for binary formats. This should not be a problem with today storage capacity.

ownCloud can somehow do that, although not real revisions like git and probably old revisions will be visible only on web. Haven't tested.

* No user intervention to upload, or download. Script, or binary, will take care to sync that local repo with opensuse artwork server, but user should be able to trigger synchronization at any moment.

ownCloud can do that.

* configuration should be as simple as possible, like: Tell binary your web credentials, and what part of the whole artwork repo you want to have and you are good to go.

ownCloud can do that. And has nice GUI wizard to do that.

* GUI as management tool. Artists are visual minds and giving them CLI will work with very few of them. - we don't have visual tool (?) + some people look for YaST modules to work on, or to create new ones. If we act fast to get their attention, then we can use their enthusiasm to fix one long standing problem for more contributions.

ownCloud has official GUI client, but being webdav, there are other GUI/CLI clients available.

* to prevent configuration problems later when you want to expand your interest to other art repos, directory structure on the web server is replicated in full, but only current interest is populated, or synchronized.

No. But you can always add another directory to be synchronized.

* included instructions, or binary, to create desktop links to populated repos which will allow to have your artwork at hand.

Not sure what you mean by that. Desktop links to directories you have on your disk? Depends on DE, but definitely independent of solution used.

* server layout (directory structure ?) ** User space for individual experiments with ability to link, or copy file to official ones. Per topic directories, like: ** system startup ** GNOME ** KDE ** Applications ** scripts and binaries

Independent of solution used.

* Any more? Please expand.

Looking at above, specifications are light version of something between OBS and SVN.

I like Richards idea of ownCloud, I think new artists will find it really easy to use and intuitive. -- Michal Hrusecky -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

On Sun, 1 Dec 2013 11:55:07 +0100 Michal Hrusecky wrote:

Rajko - 16:09 29.11.13 wrote:

...

On Fri, 29 Nov 2013 11:22:53 +0100 Richard Brown wrote: ... * Version control. ... ownCloud can somehow do that, although not real revisions like git and probably old revisions will be visible only on web. Haven't tested.

Can you test it? I would do that, but my time constrains work against. I have convincing experience that taking sizable obligations like this without being previously exposed to similar problems can delay project and frustrate everybody, including me. The basic need is a very simple version control, just to prevent destruction of old work in case of file name collision, but ability that admin can remove old files. Nothing fancier then MediaWiki provides for files. ...

...

* GUI as management tool. Artists are visual minds and giving them CLI will work with very few of them. - we don't have visual tool (?) + some people look for YaST modules to work on, or to create new ones. If we act fast to get their attention, then we can use their enthusiasm to fix one long standing problem for more contributions.

ownCloud has official GUI client, but being webdav, there are other GUI/CLI clients available.

While freedom to use whatever works best for you is precious, having unified solution helps documentation writers, online helpers and packagers.

...

* to prevent configuration problems later when you want to expand your interest to other art repos, directory structure on the web server is replicated in full, but only current interest is populated, or synchronized.

No. But you can always add another directory to be synchronized.

It seems to me that it is just ownCloud configuration. If it works for instance as SpiderOak, then it is just configuration option that can be packaged as default for artists version of ownCloud.

...

* included instructions, or binary, to create desktop links to populated repos which will allow to have your artwork at hand.

Not sure what you mean by that. Desktop links to directories you have on your disk? Depends on DE, but definitely independent of solution used.

Yes they are DE dependant, but we have to provide help how to create them, or have packaged some that everybody needs as a part of artwork team package. Template desktop link to directory is one of them.

...

* server layout (directory structure ?) ** User space for individual experiments with ability to link, or copy file to official ones. Per topic directories, like: ** system startup ** GNOME ** KDE ** Applications ** scripts and binaries

Independent of solution used.

Independent of server side solution, but it has to be provided. User space where other have restricted access and the only admin is user. Public space where even web side admins can't remove stuff permanently, like in a wiki. Articles in a wiki can be permanently deleted only by manipulating database, not from web interface.

...

* Any more? Please expand.

This is still what we need. Tell about your workflow and your vision how ownCloud can help you. Write with as many details as you can, including use of public services like Dropbox, Photobucket, Flickr, paste sites, git, svn, applications in use, problems with applications. I think that all of this can help us to create solution that will work for everybody with minimum compromises and need to rework infrastructure later. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org

On Friday 22 November 2013 19:35:26 Richard Brown wrote:

On 22 November 2013 19:16, Stephan Kulow wrote:

...

Am 22.11.2013 18:34, schrieb Michal Hrusecky:

...

Hi,

I'm trying to convince people to put all our git repos in one place (move people who are still on gitorious to github) and I run accross art repository[1]. Is there still something valuable/needed or is everything moved already to github?

In the later case, I would like to propose to delete this repository...

Apart from that I noticed that artwork repo is quite huge... Have you ever thought about splitting it? We can split it into submodules and put some simple usage script in so you could still clone everything but you could also clone only parts of it and save some space. All that while keeping history.

What do you think about that?

I already moved branding out of it for that reason.

Greetings, Stephan

Hmm, splitting isn't a half bad idea.

My personal opinion is that GitHub isn't the best tool for many of our artists contributing to openSUSE, especially when we often need to share drafts (like we're going to need to do for the next release, which I think is gonna need a nice art refresh :))

GitHub's preference for 'small(er)' file sizes can be quite a hindrance, plus git doesn't necessarily come naturally to those contributors who don't also commit code

I've looked around for a solution, and I'd like to trial using an ownCloud instance - I think it will do the job quite nicely, and the combination of both a 'sync' client, 'live access' clients (any WebDAV client) and the web interface should make it possible for see and contribute stuff to what is currently in the GitHub artwork repo (where features like code review aren't needed)

What does everyone think about this? If its popular with the team, I'll pull a finger out and speak to someone from the infrastructure team about the viability

Of course, I think it should go without saying that I think -branding should stay as it is, where it is, in GitHub

In short

* Yes, delete gitorious/artwork unless someone else screams they're still using it * Splitting further sounds like a great idea, but I'd like to consider a more 'artist appropriate' tool like ownCloud first * Whatever we decide to do for artwork, lets leave branding where it is.

Thoughts?

I have asked the sysadmin team for a solution for this a while ago. Their answer was that they would prefer to try and put as much in existing tools, rather than running owncloud or other solutions. They proposed to use progress.opensuse.org for this. It has file storage abilities and with some plugins it could be a very comfortable home for our artwork. They are currently looking into this and while it won't be this year, they will present what they have come up with as soon as they have something. Now of course we could try to speed things up, try to host something like owncloud somewhere etc., but I suggest that we've survived this long with github another month won't kill us; and we wouldn't want to rely on infrastructure that our sysadmin team doesn't have access to for something as essential as artwork. If only because whoever hosts it could get sued to Jerusalem for copyright infringement. In short, as Andy said - I've asked the sysadmins and they are looking into it. I suggest we let them do their thing ;-) /J -- To unsubscribe, e-mail: opensuse-artwork+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-artwork+owner@opensuse.org