Hello all,
in some time (let's say a couple of months, maybe more) Debian will
enter the "freeze" period, where no new upstream releases are
accepted, in order to prepare the best stable release we can 
In the past months I see many changes are accumulated in the SVN but
no new release are done. I don't know if you've already discussed
about releasing mpl, but it would be nice if we can have something
before the freeze, so to have a quite-update mpl in squeeze.
From my POV, I'll provide all the support needed, so if there
something I can do just tell me
Regards,
路路路
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Hey Sandro,
thanks for the head's up. We would like to get a 1.0 release out and
there are two roadbumps we have to navigate first. We'd like to
transition our VCS to git, and this impacts our release schedule
because of the "get_sample_data" support in the trunk which currently
pulls the data from svn but would have to be refactored to pull from
hit and we'd like to make the transition before we do a release.
Andrew, who is handling the git transition, has been very tied up of
late, but thinks he'll have some time in early May. The other issue
is my dead OSX build box -- I have access to a 64bit python 2.6
platform for builds for OSX, but currently no other platforms/versions
so I have to sink some time into this for a release, though this is
not a show stopper as we could do a release with incomplete binary
support for OSX.
So keep our feet to the fire and make sure we don't fall too far
behind so we can get something out before the freeze, hopefully far
enough before the freeze that we can get at least one bugfix release
out...
JDH
路路路
On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi <morph@...12...> wrote:
Hello all,
in some time (let's say a couple of months, maybe more) Debian will
enter the "freeze" period, where no new upstream releases are
accepted, in order to prepare the best stable release we can
In the past months I see many changes are accumulated in the SVN but
no new release are done. I don't know if you've already discussed
about releasing mpl, but it would be nice if we can have something
before the freeze, so to have a quite-update mpl in squeeze.
>From my POV, I'll provide all the support needed, so if there
something I can do just tell me
Hello all,
in some time (let's say a couple of months, maybe more) Debian will
enter the "freeze" period, where no new upstream releases are
accepted, in order to prepare the best stable release we can
In the past months I see many changes are accumulated in the SVN but
no new release are done. I don't know if you've already discussed
about releasing mpl, but it would be nice if we can have something
before the freeze, so to have a quite-update mpl in squeeze.
> From my POV, I'll provide all the support needed, so if there
something I can do just tell me
Hey Sandro,
thanks for the head's up. We would like to get a 1.0 release out and
there are two roadbumps we have to navigate first. We'd like to
transition our VCS to git, and this impacts our release schedule
John et al.,
1) It looks like numpy is about to make the jump to github. Their discussion includes interesting points of strategy. Their intention is to develop the strategy via an NEP.
2) If I understand correctly, a key question is who will have commit rights to the master repo on github. It seems that an exception is required to allow that access to more than one person. My sense is that ideally we should have more than one person with that access, but far fewer people than presently have svn commit access. Those with access would then be asked to pull changes into the master from other people's clones--which would be github branches under their control.
3) Is it really a good idea to delay the release until the we make the github transition? Given how long it has been since a release, and the possibility that there will be some turbulence until we have had some experience with github, I think it would be better to release first and transition immediately afterwards.
Eric
路路路
On 04/23/2010 02:44 AM, John Hunter wrote:
On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi<morph@...12...> wrote:
because of the "get_sample_data" support in the trunk which currently
pulls the data from svn but would have to be refactored to pull from
hit and we'd like to make the transition before we do a release.
Andrew, who is handling the git transition, has been very tied up of
late, but thinks he'll have some time in early May. The other issue
is my dead OSX build box -- I have access to a 64bit python 2.6
platform for builds for OSX, but currently no other platforms/versions
so I have to sink some time into this for a release, though this is
not a show stopper as we could do a release with incomplete binary
support for OSX.
So keep our feet to the fire and make sure we don't fall too far
behind so we can get something out before the freeze, hopefully far
enough before the freeze that we can get at least one bugfix release
out...
JDH
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
I've had unanticipated time commitments come up that have limited the time I have available for work on MPL. I had been planning spending some time to facilitate a switch to git but now can't see where the time will come from (in the next several weeks at least). Therefore I think making a release before any VCS switch is a good idea.
-Andrew
路路路
On Sat, 29 May 2010 12:28:40 -1000, Eric Firing <efiring@...229...> wrote:
3) Is it really a good idea to delay the release until the we make the
github transition? Given how long it has been since a release, and the
possibility that there will be some turbulence until we have had some
experience with github, I think it would be better to release first and
transition immediately afterwards.
Hi,
2) If I understand correctly, a key question is who will have commit
rights to the master repo on github. It seems that an exception is
required to allow that access to more than one person. My sense is that
ideally we should have more than one person with that access, but far
fewer people than presently have svn commit access. Those with access
would then be asked to pull changes into the master from other people's
clones--which would be github branches under their control.
Multiple options (as far as I have understand github). You could use one
account with multiple ssh-keys or you can add "contributors" to the repository
in the repositorys Admin-panel, which I haven't tried out, yet.
Regards,
Malte