Having this implemented manually would be great. In the future I'd
like to replace it with automatic process managed by AutoQA. AutoQA
would say Bodhi this update can be only pushed together with this
other update, because the first one depends on the second one. The
maintainer wouldn't
On Mon, 2012-04-02 at 05:39 -0400, Kamil Paral wrote:
So I really see two options for improving these situations:
1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two
months ago (to silence). The idea would be to add the ability for
bodhi
updates to mark other updates as
On 03/26/2012 09:53 PM, Stephen Gallagher wrote:
As requested during the FESCo meeting, I am going to try to summarize
some of the issues inherent in the way that Bodhi updates currently
work.
First, I'll try to explain the goals and constraints:
1) The stable 'fedora-updates' yum repository
So I really see two options for improving these situations:
1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two
months ago (to silence). The idea would be to add the ability for
bodhi
updates to mark other updates as a dependency, so that in the example
above, Firefox could
Adam Williamson wrote:
I think we'd need to make the second more optional than you suggest,
though. For instance, when the desktop team pushes a 'GNOME 3.4' update
with 30 packages in it, they really want that update to be tested as a
whole - broadly they just want people to install all the
On Mon, 2012-03-26 at 15:53 -0400, Stephen Gallagher wrote:
So I really see two options for improving these situations:
1) https://fedorahosted.org/bodhi/ticket/663 I opened this ticket two
months ago (to silence). The idea would be to add the ability for bodhi
updates to mark other updates
As requested during the FESCo meeting, I am going to try to summarize
some of the issues inherent in the way that Bodhi updates currently
work.
First, I'll try to explain the goals and constraints:
1) The stable 'fedora-updates' yum repository should NEVER exist in a
state where any package has
Stephen Gallagher wrote:
2) We could continue on the single update for multiple packages
approach, but revamp the karma system so that each SRPM gets its own
karma, rather than the update as a whole. Then, the whole update would
not be pushed via autokarma until all of the dependent packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26.03.2012 21:53, Stephen Gallagher wrote:
So now we have our first updates dependency issue. If we submit
libtevent as its own update, it is possible that it will achieve its
karma requirement before libtalloc does. It would then be pushed to
