Re: Towards Excellent Defect Management
On Friday, 17 September 2021 00:46:33 CEST Aleix Pol wrote:
> On Tue, Sep 14, 2021 at 5:23 PM Harald Sitter wrote:
> > server-side retracing. I've spent many afternoons reading up on and
> > poking demo instances of every somewhat suitable software I could
> > find, and Sentry looks like the best option for what we need. It is
> > practically free software as far as we are concerned, scales
> > tremendously, has systems for server-side deduplication, server-side
> > cross-distro/platform retracing (which might also help with some of
https://open.sentry.io/licensing/
It's refreshing to read a straightforward take on this. And indeed, BSL 1.1 is
**not** OSI-approved (I've watched plenty of the internal discussions about it
and similar licenses) because it falls foul of freedom 0: the freedom to use
the software for any purpose. That's roughly the same reason the "do no evil"
license isn't OSI-approved ("but daaad, I *want* to do evil!").
> +1 makes sense to me, it's exciting to find new ways that people can
> help make our software better without a big effort.
>
> I'd say the purpose of our manifesto clause that we need to rely
> exclusively on FOSS tools wasn't designed for cases like this one.
+1 to that, yes.
[ade] (pragmatically)
signature.asc
Description: This is a digitally signed message part.
Re: Towards Excellent Defect Management
On Tue, Sep 14, 2021 at 5:23 PM Harald Sitter wrote: > > For many years now I've been unhappy with both the quality and volume > of crash reports we get for our software. The barrier for crash report > submissions is incredibly high because we've never really had tech to > help elevate "insufficient" reports to become sufficient, outside the > client on which the crash occurred. Out of the very few people that > might want to report a crash even fewer will get beyond the first set > of questions from drkonqi, once they've managed they still have to > fight with their distro for debug symbols and quite possibly lose, and > even if they win there is a good chance the report will either get a > "this isn't very useful. install more symbols" comment or get marked > as dupe. Meanwhile we are spending our days looking at duplicated > crashes, or finding the right blurb to copy paste to ask for a better > trace, or try to find out why software crashes that hasn't actually > crashed for a year because the bug had already been fixed in the > meantime. > > We are wasting our users' time. We are wasting our time. This waste > needs to stop. > > The good news is that we have all the technical building blocks to fix > it today. In fact, it's even getting better in the future still. All > it takes is a bit of code and a bit of flexibility on our part. > > A while ago I started looking into improving the drkonqi experience. > Specifically: submitting crash reports into a purpose built crash > tracking system rather than a bug tracking system. The advantages are > kind of obvious and ranging from server-side de-duplication to > server-side retracing. I've spent many afternoons reading up on and > poking demo instances of every somewhat suitable software I could > find, and Sentry looks like the best option for what we need. It is > practically free software as far as we are concerned, scales > tremendously, has systems for server-side deduplication, server-side > cross-distro/platform retracing (which might also help with some of > the open questions of richer tracing for windows and android), data > scrubbing (what with privacy concerns), client and server-side tags, > can try to figure out when a crash first appeared if supplied with > commit data, can track the quality of specific releases, when a given > crash was fixed, health reports, performance tracking, warning rules, > health report emails, ... I've been playing with it for a month and > still find amazing new things! > > One of the best things about Sentry is that it has native support for > debuginfod, enabling us to get debug symbols directly from > distributions, solving the entire cross-distro aspect of crash tracing > in just about the neatest way possible. We get the (incomplete) trace > with lots of metadata, and Senty then uses the metadata to resolve the > symbols through the distros' debuginfod instances to give us a > complete trace. > > Even better: with relatively minor adjustments to drkonqi we could use > it right now and get immediate advantage of server-side retracing! I > already have a blob of prototype code for drkonqi that piggybacks > Sentry submission onto the existing code such that we can have both > bugzilla and Sentry. > > I am proposing that we roll out a Sentry instance for testing so we > can see if we want to fully embrace it. > > You can get a general sense of the features at Sentry's demo instance > https://sentry.io/demo/sandbox/ > Here's a code dump for drkonqi > https://invent.kde.org/sitter/drkonqi/-/commits/work/sentry > > HS +1 makes sense to me, it's exciting to find new ways that people can help make our software better without a big effort. I'd say the purpose of our manifesto clause that we need to rely exclusively on FOSS tools wasn't designed for cases like this one. Thanks for bringing it up! Aleix
Re: Towards Excellent Defect Management
Most of Sentry is licensed under the BSL (Business Source License), which prohibits using the software to create your own commercial service providing "Application Monitoring Services" (https://github.com/getsentry/sentry/blob/master/LICENSE). This is not an OSI-approved license. The issue whether such a license would be acceptable to use in KDE infrastructure has come up a few months back, in the thread "is a BSL licensed service acceptable for sysadminy use cases?" which was started on the 26.05 (https://marc.info/?t=16220380561=1=2). There was no real conclusion in the thread. Personally I'd be fine with BSL, since for all purposes of KDE, it is indeed free software, but I understand that some people would prefer a true OSI license. The license Sentry uses also includes a "timebomb" clause that releases all code under Apache 2.0 after 4 years. It seems difficult to use a 4 year old version of a piece of software that is exposed online, but it could potentially be a true FOSS option. Cheers, Julian / xyquadrat On 14.09.21 19:34, Albert Astals Cid wrote: El dimarts, 14 de setembre de 2021, a les 17:23:01 (CEST), Harald Sitter va escriure: It is practically free software as far as we are concerned I guess this means it's not actually Free Software? Cheers, Albert
Re: Towards Excellent Defect Management
On 9/14/21 11:43, Julian / xyquadrat wrote: Most of Sentry is licensed under the BSL (Business Source License), which prohibits using the software to create your own commercial service providing "Application Monitoring Services" (https://github.com/getsentry/sentry/blob/master/LICENSE). This is not an OSI-approved license. The issue whether such a license would be acceptable to use in KDE infrastructure has come up a few months back, in the thread "is a BSL licensed service acceptable for sysadminy use cases?" which was started on the 26.05 (https://marc.info/?t=16220380561=1=2). There was no real conclusion in the thread. Personally I'd be fine with BSL, since for all purposes of KDE, it is indeed free software, That's more or less my opinion on the matter. Nate
Re: Towards Excellent Defect Management
On Wed, Sep 15, 2021 at 7:06 AM Albert Astals Cid wrote: > El dimarts, 14 de setembre de 2021, a les 20:35:40 (CEST), Ben Cooksley va > escriure: > > On Wed, Sep 15, 2021 at 5:35 AM Albert Astals Cid wrote: > > > > > El dimarts, 14 de setembre de 2021, a les 17:23:01 (CEST), Harald > Sitter > > > va escriure: > > > > It is practically free software as far as we are concerned > > > > > > I guess this means it's not actually Free Software? > > > > > > > Please see https://open.sentry.io/licensing/ > > > > The tl;dr is that the license it is provided under (BSL 1.1) is not OSI > > approved due to the restriction on it's use by cloud vendors (ie. it has > an > > anti-AWS clause). > > That restriction lapses after 36 months, at which point it is Apache 2.0 > > compatible. > > > > Based on what Harald has written earlier, it looks like Sentry is the > only > > suitable game in town for what we need - the only question is whether we > > are happy to make use of BSL 1.1 licensed software given that we have > > traditionally only deployed 100% open source software to our systems > (which > > is why we use Gitlab CE over Gitlab EE) > > Oh i feel we already discussed this in the past, right? > > Sorry for bringing it up again then :) > I've checked my mail archives and there was a public discussion regarding Sentry/BSL earlier yes - however it didn't reach a conclusion, it was deferred to a BoF. That was for server/infrastructure event monitoring as well, rather than crash handling. > Cheers, > Albert > Cheers, Ben > > > > > > > Cheers, > > > Albert > > > > > > > > > > > Cheers, > > Ben > > > > > > >
Re: Towards Excellent Defect Management
El dimarts, 14 de setembre de 2021, a les 20:35:40 (CEST), Ben Cooksley va escriure: > On Wed, Sep 15, 2021 at 5:35 AM Albert Astals Cid wrote: > > > El dimarts, 14 de setembre de 2021, a les 17:23:01 (CEST), Harald Sitter > > va escriure: > > > It is practically free software as far as we are concerned > > > > I guess this means it's not actually Free Software? > > > > Please see https://open.sentry.io/licensing/ > > The tl;dr is that the license it is provided under (BSL 1.1) is not OSI > approved due to the restriction on it's use by cloud vendors (ie. it has an > anti-AWS clause). > That restriction lapses after 36 months, at which point it is Apache 2.0 > compatible. > > Based on what Harald has written earlier, it looks like Sentry is the only > suitable game in town for what we need - the only question is whether we > are happy to make use of BSL 1.1 licensed software given that we have > traditionally only deployed 100% open source software to our systems (which > is why we use Gitlab CE over Gitlab EE) Oh i feel we already discussed this in the past, right? Sorry for bringing it up again then :) Cheers, Albert > > > > Cheers, > > Albert > > > > > > > Cheers, > Ben >
Re: Towards Excellent Defect Management
On Wed, Sep 15, 2021 at 5:35 AM Albert Astals Cid wrote: > El dimarts, 14 de setembre de 2021, a les 17:23:01 (CEST), Harald Sitter > va escriure: > > It is practically free software as far as we are concerned > > I guess this means it's not actually Free Software? > Please see https://open.sentry.io/licensing/ The tl;dr is that the license it is provided under (BSL 1.1) is not OSI approved due to the restriction on it's use by cloud vendors (ie. it has an anti-AWS clause). That restriction lapses after 36 months, at which point it is Apache 2.0 compatible. Based on what Harald has written earlier, it looks like Sentry is the only suitable game in town for what we need - the only question is whether we are happy to make use of BSL 1.1 licensed software given that we have traditionally only deployed 100% open source software to our systems (which is why we use Gitlab CE over Gitlab EE) > Cheers, > Albert > > > Cheers, Ben
Re: Towards Excellent Defect Management
El dimarts, 14 de setembre de 2021, a les 17:23:01 (CEST), Harald Sitter va escriure: > It is practically free software as far as we are concerned I guess this means it's not actually Free Software? Cheers, Albert
Towards Excellent Defect Management
For many years now I've been unhappy with both the quality and volume of crash reports we get for our software. The barrier for crash report submissions is incredibly high because we've never really had tech to help elevate "insufficient" reports to become sufficient, outside the client on which the crash occurred. Out of the very few people that might want to report a crash even fewer will get beyond the first set of questions from drkonqi, once they've managed they still have to fight with their distro for debug symbols and quite possibly lose, and even if they win there is a good chance the report will either get a "this isn't very useful. install more symbols" comment or get marked as dupe. Meanwhile we are spending our days looking at duplicated crashes, or finding the right blurb to copy paste to ask for a better trace, or try to find out why software crashes that hasn't actually crashed for a year because the bug had already been fixed in the meantime. We are wasting our users' time. We are wasting our time. This waste needs to stop. The good news is that we have all the technical building blocks to fix it today. In fact, it's even getting better in the future still. All it takes is a bit of code and a bit of flexibility on our part. A while ago I started looking into improving the drkonqi experience. Specifically: submitting crash reports into a purpose built crash tracking system rather than a bug tracking system. The advantages are kind of obvious and ranging from server-side de-duplication to server-side retracing. I've spent many afternoons reading up on and poking demo instances of every somewhat suitable software I could find, and Sentry looks like the best option for what we need. It is practically free software as far as we are concerned, scales tremendously, has systems for server-side deduplication, server-side cross-distro/platform retracing (which might also help with some of the open questions of richer tracing for windows and android), data scrubbing (what with privacy concerns), client and server-side tags, can try to figure out when a crash first appeared if supplied with commit data, can track the quality of specific releases, when a given crash was fixed, health reports, performance tracking, warning rules, health report emails, ... I've been playing with it for a month and still find amazing new things! One of the best things about Sentry is that it has native support for debuginfod, enabling us to get debug symbols directly from distributions, solving the entire cross-distro aspect of crash tracing in just about the neatest way possible. We get the (incomplete) trace with lots of metadata, and Senty then uses the metadata to resolve the symbols through the distros' debuginfod instances to give us a complete trace. Even better: with relatively minor adjustments to drkonqi we could use it right now and get immediate advantage of server-side retracing! I already have a blob of prototype code for drkonqi that piggybacks Sentry submission onto the existing code such that we can have both bugzilla and Sentry. I am proposing that we roll out a Sentry instance for testing so we can see if we want to fully embrace it. You can get a general sense of the features at Sentry's demo instance https://sentry.io/demo/sandbox/ Here's a code dump for drkonqi https://invent.kde.org/sitter/drkonqi/-/commits/work/sentry HS
