[matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Benjamin Root 
I am testing the doc builds on v1.0.x when I noticed that it seems to think
that it is version 1.1.0.  Sure enough, somehow lib/matplotlib/__init__.py
has __version__ defined as '1.1.0'.  Meanwhile, I can't seem to finish a doc
build on the v1.0.x branch, but I could with my docfix/smalltypos branch.

Anybody have any clues what went wrong?

Thanks,
Ben Root
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Michael Droettboom 
Yes, it seems that the v1.0.x got hosed somehow back in early May.  Eric 
Firing did some spelunking and traced it to a push I made, but I'm not 
sure what I did wrong, and I'm even less sure how to fix it.  If someone 
with more git-fu wants to investigate and repair it, that would be 
fantastic, but I'm afraid to touch it myself.


Mike

On 06/01/2011 02:10 PM, Benjamin Root wrote:
I am testing the doc builds on v1.0.x when I noticed that it seems to 
think that it is version 1.1.0.  Sure enough, somehow 
lib/matplotlib/__init__.py has __version__ defined as '1.1.0'.  
Meanwhile, I can't seem to finish a doc build on the v1.0.x branch, 
but I could with my docfix/smalltypos branch.


Anybody have any clues what went wrong?

Thanks,
Ben Root


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev


___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Eric Firing 
On 06/01/2011 08:26 AM, Michael Droettboom wrote:
> Yes, it seems that the v1.0.x got hosed somehow back in early May. Eric
> Firing did some spelunking and traced it to a push I made, but I'm not
> sure what I did wrong, and I'm even less sure how to fix it. If someone
> with more git-fu wants to investigate and repair it, that would be
> fantastic, but I'm afraid to touch it myself.
>
> Mike

Mike, all:

Suggestion:  Let's just abandon the v1.0.x branch, stabilize master, and 
get a release out.  (Easy for me to say--I have never contributed to the 
actual release process.)  I think that we really need to get releases 
out more frequently--that needs to become a higher priority.  I don't 
think it is even worth the trouble to maintain a maintenance branch at 
all.  It adds quite a bit of complexity to the development and release 
process--every time a bug is found, the fix has to be developed on 
maintenance, committed and pushed, checked on master, and propagated to 
master.  It's not worth it. The differences between master and 
maintenance are normally not large enough to justify keeping them 
separate, given our very constrained people-time resources.

Note that a release doesn't have to be made from master HEAD; git 
branching is extremely flexible, so at any time, one can make a branch 
from any point on the tree, do some checking and adjustment, and release 
it.  Where we get into difficulty and waste time is in trying to 
maintain a separate maintenance branch for a long period.  We just don't 
have the resources to do this well; and we don't really need to do it at 
all.

Eric

>
> On 06/01/2011 02:10 PM, Benjamin Root wrote:
>> I am testing the doc builds on v1.0.x when I noticed that it seems to
>> think that it is version 1.1.0. Sure enough, somehow
>> lib/matplotlib/__init__.py has __version__ defined as '1.1.0'.
>> Meanwhile, I can't seem to finish a doc build on the v1.0.x branch,
>> but I could with my docfix/smalltypos branch.
>>
>> Anybody have any clues what went wrong?
>>
>> Thanks,
>> Ben Root

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Benjamin Root 
On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing  wrote:

> On 06/01/2011 08:26 AM, Michael Droettboom wrote:
> > Yes, it seems that the v1.0.x got hosed somehow back in early May. Eric
> > Firing did some spelunking and traced it to a push I made, but I'm not
> > sure what I did wrong, and I'm even less sure how to fix it. If someone
> > with more git-fu wants to investigate and repair it, that would be
> > fantastic, but I'm afraid to touch it myself.
> >
> > Mike
>
> Mike, all:
>
> Suggestion:  Let's just abandon the v1.0.x branch, stabilize master, and
> get a release out.  (Easy for me to say--I have never contributed to the
> actual release process.)  I think that we really need to get releases
> out more frequently--that needs to become a higher priority.  I don't
> think it is even worth the trouble to maintain a maintenance branch at
> all.  It adds quite a bit of complexity to the development and release
> process--every time a bug is found, the fix has to be developed on
> maintenance, committed and pushed, checked on master, and propagated to
> master.  It's not worth it. The differences between master and
> maintenance are normally not large enough to justify keeping them
> separate, given our very constrained people-time resources.
>
> Note that a release doesn't have to be made from master HEAD; git
> branching is extremely flexible, so at any time, one can make a branch
> from any point on the tree, do some checking and adjustment, and release
> it.  Where we get into difficulty and waste time is in trying to
> maintain a separate maintenance branch for a long period.  We just don't
> have the resources to do this well; and we don't really need to do it at
> all.
>
> Eric
>
>
Actually, there are plenty of differences between v1.0.x and master.  We
have a number of new features that are baking right now (animations, for
example).  I have personally made a number of changes with mplot3d that, in
some cases, were too risky to apply to v1.0.x and I just wanted them to sit
in the official development branch rather than in the stable branch.  Also,
because there is not much of downstream activity to the repos, I think many
of the packagers depend upon the bugfixes we apply to the maintenance
branches.  I am hesitant to change development policies without a clear
consideration for downstream.

The current practice worked very nicely with SVN (IMHO), and I think it
still works fine.  Most of the issues is really limited to svn --> git
transitions and understanding how git works.  I will agree that it is
possible that the v1.0.x branch might be damaged beyond repair.  I am not
enough of a git expert to know one way or another.

As for the comment about getting releases out faster, this contradicts your
assertion that we don't have the manpower to take care of the maintenance
branch.  We do need better planning for milestones and goals, but I don't
want to push out a release until it is ready.  In particular, I think a good
rule of thumb for the v1.1.0 release should be to have *all* the backends
behaving the same (::cough:: macosx ::cough::), and to officially deprecate
any backends that we can not continue to support (::cough:: Cairo
::cough::).

But that's just my opinion.

Ben Root
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Eric Firing 
On 06/01/2011 09:07 AM, Benjamin Root wrote:
>
>
> On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing  > wrote:
>
> On 06/01/2011 08:26 AM, Michael Droettboom wrote:
>  > Yes, it seems that the v1.0.x got hosed somehow back in early
> May. Eric
>  > Firing did some spelunking and traced it to a push I made, but
> I'm not
>  > sure what I did wrong, and I'm even less sure how to fix it. If
> someone
>  > with more git-fu wants to investigate and repair it, that would be
>  > fantastic, but I'm afraid to touch it myself.
>  >
>  > Mike
>
> Mike, all:
>
> Suggestion:  Let's just abandon the v1.0.x branch, stabilize master, and
> get a release out.  (Easy for me to say--I have never contributed to the
> actual release process.)  I think that we really need to get releases
> out more frequently--that needs to become a higher priority.  I don't
> think it is even worth the trouble to maintain a maintenance branch at
> all.  It adds quite a bit of complexity to the development and release
> process--every time a bug is found, the fix has to be developed on
> maintenance, committed and pushed, checked on master, and propagated to
> master.  It's not worth it. The differences between master and
> maintenance are normally not large enough to justify keeping them
> separate, given our very constrained people-time resources.
>
> Note that a release doesn't have to be made from master HEAD; git
> branching is extremely flexible, so at any time, one can make a branch
> from any point on the tree, do some checking and adjustment, and release
> it.  Where we get into difficulty and waste time is in trying to
> maintain a separate maintenance branch for a long period.  We just don't
> have the resources to do this well; and we don't really need to do it at
> all.
>
> Eric
>
>
> Actually, there are plenty of differences between v1.0.x and master.  We
> have a number of new features that are baking right now (animations, for
> example).  I have personally made a number of changes with mplot3d that,

Are you referring to animations.py?  The last change in that file on 
master was 9 months ago.


> in some cases, were too risky to apply to v1.0.x and I just wanted them
> to sit in the official development branch rather than in the stable
> branch.  Also, because there is not much of downstream activity to the
> repos, I think many of the packagers depend upon the bugfixes we apply
> to the maintenance branches.  I am hesitant to change development
> policies without a clear consideration for downstream.
>

Do the packagers use the tip of the maintenance branch, or do they use 
the most recent release?  If the former, then that bumps up the priority 
of keeping such a branch.  If the latter, it bumps up the priority of 
having frequent high-quality releases, regardless of what they are called.


> The current practice worked very nicely with SVN (IMHO), and I think it

(I recall that Mike had to rescue us more than once from svnmerge 
confusions, at least during the earlier days.)

> still works fine.  Most of the issues is really limited to svn --> git
> transitions and understanding how git works.  I will agree that it is
> possible that the v1.0.x branch might be damaged beyond repair.  I am
> not enough of a git expert to know one way or another.
>
> As for the comment about getting releases out faster, this contradicts
> your assertion that we don't have the manpower to take care of the
> maintenance branch.  We do need better planning for milestones and

I don't see the contradiction or inconsistency.  I am not saying we 
*can't* keep a maintenance branch; I am saying it is not clear to me 
that it is worth the fuss to do so indefinitely, especially when it is 
infrequently released.

> goals, but I don't want to push out a release until it is ready.  In
> particular, I think a good rule of thumb for the v1.1.0 release should
> be to have *all* the backends behaving the same (::cough:: macosx
> ::cough::), and to officially deprecate any backends that we can not

So, all progress should be held hostage?  This might work if we were a 
company, and could assign a programmer to a task.  Given that we rely on 
volunteers, I don't think it is practical.

> continue to support (::cough:: Cairo ::cough::).

And emf, and plain wx, and plain gtk, and fltkagg. (Many months ago I 
posted a query to matplotlib-users as to whether anyone was actually 
*using* fltkagg; there was no reply.  Regarding Cairo: I don't know what 
its status is, but it always seemed like a potentially useful backup in 
case of an Agg meltdown.) But that would be a big change in mpl de facto 
policy, which has always been very liberal with respect to leaving 
decaying code in place (like mplot3d) in case someone eventually picks 
it up and pumps some life back into it.  I have mixed thoughts about 
that; my general in

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Benjamin Root 
On Wed, Jun 1, 2011 at 2:58 PM, Eric Firing  wrote:

> On 06/01/2011 09:07 AM, Benjamin Root wrote:
> >
> >
> > On Wed, Jun 1, 2011 at 1:47 PM, Eric Firing  > > wrote:
> >
> > On 06/01/2011 08:26 AM, Michael Droettboom wrote:
> >  > Yes, it seems that the v1.0.x got hosed somehow back in early
> > May. Eric
> >  > Firing did some spelunking and traced it to a push I made, but
> > I'm not
> >  > sure what I did wrong, and I'm even less sure how to fix it. If
> > someone
> >  > with more git-fu wants to investigate and repair it, that would be
> >  > fantastic, but I'm afraid to touch it myself.
> >  >
> >  > Mike
> >
> > Mike, all:
> >
> > Suggestion:  Let's just abandon the v1.0.x branch, stabilize master,
> and
> > get a release out.  (Easy for me to say--I have never contributed to
> the
> > actual release process.)  I think that we really need to get releases
> > out more frequently--that needs to become a higher priority.  I don't
> > think it is even worth the trouble to maintain a maintenance branch
> at
> > all.  It adds quite a bit of complexity to the development and
> release
> > process--every time a bug is found, the fix has to be developed on
> > maintenance, committed and pushed, checked on master, and propagated
> to
> > master.  It's not worth it. The differences between master and
> > maintenance are normally not large enough to justify keeping them
> > separate, given our very constrained people-time resources.
> >
> > Note that a release doesn't have to be made from master HEAD; git
> > branching is extremely flexible, so at any time, one can make a
> branch
> > from any point on the tree, do some checking and adjustment, and
> release
> > it.  Where we get into difficulty and waste time is in trying to
> > maintain a separate maintenance branch for a long period.  We just
> don't
> > have the resources to do this well; and we don't really need to do it
> at
> > all.
> >
> > Eric
> >
> >
> > Actually, there are plenty of differences between v1.0.x and master.  We
> > have a number of new features that are baking right now (animations, for
> > example).  I have personally made a number of changes with mplot3d that,
>
> Are you referring to animations.py?  The last change in that file on
> master was 9 months ago.
>
>
Yeah... I guess we really haven't exercised it.  However, I know some of my
existing animation code based on it is broken and I have spotted a few
potential issues in parts of the code.  However, Ryan May is currently on
the finishing end of his Dissertation work (while I am only at the start of
it), and I doubt we will get much more out of him for a few more months.


>
> > in some cases, were too risky to apply to v1.0.x and I just wanted them
> > to sit in the official development branch rather than in the stable
> > branch.  Also, because there is not much of downstream activity to the
> > repos, I think many of the packagers depend upon the bugfixes we apply
> > to the maintenance branches.  I am hesitant to change development
> > policies without a clear consideration for downstream.
> >
>
> Do the packagers use the tip of the maintenance branch, or do they use
> the most recent release?  If the former, then that bumps up the priority
> of keeping such a branch.  If the latter, it bumps up the priority of
> having frequent high-quality releases, regardless of what they are called.
>
>
>
I think that is dependent upon the repo.  It seems that Ubuntu tends to stay
near the release, while I have seen some other repos stay very up to date (I
forget which one I saw).  However, many of the changes we make are bugfixes
and then transition to feature changes.


> > The current practice worked very nicely with SVN (IMHO), and I think it
>
> (I recall that Mike had to rescue us more than once from svnmerge
> confusions, at least during the earlier days.)
>
>
So, it appears we have difficulties with new technologies?


>  > still works fine.  Most of the issues is really limited to svn --> git
> > transitions and understanding how git works.  I will agree that it is
> > possible that the v1.0.x branch might be damaged beyond repair.  I am
> > not enough of a git expert to know one way or another.
> >
> > As for the comment about getting releases out faster, this contradicts
> > your assertion that we don't have the manpower to take care of the
> > maintenance branch.  We do need better planning for milestones and
>
> I don't see the contradiction or inconsistency.  I am not saying we
> *can't* keep a maintenance branch; I am saying it is not clear to me
> that it is worth the fuss to do so indefinitely, especially when it is
> infrequently released.
>
>
Well, I never really saw it as indefinite.  I thought it was defined as
maintaining the current release.  So, whenever we release v1.1.0, then we no
longer work on v1.0.x and bugfixe

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Matthew Brett 
Hi,

On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing  wrote:
>> The current practice worked very nicely with SVN (IMHO), and I think it
>
> (I recall that Mike had to rescue us more than once from svnmerge
> confusions, at least during the earlier days.)

I was just idly looking at the matplotlib network graph:

https://github.com/matplotlib/matplotlib/network

There seem to be lots of branches and cross merges ; the history of
1.0.x is extremely confusing.

I wonder whether it would be worthwhile to review git workflow?

I like Pauli's edits to the numpy gitwash docs in numpy for this.
I've actually just merged these back into the gitwash main docs,
example build here:

http://matthew-brett.github.com/pydagogue/gitwash/git_development.html

Maybe the overall point is that git does require some thought to
history, and some rules-of-work, to avoid confusion.

I've been managing a maintenance branch for my much smaller nibabel
project without much trouble; I've just been doing the occasional
cherry-pick and rebase from trunk for bugfixes.

Cheers,

Matthew

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Darren Dale 
On Wed, Jun 1, 2011 at 6:38 PM, Matthew Brett  wrote:
> Hi,
>
> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing  wrote:
>>> The current practice worked very nicely with SVN (IMHO), and I think it
>>
>> (I recall that Mike had to rescue us more than once from svnmerge
>> confusions, at least during the earlier days.)
>
> I was just idly looking at the matplotlib network graph:
>
> https://github.com/matplotlib/matplotlib/network
>
> There seem to be lots of branches and cross merges ; the history of
> 1.0.x is extremely confusing.
>
> I wonder whether it would be worthwhile to review git workflow?
>
> I like Pauli's edits to the numpy gitwash docs in numpy for this.
> I've actually just merged these back into the gitwash main docs,
> example build here:
>
> http://matthew-brett.github.com/pydagogue/gitwash/git_development.html
>
> Maybe the overall point is that git does require some thought to
> history, and some rules-of-work, to avoid confusion.
>
> I've been managing a maintenance branch for my much smaller nibabel
> project without much trouble; I've just been doing the occasional
> cherry-pick and rebase from trunk for bugfixes.

I have a simpler rule of thumb. When merging work to push to the
matplotlib repository: inspect the history graph before the merge,
perform the merge locally, and inspect the graph after the merge but
before the push. Inspecting the history graph doesn't take long. If
the graph doesn't look the way you anticipated (unexplained or
unexpected complexity), don't push to the matplotlib repo. If you are
unsure or want help, push to your personal fork and post to the
mailing list. If you don't know how the history graph should look
after the merge, you aren't ready to push that merge to the matplotlib
repo.

Darren

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Eric Firing 
On 06/01/2011 12:38 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing  wrote:
>>> The current practice worked very nicely with SVN (IMHO), and I think it
>>
>> (I recall that Mike had to rescue us more than once from svnmerge
>> confusions, at least during the earlier days.)
>
> I was just idly looking at the matplotlib network graph:
>
> https://github.com/matplotlib/matplotlib/network
>
> There seem to be lots of branches and cross merges ; the history of
> 1.0.x is extremely confusing.

Agreed!

>
> I wonder whether it would be worthwhile to review git workflow?

Yes.

>
> I like Pauli's edits to the numpy gitwash docs in numpy for this.
> I've actually just merged these back into the gitwash main docs,
> example build here:

I will have to take a look; mpl did pull some version of gitwash into 
its doc build.

>
> http://matthew-brett.github.com/pydagogue/gitwash/git_development.html

Thanks, I will take a look.

>
> Maybe the overall point is that git does require some thought to
> history, and some rules-of-work, to avoid confusion.

I think one of the problems is that documentation such as the Git book 
and at least early versions of gitwash, if I remember correctly, 
emphasize workflow for people who do not access the central repo 
directly.  There has been much discussion on the lists of procedure for 
those who do push to central repos, but I am not sure to what extent it 
has gotten condensed down into a sufficiently simple set of rules and 
examples in the standard documentation.  Maybe you and Pauli have done 
that now.


>
> I've been managing a maintenance branch for my much smaller nibabel
> project without much trouble; I've just been doing the occasional
> cherry-pick and rebase from trunk for bugfixes.

In a way, this illustrates the difficulty: you describe a procedure for 
working with a maintenance branch that is completely different from the 
one we have been using (apart from the errors). What we have been doing 
is initiating bug fixes in the maintenance branch and then merging that 
branch to master.  I'm sure either way can work fine, if one doesn't 
make mistakes.  I'm not sure what the relative merits of the two methods 
are, in terms of simplicity, clarity, and robustness against errors. I 
think they result in very different graphs, correct?  With your 
approach, the maintenance branch and master are separate lines, while 
with our approach, the merges keep pulling the branches together in the 
graph, even though their contents are steadily getting farther apart.

Eric

>
> Cheers,
>
> Matthew

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Matthew Brett 
Hi,

On Wed, Jun 1, 2011 at 4:05 PM, Darren Dale  wrote:
> On Wed, Jun 1, 2011 at 6:38 PM, Matthew Brett  wrote:
>> Hi,
>>
>> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing  wrote:
 The current practice worked very nicely with SVN (IMHO), and I think it
>>>
>>> (I recall that Mike had to rescue us more than once from svnmerge
>>> confusions, at least during the earlier days.)
>>
>> I was just idly looking at the matplotlib network graph:
>>
>> https://github.com/matplotlib/matplotlib/network
>>
>> There seem to be lots of branches and cross merges ; the history of
>> 1.0.x is extremely confusing.
>>
>> I wonder whether it would be worthwhile to review git workflow?
>>
>> I like Pauli's edits to the numpy gitwash docs in numpy for this.
>> I've actually just merged these back into the gitwash main docs,
>> example build here:
>>
>> http://matthew-brett.github.com/pydagogue/gitwash/git_development.html
>>
>> Maybe the overall point is that git does require some thought to
>> history, and some rules-of-work, to avoid confusion.
>>
>> I've been managing a maintenance branch for my much smaller nibabel
>> project without much trouble; I've just been doing the occasional
>> cherry-pick and rebase from trunk for bugfixes.
>
> I have a simpler rule of thumb. When merging work to push to the
> matplotlib repository: inspect the history graph before the merge,
> perform the merge locally, and inspect the graph after the merge but
> before the push. Inspecting the history graph doesn't take long. If
> the graph doesn't look the way you anticipated (unexplained or
> unexpected complexity), don't push to the matplotlib repo. If you are
> unsure or want help, push to your personal fork and post to the
> mailing list. If you don't know how the history graph should look
> after the merge, you aren't ready to push that merge to the matplotlib
> repo.

Sounds right to me :)  Pauli actually has the same rule, I discovered:

http://matthew-brett.github.com/pydagogue/gitwash/maintainer_workflow.html#check-the-history

See you,

Matthew

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.0.x branch seems confused

2011-06-01 Thread Matthew Brett 
Hi,

On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing  wrote:
> On 06/01/2011 12:38 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing  wrote:
 The current practice worked very nicely with SVN (IMHO), and I think it
>>>
>>> (I recall that Mike had to rescue us more than once from svnmerge
>>> confusions, at least during the earlier days.)
>>
>> I was just idly looking at the matplotlib network graph:
>>
>> https://github.com/matplotlib/matplotlib/network
>>
>> There seem to be lots of branches and cross merges ; the history of
>> 1.0.x is extremely confusing.
>
> Agreed!
>
>>
>> I wonder whether it would be worthwhile to review git workflow?
>
> Yes.
>
>>
>> I like Pauli's edits to the numpy gitwash docs in numpy for this.
>> I've actually just merged these back into the gitwash main docs,
>> example build here:
>
> I will have to take a look; mpl did pull some version of gitwash into
> its doc build.
>
>>
>> http://matthew-brett.github.com/pydagogue/gitwash/git_development.html
>
> Thanks, I will take a look.

If you like what you see, then the 'gitwash_dumper.py' script will
pull a new copy into your repo...

If you don't, then I'd love suggestions for improvements.

>> Maybe the overall point is that git does require some thought to
>> history, and some rules-of-work, to avoid confusion.
>
> I think one of the problems is that documentation such as the Git book
> and at least early versions of gitwash, if I remember correctly,
> emphasize workflow for people who do not access the central repo
> directly.  There has been much discussion on the lists of procedure for
> those who do push to central repos, but I am not sure to what extent it
> has gotten condensed down into a sufficiently simple set of rules and
> examples in the standard documentation.  Maybe you and Pauli have done
> that now.

That's quite right, we did more or less assume that the maintainers
were git experts, and yes, Pauli did fix that to some extent.  The
result, as ported back by me, is this page, which is new, and needs
expanding:

http://matthew-brett.github.com/pydagogue/gitwash/maintainer_workflow.html

>>
>> I've been managing a maintenance branch for my much smaller nibabel
>> project without much trouble; I've just been doing the occasional
>> cherry-pick and rebase from trunk for bugfixes.
>
> In a way, this illustrates the difficulty: you describe a procedure for
> working with a maintenance branch that is completely different from the
> one we have been using (apart from the errors). What we have been doing
> is initiating bug fixes in the maintenance branch and then merging that
> branch to master.  I'm sure either way can work fine, if one doesn't
> make mistakes.  I'm not sure what the relative merits of the two methods
> are, in terms of simplicity, clarity, and robustness against errors. I
> think they result in very different graphs, correct?  With your
> approach, the maintenance branch and master are separate lines, while
> with our approach, the merges keep pulling the branches together in the
> graph, even though their contents are steadily getting farther apart.

I must confess that my git fu is not 10/10, but to me the idea of
_merging_ the maintenance branch into trunk is very confusing.I
mean, the trees should increasingly diverge, surely, so there will be
more and more stuff you don't want to see back in trunk.  At the
moment, you have to trust git magic to correctly leave out the commits
you don't want...

See you,

Matthew

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel