https://bugzilla.redhat.com/show_bug.cgi?id=902086 jiri vanek <jvanek@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1181564 --- Comment #63 from jiri vanek <jvanek@xxxxxxxxxx> --- (In reply to jiri vanek from comment #59) > proposed: > https://fedoraproject.org/wiki/Changes/Elasticsearch This was approved, In FeSCo meeting log was few very interesting sentences: [1] * though a little worried whether everyone will be able to keep all of the packages in sync over time. * Right, this is a prime example of the tradeoff we get with strict no-bundling policies. * I'd rather reject this for F22 and have them work tightly with the Env/Stacks group for a better F23 plan. [2] * SCLs would be great for such change * No, the worst case is that we can't upgrade to a newer version of one of the deps because Elasticsearch is holding it back. * I’d much rather not have that blanket exception[3]. Compat packages are better. * I could keep the +1 with assumption that the contingency is “package does not added”, but sending this back for a revision wouldn’t hurt that much. [4] * I *really* want this to get used to solve the wider problem of "big packages with tight dep requirements". Hence why I want to make this an Env/Stacks problem. [2] [again] [1] http://meetbot.fedoraproject.org/fedora-meeting/2015-01-07/fesco.2015-01-07-18.01.log.html [2] I understand this as an effort to support similar cases in future [3] for bundling [4] not added is ok for now, but what about future breakages? Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1181564 [Bug 1181564] Elasticsearch -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review