On Mon, Nov 12, 2012 at 3:44 PM, Paul Ivanov <pivanov...@gmail.com> wrote:
> Hey everyone,
>
> So I don't have a clear picture in my head of our development cycle, and I
> don't think it's well documented. I didn't want thread jack, but in another
> thread Mike wrote:
>
> On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <md...@stsci.edu>
> wrote:
> > (BTW -- feel free to submit pull requests at any point in a release
> > cycle -- we have both a master and a maintenance branch, so we can work
> > on new stuff and stable stuff at the same time).
>
> My first question is, how are these two branches related, because I've
> been submitting things against master, and then switching it to be against
> 1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes,
> and master is for new features.
>
>
That is correct.
> Can someone clarify the current process, with a section like "Submitting
> new Pull Requests" - this should probably go into one of these places:
> http://matplotlib.org/devel/coding_guide.html
> http://matplotlib.org/devel/gitwash/index.html
>
>
This is the essence of the gitwash process. Perhaps it needs to be clearer.
> My second question is that, if I do have the right idea about the current
> process, and the distinction between master and 1.2.x, should we change
> this? (I think we should).
>
> The trouble is that it seems to me now for a bugfix, if it is submitted
> against 1.2.x, it won't be fixed in master until changes from 1.2.x are
> merged back into master. So now as a developer trying to follow "bleeding
> edge" matplotlib, I either have to live with bugs that have been fixed in
> 1.2.x if I want the features from master, or if I want the bug fixes and
> follow 1.2.x, I miss the new features in master.
>
>
A general rule is that whoever merges a bugfix to the maintenance branch
should then also manually merge the maintenance branch down to master.
> I think that the mental picture is sufficiently clearer if *everything*
> (bugfixes and new features) go into master, and then we backport the
> critical bugfixes against 1.2.x. This would be easier to do if the core
> developer merging the bugfix into master at least opens an issue for as a
> placeholder / reminder for the bugfix being a candidate to go into
> the maintenance branch. Because it seems like at this point, we aren't even
> sure if we're going to do a 1.2.1 release...
>
>
There are other git workflows, which are all perfectly valid. If you can
convince us to use another, feel free to propose one. However, we have
done a couple of releases with gitwash, and it has worked quite well for us
given how small our maintenance overhead is. Just have to remember to
regularly merge the maintenance branch to master. That's all.
Cheers!
Ben Root
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
