Re: Re-evaluating architecture inclusion in unstable/experimental
- Date: Mon, 3 Sep 2018 00:19:47 +0200
- From: Samuel Thibault <sthibault@xxxxxxxxxx>
- Subject: Re: Re-evaluating architecture inclusion in unstable/experimental
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 may
> > > > > provide some objective statistics or reflection on the actual
> > > > > suitability of your architecture's continued inclusion.
> > > > > : 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
For my part, I was not talking about that patch, but about the
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,
> Maybe the recent salvaging of packages could be helpful in the future
> regarding this problem.