Can we make it so that Bodhi runs automatically?

[Richard W.M. Jones]

I know I should make a patch to do this, but ...

Is there any reason why you _wouldn't_ want Bodhi to take an update
automatically after a successful Koji build of a non-Rawhide package?
It's an extra step that I always have to do manually, and I've never
seen a case where I wouldn't want Bodhi to just happen automatically.

Rich.

[Pavel Shevchuk]

Because it won't allow to update highly modular packages properly.
Imaging gedit update being pushed before updated gnome-libs are built

On Sun, Dec 21, 2008 at 9:48 PM, Richard W.M. Jones  wrote:
> I know I should make a patch to do this, but ...
>
> Is there any reason why you _wouldn't_ want Bodhi to take an update
> automatically after a successful Koji build of a non-Rawhide package?
> It's an extra step that I always have to do manually, and I've never
> seen a case where I wouldn't want Bodhi to just happen automatically.
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Richard W.M. Jones]

On Sun, Dec 21, 2008 at 10:22:44PM +0200, Pavel Shevchuk wrote:
> Because it won't allow to update highly modular packages properly.
> Imaging gedit update being pushed before updated gnome-libs are built

I don't understand what this means - can you explain more?

Rich.

[Pavel Shevchuk]

If all built packages will go directly to update queue they may be
delivered to repositories too fast breaking stuff

On Mon, Dec 22, 2008 at 12:12 PM, Richard W.M. Jones  wrote:
> On Sun, Dec 21, 2008 at 10:22:44PM +0200, Pavel Shevchuk wrote:
> > Because it won't allow to update highly modular packages properly.
> > Imaging gedit update being pushed before updated gnome-libs are built
>
> I don't understand what this means - can you explain more?
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://et.redhat.com/~rjones/virt-df/
>
> --
> fedora-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Jesse Keating]

On Sun, 2008-12-21 at 19:48 +0000, Richard W.M. Jones wrote:
> I know I should make a patch to do this, but ...

make build update

?

We don't automatically take things because we expect you to fill in some
details about the update, what it's fixing, what bugs should be closed,
what enhancements are added, what users should test for, if it's
security, etc...  We don't want people to just throw builds over the
wall at users and hope it sticks.

[Till Maas]

On Sunday 21 December 2008 23:31:04 Jesse Keating wrote:
> On Sun, 2008-12-21 at 19:48 +0000, Richard W.M. Jones wrote:
> > I know I should make a patch to do this, but ...
>
> make build update

Can this be done nowadays before the build suceeded?  
There is also still a patch available to get a "create update" link within 
koji:
https://fedorahosted.org/koji/ticket/87
It can probably be easy expanded to add this link to e-mails of sucessful 
builds, too.

Regards,
Till

[Richard W.M. Jones]

On Sun, Dec 21, 2008 at 02:31:04PM -0800, Jesse Keating wrote:
> On Sun, 2008-12-21 at 19:48 +0000, Richard W.M. Jones wrote:
> > I know I should make a patch to do this, but ...
>
> make build update

Useful!  I didn't know about this.

Rich.

[Kevin Kofler]

Richard W.M. Jones wrote:
> Is there any reason why you _wouldn't_ want Bodhi to take an update
> automatically after a successful Koji build of a non-Rawhide package?

Grouped updates.

For example, a xulrunner security update can't just be pushed out as soon as
it's build, it requires building xulrunner, getting it tagged into the
buildroot, then building an updated firefox and rebuilding several other
xulrunner-using packages and then pushing everything as a grouped update.
Doing it any differently would break dependencies.

In some other cases, like KDE, it would be technically possible to push
first the libs, then each application module one by one, but this would be
much more chaotic than just pushing the new version out as a grouped update
as we're doing now. And people don't really test e.g.
kdebase-workspace-4.1.2 with kdelibs-4.1.3, it should work due to backwards
compatibility, but normally users are expected to update those modules to
4.1.3 together. And we need to support grouped updates anyway for the cases
where we don't have backwards compatibility, like xulrunner (for those apps
using the xulrunner-unstable interfaces, which include Firefox).

Kevin Kofler