>> 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.
>
On a very superficial test I'd gotten errors when I simply did a pull, but
it is quite possible that I didn't model the situation correctly.
> * 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?
>
Closer to release, either because they are maturing or just started off well
(small, isolated, easy to test, etc.)
> > * 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?
>
When you're on testing you can go back to any point in the process by doing
a git log, finding the md5 of the last commit you want to include, and
checking it out. In this way your'll be looking at master with the first k
of n commits applied (for some 0 <= k <= n). This sequence of k commits is
what I was calling a prefix.
> Does the construction of the testing branch allows git bisect?
Yes. It's constructed by dynamically rebasing the branches onto the growing
branch, so there are no merge commits or other artifacts that would mess up
bisects.
> > * 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.
>
Hey, you've got to have a dream ("'cause if you ain't got a dream, how you
gonna have a dream come true?")
> > * 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.
> 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.
> > 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.
> 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).
> Many thanks,
>
Ditto!
-- Markus
--
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.
