Re: Re-evaluating architecture inclusion in unstable/experimental
On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote:
> Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit:
> > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
> >
> > >
> > > > The statistics and graphs available on the debian-ports page[1] may
> > > > provide some objective statistics or reflection on the actual
> > > > suitability of your architecture's continued inclusion.
> > > > [1]: https://buildd.debian.org/stats/
> > >
> > > Such statistics are really difficult to get any real conclusion from.
> > > Sometimes 10% packages are missing just for one tricky nonLinux-specific
> > > issue in one package.
> >
> > Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
> > It does not even have to be tricky.
>
> If it's not tricky, a NMU should be able to fix it easily.
I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this
issue and you both said it was not possible to NMU cmake, even if you are both
DD's. See bugs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905140
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900240
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905138
I think that the power of a package maintainer is far too big, making it
possible to reject/ignore important and other bugs, especially with patches, for
non-released architectures (and effectively block NMUs).
I think the next step would be to bring the responsibilities and commitments of
a Package Maintainer to the TC, in addition to the full control of everything
related to that package. Maybe the recent salvaging of packages could be helpful
in the future regarding this problem.
Reply to: