Re: Re-evaluating architecture inclusion in unstable/experimental

[Samuel Thibault <sthibault@debian.org>]

Svante Signell, le dim. 02 sept. 2018 23:39:08 +0200, a ecrit:
> 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.

For my part, I was not talking about that patch, but about the
hurd-related patches.

For others, I can simply quote what was said:

Felix Geyer wrote:
> I suggest that instead you respond to questions on bugs you opened.
> I'm not interested in maintaining patches for things that clearly
> belong upstream.  Once upstream has reviewed the changes I'm happy to
> cherry-pick them.

And I agree with it (and also one of the reasons why I didn't just
NMU-ed cmake with the hurd patch).

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

He is not rejecting things, he is saying that belongs to upstream, which
is true.  Help with that and things will flow.

> I think the next step would be to bring the responsibilities and commitments of
> a Package Maintainer to the TC,

Nope.

> Maybe the recent salvaging of packages could be helpful in the future
> regarding this problem.

Nope.

Samuel