On Fri, 2018-03-09 at 10:06 +0100, Pierre-Yves Chibon wrote: > On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote: > > On 03/08/2018 07:53 PM, Kevin Kofler wrote: > > > Randy Barlow wrote: > > > > It may be possible to automate the process a bit to make it > > > > less heavy > > > > for developers, though there is some complication for multi- > > > > package > > > > updates > > > > > > Some automation would help, sure. But if we are going to do > > > things > > > automatically, why bother with Bodhi at all? > > > > Well, we don't currently have another tool to show results and > > allow > > waving of them. We could come up with another app and have yet a > > different place and workflow from regular releases, but why not > > stick to > > the same workflow and avoid making yet another app. > > > > > > We are already building into a pending tag for the autosigning, > > > from which > > > the packages are moved into the final tag when they are signed. > > > The same > > > process should work for autotesting. Just add it before or after > > > the > > > autosigning in the pipeline, possibly with another intermediate > > > tag. > > > > > > I think that Bodhi is really the wrong tool for the job here. > > > What you are > > > trying to hit with your shiny hammer may look like a nail to you, > > > but it is > > > really a screw. ;-) > > > > I don't think thats the case here, it's more than we don't want to > > build > > another different tool for something that could work with the > > hammer we > > have. > > > > To be fair, there was a suggestion that we show results in > > pagure/src.fedoraproject.org, but to me, that definitely sounds > > like the > > wrong place for such things. We want tests tied to a specific > > update, > > not the entire package as a whole. (Even thought we could fudge > > this by > > having git tags or something to tie results to). > > For regular Fedora releases I definitely agree with you, but for > rawhide where > the only time we bundle package together would be via side-tags, I > think > reporting test results to src.fp.o would be a valid approach. We could take a hint from how we make software upstream these days: 1. submit a pull request for the package in src.fp.o on the master branch 2. a CI automatically builds this package in Koji 3. merge the pull request into master 4. the build (from step 2) is tagged for Rawhide, without a rebuild Gating is achieved by preventing merges if the build/tests fail. -- Mathieu _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
