Re: jlapack_0.8~dfsg-3~bpo8+1_amd64.changes REJECTED
On Fri, Jul 08, 2016 at 11:27:01AM +0200, Rhonda D'Vine wrote:
> But it would be much more helpful to not have to ask but been
> told by the people doing that beforehand.
I've got this.
> > Please assume that I was considering the change from contrib to main
> > a relevant change. Next time I'll post this here first.
>
> While I agree that it's an important change on itself, it's a corner
> case and I don't see it as a reason for a backport on its own.
> Backports is about new features that packages offer that might be useful
> for users of an otherwise stable release. And moving package from
> contrib to main - while it is an important step, no question there - is
> not really offering something new to stable users.
Yes, *only* the move from contrib to main does not rectify a backport.
However, there are bugfix releases from beast-mcmc I would love to ship
to stable users. I would have expected a "package is not in testing of
the distribution in question" if I try to upload a new version from
beast-mcmc to contrib since contrib/testing does not have this version
(since its in main). Yes, its a corner case and if things are not in
line with backports policy the weld will keep on turning without the new
version in backports.
> > May I assume that it is fine to re-upload jlapack and once this is
> > accepted netlib-java and mtj as well which have pretty the same reason
> > and minimal changelog.
>
> You can upload them together, the buildds should be able to handle that
> correctly from what I know. Unless there is something else that might
> be an issue here that I don't see on first sight.
I might consider setting up a local mirror for pbuilder to make sure all
will be build in a clean environment. In any case I'll make sure to add
a short explanation to each of the packages in d/changelog.
Hope to fit requirements for backports better in future.
Thanks for your patience
Andreas.
--
http://fam-tille.de
Reply to: