On Friday, 8 June 2018 12:11:49 PM AEST Paul Wise wrote:
> In my experience the Wordpress upstream auto-upgrade system is
> typically faster than the Debian's handling of Wordpress. I also get
> the impression that the number of CVEs (let alone all security issues)
> is scaling faster than the amou
On Friday, 8 June 2018 2:48:58 AM AEST Tollef Fog Heen wrote:
> As DSA, I'd love to have Kubernetes or similar in stable so we could
> have deployment using containers and just rebuild those and then service
> owners could have a good way to do both development, testing and
> deployment of their se
On Sat, 2018-06-09 at 13:52 +0100, Ian Jackson wrote:
> As a service owner who has chosen to run the service out of git
> for other reasons, I don't really care. But someone who wants to run
> the service from packages might have a different view.
In my very limited experience with containers the
Tollef Fog Heen writes ("Re: concerns about Salsa"):
> Russell Stuart :
> > [on service owners not having root on DSA-managed service hosts:]
> >
> > I accept that's doesn't leave the Salsa team with much choice, but it
> > still leaves me scratch
]] Russell Stuart
> On Thu, 2018-06-07 at 18:14 +0200, Tollef Fog Heen wrote:
> > Packages does not imply automation (lots of people maintain machines
> > by logging into each one and running apt by hand and $EDITOR on their
> > configuration files; I suspect this applies to the majority of
> > d
On 06/08/2018 12:46 AM, Russell Stuart wrote:
> Wordpress sites using the
> Debian package with unattended upgrades installed would likely have
> been patched before news of the exploit made the headlines.
And those running a simply unzipped version will also receive automated
upgrade from upstrea
On Fri, Jun 8, 2018 at 8:31 PM, Russell Stuart wrote:
> I didn't realise Wordpress had an auto-upgrade system. That put's in
> the same league as the Browsers like Chrome and Firefox. I'm
> impressed.
>
> However, it's not the same service that Debian offers. Wordpress has
> an auto upgrade sys
On Fri, 2018-06-08 at 10:11 +0800, Paul Wise wrote:
> In my experience the Wordpress upstream auto-upgrade system is
> typically faster than the Debian's handling of Wordpress.
I didn't realise Wordpress had an auto-upgrade system. That put's in
the same league as the Browsers like Chrome and Fir
On Fri, Jun 8, 2018 at 6:46 AM, Russell Stuart wrote:
> I'll drive the point home with yesterdays (literally yesterdays)
> headline: "Three months later, a mass exploit of powerful Web servers
> continues". The headline is referring to the 1000's of unpatched
> Drupal servers out there, unpatched
On Thu, 2018-06-07 at 18:14 +0200, Tollef Fog Heen wrote:
> Packages does not imply automation (lots of people maintain machines
> by logging into each one and running apt by hand and $EDITOR on their
> configuration files; I suspect this applies to the majority of
> desktops and laptops by people
On 2018-06-07 18:48:58 +0200 (+0200), Tollef Fog Heen wrote:
[...]
> So while we're not likely to have many deployments of each
> service, lowering the bar for setting up services, defining a very
> clear boundary between the service and its surroundings and making
> service development much easier
]] Russ Allbery
I agree with the points in your mail, but I wanted to expand slightly on
where I think Debian stands in the scale you described.
> I think people's varying reactions on this thread may have a lot to do
> with where they are in this hierarchy of scale, and what problems they
> the
]] Russell Stuart
> On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote:
> > Packages are great for software which you can just install and use
> > without much fuss. That is often true for mature software. But for
> > services which are less mature, and more complex, and which have more
> > t
On June 4, 2018 6:27:13 PM GMT+05:30, Bastian Blank wrote:
> However, we actually pull in some external
>binaries, for node, yarn and go.
Newer versions of node and go are available via stretch-backports.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote:
> Packages are great for software which you can just install and use
> without much fuss. That is often true for mature software. But for
> services which are less mature, and more complex, and which have more
> tentacles, the admin is likely
On Tue, Jun 05, 2018 at 10:24:20AM -0700, Russ Allbery wrote:
> My personal experience is that there is an interesting cycle of scale
> here.
[...]
This entire email is roughly what I was trying to say, only (as usual
for Russ) much more clearly put. Thanks.
> More broadly, one useful way to thi
Colin Watson writes:
> My experience has been that if I'm working on a complex service then I
> want as little friction as possible for the fast-moving stuff that I'm
> working on directly and so often end up deploying that straight from git
> or whatever, but that I prefer to use packages for ev
Bastian Blank writes ("Re: concerns about Salsa"):
> On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> > Salsa is hardly the first Debian production service to not be running
> > the packaged version of its primary application, and it won't be the
&
Pierre-Elliott Bécue writes ("Re: concerns about Salsa"):
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > In practice, I have found that it is much easier to deploy a
> > production service directly from its git tree. This makes it much
> > ea
Colin Watson writes ("Re: concerns about Salsa"):
> On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> > I wonder then, if a lot of people prefer deploy a service from
> > upstream's git repo/cookbooks, what is the purpose of packaging?
> &g
Wookey writes ("Re: concerns about Salsa"):
> Buildds don't run the packaged version either, and this contributes to
> it being much harder than it should be to set up local buildd
> infrastructure. There are good reasons for this from the admin's POV,
> but the sid
Quoting Pierre-Elliott Bécue :
I've always found otherwise, ie that packaged stuff makes the administrator
of a service spare a lot of time.
Same here, but it's a matter of taste and requirement diversity.
I wonder then, if a lot of people prefer deploy a service from upstream's
git repo/cook
On Tue, Jun 5, 2018 at 2:37 PM, Pierre-Elliott Bécue wrote:
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
>>
>> In practice, I have found that it is much easier to deploy a
>> production service directly from its git tree. This makes it much
>> easier to make changes.
>
> I've alw
On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > In practice, I have found that it is much easier to deploy a
> > production service directly from its git tree. This makes it much
> > easier to make changes.
>
On Tue, Jun 05, 2018 at 02:37:16PM +0200, Pierre-Elliott Bécue wrote:
> I wonder then, if a lot of people prefer deploy a service from upstream's
> git repo/cookbooks, what is the purpose of packaging? Who would benefit from
> it and who should use package-distros?
Yes, it's a more and more importa
Le lundi 04 juin 2018 à 12:54:32+0100, Ian Jackson a écrit :
> > Aren't we sending a wrong message that packaging is not important?
>
> In practice, I have found that it is much easier to deploy a
> production service directly from its git tree. This makes it much
> easier to make changes.
I've
On 2018-06-05 00:12, Wookey wrote:
On 2018-06-04 21:52 +, Clint Adams wrote:
On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ft
Dmitry Smirnov writes:
> Do you think there will be a potential to move services to containers,
> probably on "rkt" runtime[*] ?
rkt is neither in testing nor stable...
> [*]: Because Docker sucks...
Does rkt then suck more because it depends on docker stuff (at least in
Debian)? *scnr*
Ansgar
On Tue, 05 Jun 2018, Dmitry Smirnov wrote:
> On Tuesday, 5 June 2018 3:45:42 PM AEST Alexander Wirt wrote:
> > We don't have root.
>
> That actually makes sense... I didn't realize that Salsa is locked so tightly
> that even you don't have root access... That makes things much harder than it
>
On Tuesday, 5 June 2018 3:45:42 PM AEST Alexander Wirt wrote:
> We don't have root.
That actually makes sense... I didn't realize that Salsa is locked so tightly
that even you don't have root access... That makes things much harder than it
should be...
Do you think there will be a potential to
On Tue, 05 Jun 2018, Dmitry Smirnov wrote:
> On Monday, 4 June 2018 10:08:00 PM AEST Alexander Wirt wrote:
> > It just doesn't packages - which were just not available at the
> > time we needed them (the available package were several major versions
> > behind).
>
> IMHO it should have create eno
On Tue, 05 Jun 2018, Dmitry Smirnov wrote:
> On Monday, 4 June 2018 11:25:41 PM AEST Alexander Wirt wrote:
> > Please don't expect us to ever switch to packages - that will not happen.
>
> That's an interesting statement. Why?
>
> Do you think Praveen did all the enormous effort of packaging Git
On Monday, 4 June 2018 11:25:41 PM AEST Alexander Wirt wrote:
> Please don't expect us to ever switch to packages - that will not happen.
That's an interesting statement. Why?
Do you think Praveen did all the enormous effort of packaging GitLab for
nothing? Do you reckon that packaging software
On Tue, Jun 5, 2018 at 9:05 AM, Dmitry Smirnov wrote:
> * dak is very internal to Debian project. We don't have to package it just
> for internal consumption.
dak is used by Debian derivatives (at least LiMux and Tanglu).
https://wiki.debian.org/Derivatives/CensusFull
--
bye,
pabs
https://wi
On Mon, Jun 4, 2018 at 6:29 PM, Dmitry Smirnov wrote:
> IMHO we should have been working on improving GitLab package in order to make
> is suitable for Salsa if it is not suitable already. What are the blockers?
In my opinion the biggest blocker is that, the node.js ecosystem is
not security supp
On Monday, 4 June 2018 9:54:32 PM AEST Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ftp.debian.org isn't running the packaged version of dak.
I think dak is quite different
On Monday, 4 June 2018 10:08:00 PM AEST Alexander Wirt wrote:
> It just doesn't packages - which were just not available at the
> time we needed them (the available package were several major versions
> behind).
IMHO it should have create enough incentive to (help) updating gitlab package
and the
On 2018-06-04 21:52 +, Clint Adams wrote:
> On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> > Salsa is hardly the first Debian production service to not be running
> > the packaged version of its primary application, and it won't be the
> > last. ftp.debian.org isn't running the
On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ftp.debian.org isn't running the packaged version of dak.
No, this has been happening
On Mon, 04 Jun 2018, Thomas Goirand wrote:
> On 06/04/2018 12:29 PM, Dmitry Smirnov wrote:
> > GitLab is the right technology for us and a good improvement comparing to
> > Alioth.
> >
> > I think it is great that we've chosen GitLab as successor to Alioth but how
> > would it make you feel if
Hi Ian
On Mon, Jun 04, 2018 at 12:54:32PM +0100, Ian Jackson wrote:
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its primary application, and it won't be the
> last. ftp.debian.org isn't running the packaged version of dak.
Running packaged ve
On 06/04/2018 12:29 PM, Dmitry Smirnov wrote:
> GitLab is the right technology for us and a good improvement comparing to
> Alioth.
>
> I think it is great that we've chosen GitLab as successor to Alioth but how
> would it make you feel if you were told that Salsa is not running on Debian?
>
>
On Mon, 04 Jun 2018, eamanu15 wrote:
> El lun., 4 de jun. de 2018 a la(s) 09:08, Alexander Wirt <
> formo...@debian.org> escribió:
>
> > On Mon, 04 Jun 2018, eamanu15 wrote:
> >
> > > I think it's a low blow to us.
> > >
> > > I think this should have been known from the beginning. We need each o
El lun., 4 de jun. de 2018 a la(s) 09:08, Alexander Wirt <
formo...@debian.org> escribió:
> On Mon, 04 Jun 2018, eamanu15 wrote:
>
> > I think it's a low blow to us.
> >
> > I think this should have been known from the beginning. We need each of
> the
> > Debian projects, intervene the Debian itse
On Mon, 04 Jun 2018, Ian Jackson wrote:
> Dmitry Smirnov writes ("concerns about Salsa"):
> > Imagine my surprise when I've found that Salsa is not using our own
> > GitLab package at all.
>
> Salsa is hardly the first Debian production service to not be running
> the packaged version of its prim
On Mon, 04 Jun 2018, eamanu15 wrote:
> I think it's a low blow to us.
>
> I think this should have been known from the beginning. We need each of the
> Debian projects, intervene the Debian itself.
>
> Why don't start a new Debian project similar to GitLab, but based on Debian
> OS.
of course it
Dmitry Smirnov writes ("concerns about Salsa"):
> Imagine my surprise when I've found that Salsa is not using our own
> GitLab package at all.
Salsa is hardly the first Debian production service to not be running
the packaged version of its primary application, and it won't be the
last. ftp.debia
I think it's a low blow to us.
I think this should have been known from the beginning. We need each of the
Debian projects, intervene the Debian itself.
Why don't start a new Debian project similar to GitLab, but based on Debian
OS.
Regards!
Emmanuel
El lun., 4 de jun. de 2018 a la(s) 07:47, Dm
48 matches
Mail list logo
