[katello-devel] Merging and Pulling with no wait

[Hugh Brock]

On Wed, Oct 24, 2012 at 02:32:34PM -0400, Jeff Weiss wrote:
> We did have a lengthy and productive discussion related to this problem at the QE Summit in Brno last week.
> 
> I think the major takeaway from that is, we want automated tests running on changes BEFORE they hit master, not only after.
> 
> So what we'll be working towards is some system whereby Pull Requests are tested, and some kind of feedback of the automated test results will be posted to the PR comments.
> 
> This process should take less than 1 hour after the PR is submitted.  I was planning on using Jenkins, since aside from the PR interaction, the steps are exactly the same as what we do for master today:
> 
> 1) build rpms from the commit we want to test
> 2) Install them on fresh vm
> 3) Run automation against vm
> 
> We just need to add
> 0) Monitor PR's
> 4) Add feedback to PR
> 
> 
> 
> -Jeff

+1000 to this, can we also haz 4 aeolus plz? kthxbai

--Hugh

> 
> ----- Original Message -----
> From: "Lukas Zapletal" <lzap at redhat.com>
> To: katello-devel at redhat.com
> Sent: Wednesday, October 24, 2012 5:07:21 AM
> Subject: Re: [katello-devel] Merging and Pulling with no wait
> 
> On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote:
> > Tom - you know, I totally agree with you.  I hadn't really thought of
> > the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but
> > obviously it didn't catch Adam's pylint error, so it's not perfect.
> > Perhaps I jumped the gun sending my email out, but my main goal is to
> > make the product stable each and every check-in.  Education is great,
> > and I like that side of pull-requests, but it's not the primary reason
> > for my concern.  Plus, there is nothing stopping someone from viewing
> > the committed files via the closed pull request.
> >
> 
> Just to fine-tune the information - Erik is working on TravicCI-Github
> integration and I am just helping him to integrate the new Gemfile. And
> it is looking good. No other works on Ozzak, I turned it off because I
> thought Eric is done (but he is still tuning the stuff). No more Ozzak,
> expect big announcement very soon :-) I want to change ozzak script to
> run koji scratch builds against git pull requests.
> 
> The git pull you picked as an example is not a good example of request
> that should be put on hold for 24 hours. We have having annoying amount
> of "fuzzy i18n messages" during our unit test runs and it was literally
> blocking Eric from doing anything on Travis (because what you get is 10
> MB log which does not pretty work with all that javascript that is on
> Travis). And that was reason for the quick merge.
> 
> I agree with you that for *important* changes we should not do this and
> let everyone to read the patch, but I am totally fine with quick-merging
> those tiny things, blockers and cosmetic changes. One can always rise
> his hand even after a pull request was merged and if the objections are
> reasonable - yes - we have the revert thing.
> 
> I have to admit I raised this topic for the first time, but it was after
> I saw several big merges I was not totally comfortable with. 
> 
> Let's agree on that and if you (or anyone) encounter a "fast&bad" merge,
> just scream in the comments.
> 
> -- 
> Later,
> 
>  Lukas "lzap" Zapletal
>  #katello #systemengine
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey