Am 19.09.22 um 14:57 schrieb Neal Gompa:
On Sat, Sep 10, 2022 at 5:41 AM Reindl Harald wrote:
Am 09.09.22 um 11:42 schrieb samuel ammonius:
Thanks. I hadn't thought of a lot of these issues before.
I think the biggest one is that If there's an update that the package
manager didn'tknow
On Sat, Sep 10, 2022 at 5:41 AM Reindl Harald wrote:
>
>
>
> Am 09.09.22 um 11:42 schrieb samuel ammonius:
> > Thanks. I hadn't thought of a lot of these issues before.
> >
> > I think the biggest one is that If there's an update that the package
> > manager didn'tknow about, the user would have
Am 09.09.22 um 11:42 schrieb samuel ammonius:
Thanks. I hadn't thought of a lot of these issues before.
I think the biggest one is that If there's an update that the package
manager didn'tknow about, the user would have to update right after installing, and
the bug would come back if the
Thanks. I hadn't thought of a lot of these issues before.
I think the biggest one is that If there's an update that the package
manager didn't
know about, the user would have to update right after installing, and the
bug would
come back if the user re-installed or updated the app. Sorry
On Thu, Sep 8, 2022 at 12:51 PM samuel ammonius
wrote:
> Bug fixes don't change the entire package, only the executable, so
> why can't apps just be programmed to update themselves? There
> could be precompiled binaries stored on the git repos of each project
> for a few CPU architectures, or
I'm sad other emails sound kinda harsh and without detailed elaboration. Folks,
please, let's keep the discussion peaceful. Different people have different set
of knowledge, that's life. Angry comments would push people away from the
community.
On Thu, 2022-09-08 at 19:23 -0230, samuel ammonius
Am 08.09.22 um 23:53 schrieb samuel ammonius:
> and you marry upstream binaries with the distribution update-manager how?
You don't need to. The app can just check the latest bugfix for that
version on git
and install it if it isn't installed. I don't understand why you stress
the need
> and you marry upstream binaries with the distribution update-manager how?
You don't need to. The app can just check the latest bugfix for that
version on git
and install it if it isn't installed. I don't understand why you stress the
need for the
package manager to have anything to do with the
Am 08.09.22 um 22:24 schrieb samuel ammonius:
> because outside the windows world central package management is the norm
> and based on "least privileges" applications must not have the
> permissions to change itself
I didn't mean a background update. I meant the user could get a dialog
> because outside the windows world central package management is the norm
> and based on "least privileges" applications must not have the
> permissions to change itself
I didn't mean a background update. I meant the user could get a dialog or
notification asking them to update, and if they
Am 08.09.22 um 20:50 schrieb samuel ammonius:
Bug fixes don't change the entire package, only the executable, so
why can't apps just be programmed to update themselves?
because outside the windows world central package management is the norm
and based on "least privileges" applications
Bug fixes don't change the entire package, only the executable, so
why can't apps just be programmed to update themselves? There
could be precompiled binaries stored on the git repos of each project
for a few CPU architectures, or maybe the app could even recompile
itself inside /tmp since most
On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote:
From the git-archive manual page:
«git archive behaves differently when given a tree ID versus
when given a commit ID or tag ID. In the first case the current
time is used as the modification time of each file in the
archive. In
On 9/8/22 05:51, Nicolas Fella wrote:
Hi,
I don't think Nate or anyone wants to propose a strict policy that when
X then Y has to happen. That's just not how we operate in KDE. I do
think it is valuable though to discuss and create some guidelines/shared
understanding/soft policy that
On 8/9/22 13:51, Nicolas Fella wrote:
Hi,
I don't think Nate or anyone wants to propose a strict policy that when
X then Y has to happen. That's just not how we operate in KDE. I do
think it is valuable though to discuss and create some guidelines/shared
understanding/soft policy that
Hi,
I don't think Nate or anyone wants to propose a strict policy that when
X then Y has to happen. That's just not how we operate in KDE. I do
think it is valuable though to discuss and create some guidelines/shared
understanding/soft policy that maintainers can use as a reference when
making
Hi,
I think all 3 of us envision very similar things, we just have different
things we think/talk about, and different understandings of Nate's
suggestion. I for example understood that Nate suggests to make bugs
matching the named criteria the *trigger* for making (or discussing) a
new
On Thu, Sep 8, 2022 at 8:30 AM Sven Brauch wrote:
>
> Hi,
>
> On 9/7/22 17:28, Harald Sitter wrote:
> > On Wed, Sep 7, 2022 at 5:20 PM wrote:
> >> In most projects the maintainers who'd make a release decision are the
> >> same people who triage bugs
> >
> > You quite clearly have no idea how
I'm sorry, I neither wanted to upset nor insult.
frameworks has 83 projects, plasma has 65 projects, release service
has 297 = 445 projects to which your blanket statement does not apply.
Their releases run on rails, that's why Nate suggests a way to
introduce additional stops, as it were.
On
Hi,
On 9/7/22 17:28, Harald Sitter wrote:
On Wed, Sep 7, 2022 at 5:20 PM wrote:
In most projects the maintainers who'd make a release decision are the
same people who triage bugs
You quite clearly have no idea how this community works. I'll thank
you not to misdirect discussions.
in kate
On 2022-09-07 16:28, Harald Sitter wrote:
On Wed, Sep 7, 2022 at 5:20 PM wrote:
In most projects the maintainers who'd make a release decision are the
same people who triage bugs
You quite clearly have no idea how this community works. I'll thank
you not to misdirect discussions.
Ta
I
On Wed, Sep 7, 2022 at 5:20 PM wrote:
> In most projects the maintainers who'd make a release decision are the
> same people who triage bugs
You quite clearly have no idea how this community works. I'll thank
you not to misdirect discussions.
Ta
On 2022-09-06 19:41, Nate Graham wrote:
To revive this thread, I think the issue is that it feels sort of
subjective what kind of bugs are bad enough that we think like a new
release is worth it. So maybe we can try to get specific and say that
we should make a new release for fixes of Bugzilla
To revive this thread, I think the issue is that it feels sort of
subjective what kind of bugs are bad enough that we think like a new
release is worth it. So maybe we can try to get specific and say that we
should make a new release for fixes of Bugzilla bug reports where:
- Priority is VHI
On 8/25/22 22:59, Albert Astals Cid wrote:
c) Who decides which bugs "are important" because for every bug, there's
always a person out there that thinks it's the most important bug ever.
d) What do we release? i.e. imagine we find one of those "important bugs" in
dolphin and we have to release
As a distro packaging it's much easier and more reliable to just let the
new version get added automatically to our builds. As a release manager it
shouldn't be any harder to automate making a new bugfix release. I do this
already for Plasma when requested. It should be the default method.
El dijous, 25 d’agost de 2022, a les 18:55:08 (CEST), Nate Graham va escriure:
> Hello everyone,
> Right now when we fix a significant bug in our software that may take a
> while to reach users to to the release schedule of its repo, we contact
> distros and ask them to backport it. This puts the
Same here, I like the idea of point releases to fix impactful bugs.
On Thu, Aug 25, 2022 at 6:56 PM Harald Sitter wrote:
> make sense to me
>
> On Thu, Aug 25, 2022 at 6:55 PM Nate Graham wrote:
> >
> > Hello everyone,
> > Right now when we fix a significant bug in our software that may take a
make sense to me
On Thu, Aug 25, 2022 at 6:55 PM Nate Graham wrote:
>
> Hello everyone,
> Right now when we fix a significant bug in our software that may take a
> while to reach users to to the release schedule of its repo, we contact
> distros and ask them to backport it. This puts the burden
Hello everyone,
Right now when we fix a significant bug in our software that may take a
while to reach users to to the release schedule of its repo, we contact
distros and ask them to backport it. This puts the burden on distros to
react to us. I'm wondering how people feel about KDE instead
30 matches
Mail list logo
