Re: Bug#835533: dasher: Please package Dasher 5.0 beta
On Thu, Oct 06, 2016 at 02:46:46PM -0400, Scott Kitterman wrote:
>
>
> On October 6, 2016 8:51:59 AM EDT, Adrian Bunk <bunk@stusta.de> wrote:
> >On Thu, Oct 06, 2016 at 02:46:44AM -0400, Scott Kitterman wrote:
> >>...
> >> As frustrating as occasional removal/reintroduction cycles are, they
> >are rare enough that despite the frustration when they occur it's
> >really not worth the effort it would take to avoid them completely.
> >
> >This assumes that all users are developers who are following unstable.
> >
> >The vast majority of Debian users won't use stretch until after it
> >became stable.
> >
> >And even if a user does use unstable or testing, there is no clear way
> >for a non-developer do get a removed package back into unstable.
> >
> >It is a problem for users when Debian is a revolving door
> >for packages that get ITP'ed into one stable and then disappear
> >without a good reason for removal in a later stable.
> >
> >Example maintainer opinion: [1,2]
> > If we orphan 2.x someone might fix the RC bug and get it back into
> > testing.
> > At this point I think releasing stretch with 2.x would be worse than
> > releasing stretch without freeradius.
> >
> >When a user who uses FreeRADIUS 2.2.5 in jessie upgrades to stretch
> >after it became stable, is it worse for the user he gets FreeRADIUS
> >2.2.9
> >in stretch with 3 years (or 5 years with LTS) of security support,[3]
> >or if he gets no FreeRADIUS in stretch?
> >
> >FreeRADIUS is high-profile enough that many Debian developers do care
> >and new maintainers were quickly found. Many other packages are not.
> ...
>
> This is all true, but in the end, Debian is a do-acracy. While we should try to do the best for our users, there's no way we can do everything for everyone. Users who want to increase the chances our next release scratches whatever their personal itch is need to get involved with development.
I am not disputing that.
What I am saying is that "try to do the best for our users" includes
"do not remove a package that is in stable without a good reason from
the next stable".
I am not saying that anyone has an obligation to fix RC issues in
packages he does not maintain.
If there is an RC issue that doesn't get fixed, that is a good reason.
If Debian is not able to provide security support for a package,
that is a good reason.
"maintainer doesn't want his package in the next stable" or
"package is orphaned" alone are not good reasons, especially
when the package is in testing or only kept out of testing
by a maintainer not applying a fix.
"upstream is dead" is also less obvious that it looks at first sight.
For some packages it does not even matter that much (e.g. packages
supporting specific older hardware).
Code that works for 10 years is also not necessarily in a worse
state than some random code a highschool student pushed to GitHub
that gets ITP'ed.
I do see the problem that Debian accumulates more and more packages,
but instead of being a revolving door for packages Debian would need
a policy for ITPs if that should change.
> Scott K
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: