Re: Rawhide gating: What shell be done with failed updates?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 28, 2019 at 02:47:32PM +0200, Miro Hrončok wrote:
> On 28. 08. 19 14:45, Pierre-Yves Chibon wrote:
> > On Wed, Aug 28, 2019 at 01:42:34PM +0200, Miro Hrončok wrote:
> > > On 28. 08. 19 13:24, Pierre-Yves Chibon wrote:
> > > > On Wed, Aug 28, 2019 at 12:16:09PM +0200, Miro Hrončok wrote:
> > > > > On 28. 08. 19 9:32, Clement Verna wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, Aug 27, 2019, 15:35 Miro Hrončok <mhroncok@xxxxxxxxxx
> > > > > > <mailto:mhroncok@xxxxxxxxxx>> wrote:
> > > > > > 
> > > > > >       If updates in rawhide gating fail the tests, what is the procedure? Should they
> > > > > >       be unpuhsed, or left to rot forever?
> > > > > > 
> > > > > > 
> > > > > > There are a few options here, fix the package so that the tests pass,
> > > > > > disable the tests, or waive the results. If none of these are done then
> > > > > > yes the update will just stay there to rot.
> > > > > 
> > > > > I meant what to do with the broken updates that are actually broken. When a
> > > > > new update is created, the older one doesn't seem to be obsoleted or
> > > > > unpushed.
> > > > 
> > > > I'm not sure I understand what you mean. What do you mean with "Broken updates
> > > > that are actually broken"?
> > > 
> > > I mean when I push an update A and a test T realizes update A is broken, so
> > > I fix it and push another update B. I.e. I have no interest in waiving the
> > > failed test T in update A, because update A actually was broken.
> > > 
> > > Update B now does not obsolete update A (as you have described in the
> > > paragraph below). As a packager, should I unpush update A or just do
> > > nothing?
> > 
> > In this case I'd encourage to unpush update A since you know beforehand and are
> > not interested in ever seeing this update go through.
> > Do nothing is also an option, though it is less clear as what it means to other
> > contributors.
> 
> Makes sense. Thanks. Let's document this somewhere. Where?

Good question.
Maybe the packaging guidelines?
Or in the rawhide-gating docs? [1]


Pierre

[1] https://pagure.io/cpe/rawhide-gating-docs/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux