Re: Fixed release dates are hurting quality

[John Lines]

> 
> 
> 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
support for their core packages, is that all the tricky problems you
encounter in real life come from software which is outside the
supported set.

Once you start using third party RPMs you are in a worse state that
using a Debian package which has fallen out of active maintenance, in
that at least old packages met policy at some time in the past.

If the Debian maintainer has moved on to other areas of interest, and
another maintainer finds something they use is in danger of dropping
out of a release then that implies the package was used by at least two
Debian developers, so there is a high chance it is actually helping
many more people who are not developers, and so keeping it in Debian
seems to me a net benefit.

John

Re: Fixed release dates are hurting quality

[John Paul Adrian Glaubitz]

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 times, and I guess that it's the same
> for most of the packages uploaded like that.

Sure, you don't have to agree with my stance on this. I think it's better
to not ship something at all than to ship something with a hotpatch that
hasn't been touched for a long time.

After all, users expect packages that are shipped with a release to meet
certain quality standards and I would say that chances are not zero that
such a package which hasn't been touched for a longer time will have other
problems that may warrant further action of the security team in the future.

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

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fixed release dates are hurting quality

[Wouter Verhelst]

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 can get into testing,
> despite the packages being untouched for a long time in some cases meaning
> there is no guarantee for quality.

I was one of these maintainers.

gridengine has been in Debian since 2008, and the version in Buster
works well. I don't have time to maintain it, but I do use it often, and
some of the work I do for the debconf and FOSDEM video teams relies on
it being available.

It was pointed out to me shortly before the freeze that it was not in
bullseye because of a "FTBFS with gcc-10" bug for which a (rather
trivial) patch was already available. Unfortunately it turned out that
that patch wasn't sufficient, so I had to repeat the pattern one more
time to make it work. The patch is *still* very trivial though.

There is now a gridengine package in Bullseye again, and it works as
well as it did in Buster.

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 times, and I guess that it's the same
for most of the packages uploaded like that.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Fixed release dates are hurting quality

[Gard Spreemann]

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. I (mis-)read the parent
message as suggesting that instead of absence of bugs being sufficient
for release, we should consider instead "presence of quality"
(anti-bugs, if you will). That felt like a major paradigm shift, but I
was misunderstanding.

 -- Gard


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Adrian Bunk]

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 want in a release in any case.

> 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?

>  -- Gard

cu
Adrian

Re: Fixed release dates are hurting quality

[Paul Sutton]

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 should also be properly maintained or not shipped at all.


For context, there are currently 929 packages maintained by
packa...@qa.debian.org. That doesn't count packages that have an
inactive maintainer, which is more challenging to quantify.


that also doesn't include any team-maintained package with inactive uploaders.




The current model seems to work, this seems to be release the next 
version of Debian every 2 years (when ready) then a point release update 
it seems every 2/3 months, other updates are released as and when needed.


I agree if there are major bugs these packages should not make it,  but 
would that encourage people to get involved and help or just moan that 
package x is no longer available.


Paul


--
Paul Sutton, Cert Cont Sci (Open)
https://personaljournal.ca/paulsutton/
OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99

Pronoun : him/his/he



OpenPGP_signature
Description: OpenPGP digital signature

Re: Fixed release dates are hurting quality

[Matthias Klose]

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 maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.

that also doesn't include any team-maintained package with inactive uploaders.

Re: Fixed release dates are hurting quality

[Andrew M.A. Cater]

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 issue left with the package, we can as
> > well ship it.
> 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.
> And if a package has an RC bug that doesn't mean it's not usable etc., it
> just means it has some problem that fits the definition of an RC bug (or,
> even, that doesn't, but nobody lowered the severity).
> But the project decided to use these criteria in the absence of better
> ones, just as the project decided to use obviously flawed popcon stats.
> 
> -- 
> WBR, wRAR

Several of those updates may also be down to h0lger mass updating packages so 
that they were built on buildds that could give reproducible build info.

Never ascribe to malice something that is entirely good, useful and 
well-intentioned :)

All the very best, as ever,

Andy Cater

Re: Fixed release dates are hurting quality

[Paul Wise]

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 could be adapted towards registering manual test
procedures and allowing folks to walk through those procedures and
record results. The release team could potentially use that
information as input into the testing migration process.

https://ditto.debian.net/
https://wiki.debian.org/Teams/DebianCd/ditto

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Fixed release dates are hurting quality

[Paul Wise]

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 Debian:

The Debian CD team are testing images before each release and point release.

https://wiki.debian.org/Teams/DebianCD/ReleaseTesting

At one point there was systematic testing of the secure boot stuff:

https://wiki.debian.org/SecureBoot/Testing

The LTS team have manualish testing of packages they fix security issues in:

https://wiki.debian.org/LTS/TestSuites

The u-boot maintainer/users record the status of various uploads:

https://wiki.debian.org/U-boot/Status

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Fixed release dates are hurting quality

[Alexis Murzeau]

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 saying
> we're better off with them.
> 

The recent re-upload of xserver-xorg-video-*
drivers is a good example of (maybe) unmaintained but useful packages.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955603

Several xserver-xorg-video-* (like xserver-xorg-video-r128) were
removed by this bug because:
> They are either unmaintained upstream or provide no value to the
> distribution.

But were still being useful for users as shown by these comments on
#955603:
> Please keep these drivers. They work as just fine, and many people
> still use them. They have not been dropped by upstream X.org, and there
> is no reason to drop them from Debian. Without these drivers, it will
> make running Debian desktop on this hardware impossible. One of the
> things that makes Debian great is the backward compatibility. It's very
> sad to see destructive actions like this being taken. Please don't just
> throw away all the work that people have put into these drivers over
> the years, and please don't orphan their users!

Another comment:
> those modules are STILL IN RECENT SERVERS like r128 (rage) and
> openchrome via boards
> 
> proliant hp and DELL ones!


These drivers were reintroduced last friday.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Re: Fixed release dates are hurting quality

[Russ Allbery]

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 can then
>> take appropriate action.

>> The exception, I suppose, is that we probably shouldn't keep shipping
>> packages that are orphaned and that no one is using, just on clutter
>> grounds, but that seems like a smaller problem that would be
>> better-handled by other mechanisms than a blanket rule for unmaintained
>> packages.

> There are also other, though I think rare, considerations, like security
> problems.

Yes, security is a worry, and security problems in orphaned packages fall
primarily on the security team instead of on the maintainer.  If there are
packages of concern to the security team from a supportability standpoint,
I certainly would support them in asking for them to be adopted or
removed.

Thankfully, most packages in the archive don't tend to have meaningful
security problems, in the sense that they don't listen to the network and
don't have unusual privileges, so are only likely to cause problems if
they're somehow run on untrusted input.  (Which was probably your point
about being rare.)

-- 
Russ Allbery (r...@debian.org)  

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 action.
> 
> The exception, I suppose, is that we probably shouldn't keep shipping
> packages that are orphaned and that no one is using, just on clutter
> grounds, but that seems like a smaller problem that would be
> better-handled by other mechanisms than a blanket rule for unmaintained
> packages.
There are also other, though I think rare, considerations, like security
problems.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Russ Allbery]

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 release should also be properly maintained or
>>> not shipped at all.

>> For context, there are currently 929 packages maintained by
>> packa...@qa.debian.org. That doesn't count packages that have an
>> inactive maintainer, which is more challenging to quantify.

> Yes, and I think that number 929 is already too high.

I think everyone agrees that it would be better if those packages were
adopted.  Forcing them to be adopted to remain in the distribution may
spark some adoption (although it may also backfire and spark adoption by
people seeking solely to keep them in the release but without any real
intent of working on them).

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 saying
we're better off with them.

-- 
Russ Allbery (r...@debian.org)  

Re: Fixed release dates are hurting quality

[Russ Allbery]

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 that it's usable.

Think of it in terms of a risk trade-off: If we toss orphaned packages or
packages with inactive maintainers, the upside is that we are less likely
to ship broken packages that have a low enough usage that no one has
reported the brokenness, and the downside is that we may remove packages
that someone is still using and cares about and that work fine for them.

If we keep those packages, the upside is that if they are working they
continue to work.  The downside is that they may be silently broken... but
in that case if no one is using them to know that they're broken, all
they're wasting is disk space and possibly an unpleasant surprise in the
rare case that someone stumbles across them.

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 action.

The exception, I suppose, is that we probably shouldn't keep shipping
packages that are orphaned and that no one is using, just on clutter
grounds, but that seems like a smaller problem that would be
better-handled by other mechanisms than a blanket rule for unmaintained
packages.

-- 
Russ Allbery (r...@debian.org)  

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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.
> > 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.
> 
> 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?
Sure, it would, and I'm not proposing it. Better QA would help us with
tracking bugs, on the other hand. It's debatable whether or not "better
QA" includes more of the manual testing (like "get more users"? "get more
users that are able to report bugs"? "do that by improving the reporting
experience"? "make sure people that are able to report bugs actually use
everything we ship in testing"? "make sure everything we ship in testing
was checked manually before migrating"?).

I'm also not sure what is the author of this thread proposing regarding
this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Gard Spreemann]

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 ship it.
> 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.

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?

 -- Gard
 


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Samuel Thibault]

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 issue left with the package, we can as
> > well ship it.
> 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.

If a package has serious issues or is unusable, that makes it an RC bug,
and then the package will get removed, as it shall.

Of course, if nobody filed such an RC bug, the package gets shipped in a
broken state.  But it's perhaps better to just ship the package and let
people report in the case it is broken, rather than not ship it (despite
it is usable and has no serious issue ; no upload in a decade does *not*
necessarily mean that it has bitrotted), and then people not even notice
that the package isn't shipped any more.  I do have some packages on my
system which I do use, and which I just happened to notice that they are
not installable any more, because they got removed at some point.

Samuel

Re: Fixed release dates are hurting quality

[Adam Borowski]

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 should also be properly maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.

Orphaned packages are nowhere as bad -- you can fix anything.

It's packages that are nominally maintained which see no updates but for RC
bugs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy.
⠈⠳⣄

Re: Fixed release dates are hurting quality

[Holger Levsen]

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 many maintainers are "affected" in your
opinion?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

I'm looking forward to Corona being a beer again and Donald a duck.


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 testing
Do you mean the process that happens for most of each testing freeze? As
my understanding is that this process is something normal and even
encouraged. Also, I'm not sure how is this related to "fixed release
dates" from the subject.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 maintained or not shipped at all.
> > 
> > For context, there are currently 929 packages maintained by
> > packa...@qa.debian.org. That doesn't count packages that have an
> > inactive maintainer, which is more challenging to quantify.
> 
> Yes, and I think that number 929 is already too high.
Are you in favor of more aggressive package removal from testing or even
unstable? 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 should also be properly maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.
There were proposals for that, for example counting time and/or number of
uploads since the last maintainer upload.
On the other hand, there is vocal opposition in the project to calculating
whether a package is working/useful/should be removed based on its
maintenance status in Debian, its upload history, the history of its
upstream releases and similar things.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[John Paul Adrian Glaubitz]

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 maintained or not shipped at all.
> 
> For context, there are currently 929 packages maintained by
> packa...@qa.debian.org. That doesn't count packages that have an
> inactive maintainer, which is more challenging to quantify.

Yes, and I think that number 929 is already too high.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fixed release dates are hurting quality

[Andrey Rahmatullin]

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 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.
And if a package has an RC bug that doesn't mean it's not usable etc., it
just means it has some problem that fits the definition of an RC bug (or,
even, that doesn't, but nobody lowered the severity).
But the project decided to use these criteria in the absence of better
ones, just as the project decided to use obviously flawed popcon stats.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Fixed release dates are hurting quality

[David Bremner]

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 are currently 929 packages maintained by
packa...@qa.debian.org. That doesn't count packages that have an
inactive maintainer, which is more challenging to quantify.

Re: Fixed release dates are hurting quality

[Samuel Thibault]

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 date?

We want to manage to release at some point.

> 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.

Samuel

Re: Fixed release dates are hurting quality

[Bjørn Mork]

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

Fixed release dates are hurting quality

[John Paul Adrian Glaubitz]

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 meaning there is
no guarantee for quality.

I personally do not think that this is a good idea as this leads to the release
being shipped with lots of packages that have not been properly maintained and
the single NMU just paints over that issue.

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.

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. I don't
think we gain anything by shipping half-finished releases.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913