On Sat, Aug 18, 2018 at 02:16:33AM +0200, Mathias Behrle wrote:
> > Please explain. Google Cloud storage is just a large disk. The
> > analytics stuff can access the data if it got the authorization to
> > access it.
> I have quite some difficulties to believe that Google respects privacy
> setti
On Fri, 17 Aug 2018, Thomas Goirand wrote:
> On 08/17/2018 10:52 AM, Andrey Rahmatullin wrote:
> > On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote:
> >> While I understand the simplicity of using $company's cloud storage, I'd
> >> rather not rely on some external company and in partic
> On Aug 17, 2018, at 21:17, Paul Wise wrote:
>
>> On Fri, Aug 17, 2018 at 10:05 PM, Jacob Adams wrote:
>>
>> So even if we could change it, it would flood everyone's inbox. I
>> suppose the only solution is to always @mention the package maintainer
>> when submitting a merge request. I suspec
On Fri, Aug 17, 2018 at 10:05 PM, Jacob Adams wrote:
> So even if we could change it, it would flood everyone's inbox. I
> suppose the only solution is to always @mention the package maintainer
> when submitting a merge request. I suspect most haven't looked at their
> notification settings and so
* Bastian Blank: " Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade,
external storage migration)" (Fri, 17 Aug 2018 22:58:18 +0200):
> > Google Cloud storage is tightly linked to their AI & big data analytics
> > features which I personally find highly questionable.
>
> Please explain.
On Fri, Aug 17, 2018 at 01:46:00PM +, Ulrike Uhlig wrote:
> Consent
> ---
>
> I feel like we're currently balancing on a thin cobweb of fait accompli.
> Are such decisions team internal or do they require the consent of the
> project?
There is no notion of a project consent in Debian, apa
On 08/17/2018 04:11 PM, Wouter Verhelst wrote:
> But if we're going to
> be using an external cloud provider for such things, then it doesn't
> matter whether that external cloud provider runs a free software cloud
> implementation or a proprietary one, since we wouldn't have any of the
> benefits
On 08/17/2018 10:52 AM, Andrey Rahmatullin wrote:
> On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote:
>> While I understand the simplicity of using $company's cloud storage, I'd
>> rather not rely on some external company and in particular not on this
>> one. This company does not exact
On Mon, Aug 13, 2018 at 07:05:14PM +0200, Gregor Riepl wrote:
> This package provides the driver for Sun Creator, Creator3D, and Elite3D
> video devices.
And no-one took care to actually convert them to kernel mode setting?
> This driver was previously removed from Debian along with sparc support
On 2018-08-17 16:11:22 +0200 (+0200), Wouter Verhelst wrote:
[...]
> It is true that the whole "cloud" thing does have some impact on free
> software, and it is indeed also true that this is something that should
> be considered when deciding on a strategy; however, it is *not* correct
> to assume
On Tue, Aug 14, 2018 at 01:25:22PM +0200, Jonas Meurer wrote:
> [...] free software cloud providers [...]
No such thing.
The whole concept of "cloud provider" is that you have a company which
provides "hardware" or "infrastructure" as a service. This service is
provided "as is"; you wouldn't be a
Hello,
Alexander Wirt:
> On Fri, 17 Aug 2018, Ulrike Uhlig wrote:
>> Jonas Meurer:
>>> Am 13.08.2018 um 20:36 schrieb Alexander Wirt:
> why should gandi be better? Do you have access to all of their source code
> (managementfrontend, storagebackend, billingbackend and so on?)
>
> Unless debian
On 08/17/2018 03:19 AM, Alexander Wirt wrote:
> On Thu, 16 Aug 2018, Jacob Adams wrote:
>
> Hi,
>
>> I've just discovered that by default, salsa.d.o does not inform project
>> owners of merge requests opened against their projects. This seems like
>> a poorly chosen default, as it is quite easy
Hello,
Andrey Rahmatullin:
> On Fri, Aug 17, 2018 at 10:12:00AM +, u wrote:
While I understand the simplicity of using $company's cloud storage, I'd
rather not rely on some external company and in particular not on this
one. This company does not exactly represent what I would c
On Fri, 17 Aug 2018, Ulrike Uhlig wrote:
> Hi!
>
> Jonas Meurer:
> > Am 13.08.2018 um 20:36 schrieb Alexander Wirt:
> >>> Hrmpf! I have to say that I was somewhat surprised by this announcement.
> >>> To be honest, I don't like the idea of making our infrastructure as a
> >>> project rely on clos
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: minimap2
Version : 2.12
Upstream Author : Copyright: © 2017-2018 Broad Institute
* URL : https://github.com/lh3/minimap2
* License : MIT
Programming Lang: C
Description : versatile
On Fri, Aug 17, 2018 at 10:12:00AM +, u wrote:
> >> While I understand the simplicity of using $company's cloud storage, I'd
> >> rather not rely on some external company and in particular not on this
> >> one. This company does not exactly represent what I would call ethical,
> >> non-propriet
Hello,
Andrey Rahmatullin:
> On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote:
>> While I understand the simplicity of using $company's cloud storage, I'd
>> rather not rely on some external company and in particular not on this
>> one. This company does not exactly represent what I wo
Hi,
I believe by decentralization we can just implement it by not relying our
data on single company but multiple.
Still, it is up to their implementation how we can access their storage,
and as long as we can access it with free software (JavaScript stuff could
be a pitfall though) it shouldn't
On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote:
> While I understand the simplicity of using $company's cloud storage, I'd
> rather not rely on some external company and in particular not on this
> one. This company does not exactly represent what I would call ethical,
> non-proprieta
Hi!
Jonas Meurer:
> Am 13.08.2018 um 20:36 schrieb Alexander Wirt:
>>> Hrmpf! I have to say that I was somewhat surprised by this announcement.
>>> To be honest, I don't like the idea of making our infrastructure as a
>>> project rely on closed and proprietary systems like Google Cloud. Isn't
>>>
On Thu, 16 Aug 2018, Jacob Adams wrote:
Hi,
> I've just discovered that by default, salsa.d.o does not inform project
> owners of merge requests opened against their projects. This seems like
> a poorly chosen default, as it is quite easy to completely miss when a
> user opens a merge request, u
22 matches
Mail list logo
