Educating packagers about always making changes in devel / rawhide first
Kevin Fenzi
kevin at scrye.com
Tue Feb 11 02:27:24 UTC 2014
On Mon, 10 Feb 2014 21:37:19 +0100
Till Maas <opensource at till.name> wrote:
> On Mon, Feb 10, 2014 at 09:55:26AM -0700, Kevin Fenzi wrote:
> > On Mon, 10 Feb 2014 17:42:47 +0100
> > Till Maas <opensource at till.name> wrote:
>
> > > Isn't AutoQA already running these kind of checks?
> >
> > For f19 and f20 updates, yes... in an advisory manner.
> >
> > But not for rawhide since it has no bodhi update to add the comment
> > to or know to check.
>
> It is not the Rawhide update that needs to be checked but the F19/F20
> update, because the problem results from the lack of an Rawhide
> update, not because a bad one was issued.
There are still cases where thats not true. Take for example:
* Maintainer builds for f19/f20/rawhide
* Pushes to testing for f19/f20
* Discovers a problem with only the rawhide version.
* Since there's not yet been a rawhide compose, untags it.
* autoqa already ran on the updates-testing updates, so maintainer
forgets about it.
* f19/f20 go stable.
> However, IMHO it makes more
> sense to just hook into AutoQA instead of running the same test
> twice. Also it would allow to respond in a timely manner which might
> better help to educate maintainers instead of when there are several
> days between the bad update creation and the reaction to it.
Sure, but I wonder how many maintainers ignore the autoqa note.
I know there's at least one common case... if you build for f19/f20 and
say the f19 build finishes first and you make that update then, it will
add a note from autoqa, but then you know you are going to create the
f20 one soon so you ignore it, then you forget to?
Anyhow, yeah, I would love taskotron to handle this...
kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140210/6c3793b3/attachment.sig>
More information about the devel
mailing list