>
>
> But ok, maybe my thinking is too much influenced from the SLES
> release process
> at SUSE which ships with a rather limited set of packages which are
> guaranteed
> to work and are officially supported.
>
> Adrian
>
The problem I found using SLES and Redhat, which both had excellent
On 3/3/21 9:09 AM, Wouter Verhelst wrote:
> I don't agree with the statement that doing things like this is a bad
> idea. Sometimes doing the minimal necessary to make a package work again
> so that our future needs will still be served by it is a good idea. I
> think that this is one of those
So.
On Sun, Feb 07, 2021 at 01:40:39PM +0100, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release. The packages get small
> patches so that they are more or less working and
Adrian Bunk writes:
> On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote:
>> and instead try to track positive attributes like fitness for
>> release, though?
>
> Can you provide a less lofty description of what you want to implement?
I didn't suggest that anything be implemented.
On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote:
>
> Wouldn't it be quite the massive paradigm shift to give up on the notion
> of tracking problems (= bugs),
The only bugs that are actually being tracked are RC bugs.
In practice the majority of RC bugs are FTBFS,
which we don't
On 08/02/2021 12:52, Matthias Klose wrote:
On 2/7/21 3:20 PM, David Bremner wrote:
John Paul Adrian Glaubitz writes:
It shouldn't be enough for a package to have its worst bugs fixed like FTBFS or
crashes when it gets shipped with a release. Packages that are being shipped
with
a release
On 2/7/21 3:20 PM, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
>> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS
>> or
>> crashes when it gets shipped with a release. Packages that are being shipped
>> with
>> a release should also be properly
On Sun, Feb 07, 2021 at 07:41:01PM +0500, Andrey Rahmatullin wrote:
> On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
> > > the packages being untouched for a long time in some cases meaning there
> > > is
> > > no guarantee for quality.
> >
> > Sure, but if there is no serious
On Sun, Feb 7, 2021 at 4:45 PM Andrey Rahmatullin wrote:
> "make sure everything we ship in testing was checked manually before
> migrating"?).
The Debian CD team has an in-progress tool called ditto that is aimed
at manual testing, currently for CD images. Potentially it or
something like it
On Sun, Feb 7, 2021 at 4:20 PM Gard Spreemann wrote:
> Wouldn't it be quite the massive paradigm shift to give up on the notion
> of tracking problems (= bugs), and instead try to track positive
> attributes like fitness for release, though?
This is something that is already happening a bit in
Le 07/02/2021 à 19:27, Russ Allbery a écrit :
> The more interesting question is what if there simply isn't resources to
> adopt them and maintain them properly. In that case, are we better off
> with them, or without them?
>
> I don't think this answer is obvious, but I would lean towards
Andrey Rahmatullin writes:
> On Sun, Feb 07, 2021 at 10:25:26AM -0800, Russ Allbery wrote:
>> To me, the rewards of keeping the orphaned packages clearly outweigh
>> the risks. If the package is actually broken, presumably sooner or
>> later someone will notice and report that as a bug, and we
On Sun, Feb 07, 2021 at 10:25:26AM -0800, Russ Allbery wrote:
> To me, the rewards of keeping the orphaned packages clearly outweigh the
> risks. If the package is actually broken, presumably sooner or later
> someone will notice and report that as a bug, and we can then take
> appropriate
John Paul Adrian Glaubitz writes:
> On 2/7/21 3:20 PM, David Bremner wrote:
>> John Paul Adrian Glaubitz writes:
>>> It shouldn't be enough for a package to have its worst bugs fixed like
>>> FTBFS or crashes when it gets shipped with a release. Packages that
>>> are being shipped with a
Andrey Rahmatullin writes:
> Strictly speaking, there is a big logical error here.
> If a package doesn't have RC bugs that doesn't mean it's fit for a
> stable release, doesn't have serious issues, or even is usable.
Yes, but if no one has reported any serious issues, I think we should
assume
On Sun, Feb 07, 2021 at 05:19:17PM +0100, Gard Spreemann wrote:
> >> > the packages being untouched for a long time in some cases meaning there
> >> > is
> >> > no guarantee for quality.
> >>
> >> Sure, but if there is no serious issue left with the package, we can as
> >> well ship it.
> >
Andrey Rahmatullin writes:
> On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
>> > the packages being untouched for a long time in some cases meaning there is
>> > no guarantee for quality.
>>
>> Sure, but if there is no serious issue left with the package, we can as
>> well
Andrey Rahmatullin, le dim. 07 févr. 2021 19:41:01 +0500, a ecrit:
> On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
> > > the packages being untouched for a long time in some cases meaning there
> > > is
> > > no guarantee for quality.
> >
> > Sure, but if there is no serious
On Sun, Feb 07, 2021 at 10:20:19AM -0400, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
> > It shouldn't be enough for a package to have its worst bugs fixed like
> > FTBFS or
> > crashes when it gets shipped with a release. Packages that are being
> > shipped with
> > a release
On Sun, Feb 07, 2021 at 01:40:39PM +0100, John Paul Adrian Glaubitz wrote:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release.
what does 'large' mean here? 23? 230? 2300? >9000?
also, how many source packages & how
On Sun, Feb 07, 2021 at 01:40:39PM +0100, John Paul Adrian Glaubitz wrote:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release. The packages get small
> patches so that they are more or less working and can get into
On Sun, Feb 07, 2021 at 03:42:54PM +0100, John Paul Adrian Glaubitz wrote:
> >> It shouldn't be enough for a package to have its worst bugs fixed like
> >> FTBFS or
> >> crashes when it gets shipped with a release. Packages that are being
> >> shipped with
> >> a release should also be properly
On Sun, Feb 07, 2021 at 10:20:19AM -0400, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
> > It shouldn't be enough for a package to have its worst bugs fixed like
> > FTBFS or
> > crashes when it gets shipped with a release. Packages that are being
> > shipped with
> > a release
On 2/7/21 3:20 PM, David Bremner wrote:
> John Paul Adrian Glaubitz writes:
>
>> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS
>> or
>> crashes when it gets shipped with a release. Packages that are being shipped
>> with
>> a release should also be properly
On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
> > the packages being untouched for a long time in some cases meaning there is
> > no guarantee for quality.
>
> Sure, but if there is no serious issue left with the package, we can as
> well ship it.
Strictly speaking, there is a
John Paul Adrian Glaubitz writes:
> It shouldn't be enough for a package to have its worst bugs fixed like FTBFS
> or
> crashes when it gets shipped with a release. Packages that are being shipped
> with
> a release should also be properly maintained or not shipped at all.
For context, there
Hello,
Just answering the subject.
John Paul Adrian Glaubitz, le dim. 07 févr. 2021 13:40:39 +0100, a ecrit:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release.
I don't think this is related to fixing the release
John Paul Adrian Glaubitz writes:
> If the packages in question are essential, then these packages should get a
> proper
> maintainer with a maintenance release first before the freeze kicks in.
How does that happen?
Bjørn
Hello!
I just noticed how maintainers are NMU'ing packages in large quantities to
get them somehow in a usable state for the release. The packages get small
patches so that they are more or less working and can get into testing, despite
the packages being untouched for a long time in some cases
29 matches
Mail list logo
