On 10/02/10 19:46, Markus Roberts wrote: >>> * 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? >> > > No. It might, for example, get the ticket changed to "code insufficient" or > "rejected" with a note of explanation added o the ticket.
it makes sense. >> 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? >> > > Actually, I might be inclined to include it (towards the end of the list) so > more people can play with it and we can refine our understanding. Luke and > I went over it very briefly yesterday and I plan to spend more time on it > later today. It's something we'd like to get in, but there are many issues > to consider. That's exactly the sort of thing the testing branch is > intended for. I expect tons of comments :-) As I said in my intro comment in the patch set, it's the result of a quick and dirty hack on a rainy sunday. If you're interested it's in my github repository, branch wip/streaming. >>> 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? >> > > I'll have them in the next testing branch; I was a dolt and based them on > 0.25.x and need to rework them. Based on all the Luke's ruby DSL patch, I'm afraid it'll be difficult. >> 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? >> > > Ping me or, if you want to roll your own, there's a rake task you could use > (but it's not particularly end-user friendly). Great, So to conclude, I should now start coding against next and not master, is that correct? -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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.
