On Tue, 2010-02-09 at 17:15 -0800, Markus Roberts wrote:
> All --
>
> I've just pushed a newly built testing branch to
> http://github.com/reductivelabs/puppet/tree/testing
Good!
> For those of you that haven't been following the testing branch saga,
> a few things to note:
>
> * This branch will be frequently (at least once a week) rebuilt from
> scratch, so git's normal "don't rewrite
> history" assumptions don't apply; instead, assume that history will
> be rewritten regularly
> * Consequently, the best way to pull it is probably
>
> git branch -D testing
> git fetch origin testing
> git checkout testing
>
> or some variation there of. If you try to pull a new version on top
> of a previous version you will likely see
> merge conflicts.
It is my understanding that if you push -f on testing instead of
removing the remote branch/recreating it, people pulling it would just
see a "forced update" without merge conflicts.
> * The goal of this branch is to provide a testing area for new patches
> that are intended to go into master but
> need a little ex{e,o}rcising first
> * The testing branch is constructed by applying the branches off
> tickets marked "ready for testing" on top of
> master, omitting those that produce conflicts.
> * The branches will be applied in a specific order, with "better"
> patches migrating towards the head while respecting
> dependencies.
Can you define "better"?
Do you mean closer to release because maturing or better because they
bring a better feature?
> * In addition to testing the entire branch it is possible to test a
> prefix by checking out a specific earlier commit (by md5)
What do you mean by "prefix"? Do you have an example on how to do that?
Does the construction of the testing branch allows git bisect?
> * When a given prefix series of patches is deemed sufficiently proven
> it will be removed from the testing branch
> maelstrom and permanently added to the head of master.
> * In parallel, we're going to be working to clean up master with the
> goal of maintaining constant 100% test passage.
It's a good goal.
> * If you have code that ought to be in the testing branch:
>
> * Make sure it's listed on a ticket
> * Make sure the ticket is marked ready for testing
> * If it depends on any other branches, make sure to note that fact
> * Track the ticket for changes; questions, status changes (e.g. to
> "code insufficient" if it causes merge conflicts) and
> links to the tickets for any bugs discovered in the testing
> process.
Hmm, does that mean you'd accept any patch as being part of "testing",
if the only thing we need to do is log a ticket and change its status to
ready for testing?
I mean for instance my puppetd streaming patch has low chance (in its
current state) to get accepted and merged, will it enter testing without
any more proof-reading if I just log a ready for testing ticket?
> The following is the list used to construct the present branch. All
> of them applied cleanly except for luke:tickets/master/2954. For the
> next round I need to get my futures rebased to testing, Luke needs to
> resolve the problems with 2954 and indicate which of the other
> branches from his repo should be included. I'll also go back through
> the dev list to find branches that ought to be included (feel free to
> respond with any)--right off the bad I know I want to get the hashes
> in here.
I was holding the Hash stuff until I could grab your futures and string
interpolation patch and rebase on top of yours.
What's the status of the futures patch?
Where could I get a preview to start the rebasing?
How do we trigger a "testing" rebuild (if we can't wait for the weekly
rebuild)?
Let's say if I make some important changes (ie bugfixing one of the
testing patchset), how do I make sure testing will get rebuilt in a
timely way?
Many thanks,
--
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
