Hi Flo, On Tue, Dec 03, 2013 at 01:23:15PM +0100, Florian Effenberger wrote: > My strong proposal is therefore to raise the attachment limit in our > own BugZilla instance when it's ready. By that, files are in the > same tool, tied to the same user accounts, and therefore also in the > same backup.
That is ouf course intended in the end. But up until then the Wiki is still a better choice than ownCloud as most people already have accounts there. And no matter to which value we will raise the limit in the new Bugzilla, there always will be freaky corner cases that might need more space. As essentially everything in bugzilla is there for eternity, we shouldnt raise the limit too high. So in the end, we need some form of storage anyway. As the wiki has a rather high limit (25MB) and it should be possible to delete stuff again from there (right?), it doesnt look too bad a fallback to me for now -- esp. since it was already used like that before(*). Probably we should require these to be tagged properly in the wiki though. So _if_ we are using a solution that kinda sucks, we should use _one_ (wiki) and not two (wiki and ownCloud). > (3) SFTP > (4) WebDAV > (5) git via SSH > (6) rsync via SSH > > All of #3-#6 would do from my POV, as they can be configured to use > encryption and authentication (probably git is a wrong choice as > well because of the growing file storage, but I'm no expert here). > It just requires someone taking care of setting up individual > accounts, and I hope we find volunteers if needed. Yes, account creation makes all these a stillborn. For it is easier to tell the reporter to upload to his dropbox/UbuntuOne/Whatever and us to pick it up from there. Of the solutions proposed, 3, 4 and 6 are icky -- since they give everyone read/write-access to the whole thing, we would need backups (of a big amount of trash data) => meh. 4, 5, 6 would usually also result in people doing a full checkout of the tree for simplicity -- and that likely makes people not bothering with it at all. > I don't now how long the BugZilla migration will take. If it's just > a short period of time, we can stay with ownCloud _TEMPORARILY_ and > for a _LIMITED_ amount of time, and then directly host things at > BugZilla. IMHO no. The wiki was used before for this, so lets not throw in another tool into the mix -- so lets roll back on ownCloud usage for this, and _stay_ with the wiki. Not because its the right solution, but because we introduced that already and we dont have anything better right now. Aka: lets not stack one temporary bandaid storage on top of another temporary bandaid storage. Lets stick with the first temporary bandaid (wiki). IMHO, the best solution we could hope for is something helping us like this - to let the enduser upload the file in question to the Dropbox-equivalent of his choice - then have a TDF service where our QA guys can throw an URL at (via email, webinterface, ssh login) - this service then downloads the file and saves it for us on our mirror Scripting this ourselves likely isnt worth it, but I somehow suspect that a simple solution for that somewhere (hopefully without a bazillion other features that we would feature creep into then). Oh, and welcome to the world of http://www.xkcd.com/1172/ ;) Best, Bjoern (*) since at least 2011-05 that was the recommended way: https://wiki.documentfoundation.org/index.php?title=QA/Bugzilla-Attachments&oldid=22899 _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/