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