On Po, 2013-11-18 at 07:20 +0100, Stanislav Ochotnicky wrote:
> I'd expect out of ~800 packages that BR java only very few are going to be
> affected by java-headless change (i.e. they'd have to revert the change). I'd
> estimate maybe 30 broken packages and some we know wouldn't work so we would
> exclude them.
That is no reason for breaking these 30 broken packages without at least
giving the package maintainer a chance to opt out of getting it broken.
> How about this:
> * I file bug for every package that BRs java
> * We'll give maintainers two weeks (or maybe a month) to look at the bug and
> possibly fix their packages.
> * If they don't take any action on the bug (i.e. leave it in NEW)
> we'll fix up the package in automated way.
> * If they close the bug or assign it to themselves we'll leave the package
> alone
I could agree with this plan.
> However I am worried some maintainers will close those bugs without even
> glancing at their packages. And it takes just one screwed up package which pulls
> in full java and we're back at square one. I am open to suggestions on how to
> allow maintainers to opt-out if they feel confident their package is OK.
Don't be so pessimistic - if you eliminate 95% of unneeded full Java
dependencies, taking away the rest 5% on case by case basis would not be
impossible even manually. Why it would be so catastrophic that some
obscure server package would pull full Java? I mean it should not be
hard for server admins to spot such package and report a bug for it
appropriately.
And I don't really believe package maintainers will blindly close the
bugs if their package requires only headless Java. I much more believe
the maintainers will ignore the bug even if the package requires full
Java which will mean that the package gets broken after the mass change.
But that's a maintainer ignorance problem then and not just mass
breaking packages by a script.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
