Fernando Garcia Bermudez <fgb@...926...> writes:
Do you know if these changes will trickle to the py3 repo after
merging into master?
I don't know if we have a process in place for that. It depends on how
you view the py3 repo: if it's just another feature branch, it shouldn't
do any merges from master just for the sake of it, but if it's kind of
like "next" or "pu" (proposed updates) in some workflows, it makes sense
for it to be occasionally brought up to date (possibly even by
rebasing).
But it's fine for even feature branches to merge from master, e.g. if
there is a feature in master that the branch is going to depend on.
···
--
Jouni K. Sepp�nen
I guess the py3 master will not be merged back into the matplotlib
repo until the last maintenance branch supporting python-2.5 and older
has been created (perhaps 1.1.x or 1.2.x). Since it is a long-running
line of development, I think it makes sense to occasionally bring it
up to date with the master branch. I've already done this once or
twice. I don't think we want to deal with rebasing. I rebased the py3
master branch once right after you merged the maintenance branches
with --strategy=ours, since that provided a much improved point of
reference, but it was a headache to coordinate with even one other dev
to deal with any unmerged branches out there effected by the rebase.
Maybe once the osx make binaries issue is resolved and the make.osx
branch is merged into master, someone with a working windows build
environment could test building binaries with python-2.6 and 2.7. If
it looks ok, that might be a good point to merge matplotlib/master
into py3/master.
Darren
···
On Sun, Mar 6, 2011 at 4:46 AM, Jouni K. Seppänen <jks@...278...> wrote:
Fernando Garcia Bermudez <fgb@...926...> writes:
Do you know if these changes will trickle to the py3 repo after
merging into master?
I don't know if we have a process in place for that. It depends on how
you view the py3 repo: if it's just another feature branch, it shouldn't
do any merges from master just for the sake of it, but if it's kind of
like "next" or "pu" (proposed updates) in some workflows, it makes sense
for it to be occasionally brought up to date (possibly even by
rebasing).