matplotlib-devel Mailing List for matplotlib

On Sun, May 30, 2010 at 1:15 PM, John Hunter <jd...@gm...> wrote:
> On Sun, May 30, 2010 at 12:05 PM, Eric Firing <ef...@ha...> wrote:
>> Do you have in mind a dual release--maintenance branch and trunk--or is
>> v0_99_maint abandoned with no release? Another option would be to make
>> a 99 release ASAP and delay the 1.0.
>
> I do want to put out one last maintenance branch release -- I put up
> an rc some time ago and heard no problems so it is good to go. I will
> do it this weekend.
This is done -- the source, win32 binaries and osx binaries have been
uploaded the the sf site, and the site docs are updated to 99.3. I'll
hold off til Tuesday for the official announce.
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3
JDH

Hi,
>> 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.
>
> The github TOS allow only one person per account. I guess that's why
> Eric refers to an exception being required.
It's trivial to add people as collaborators to a github repository
(the Admin panel Eric mentioned); that's the equivalent of SVN
per-repository permissions. Adding collaborators gives the
collaborator push access to the repo with their own github user / ssh
key.
http://github.com/guides/managing-collaborators
I guess, by one-person-per-account, github means that only one person
should be logging into the account and administering it, but they did
agree with Fernando a while ago that it was OK to have project
accounts:
http://support.github.com/discussions/email/6289-contact-per-project-account-for-open-source-projects?anon_token=5139fe18a00792fd470a9fe3b7bca187b64ddb8d
See you,
Matthew

On 05/30/2010 05:54 AM, John Hunter wrote:
> now. Everyone who has some free time should tackle outstanding bugs
> on the tracker. I am aware of a compile problem on solaris with CXX6
Appeal to all developers, official or not: there are 95 open bugs listed 
on the tracker at the moment.
I suspect several of these have actually been fixed already--like the 
most recent one, for example--and only need to be closed, ideally with a 
reference to the svn commit that fixed the problem. If you have been 
committing bug fixes, please scan the tracker list, and see if there 
some tickets that you can close as a result of work you have already done.
Beyond that, there are probably quite a few tickets that are out of 
date, or reflect a misunderstanding, or can otherwise be closed fairly 
easily. Please try to identify them and close them.
And last but not least, I'm sure there are real problems identified by 
some of the tickets; and some of them have solutions attached, requiring 
only a review of the proposed solution, possibly some editing and 
testing, and a commit.
Eric

On Sun, May 30, 2010 at 12:05 PM, Eric Firing <ef...@ha...> wrote:
> Do you have in mind a dual release--maintenance branch and trunk--or is
> v0_99_maint abandoned with no release? Another option would be to make
> a 99 release ASAP and delay the 1.0.
I do want to put out one last maintenance branch release -- I put up
an rc some time ago and heard no problems so it is good to go. I will
do it this weekend.
JDH

On 05/30/2010 05:54 AM, John Hunter wrote:
> On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen<jk...@ik...> wrote:
>
>> I agree that there should be a release before the transition.
>
> I was initially reluctant to do a release before the transition
> because of the get_sample_data issue. I was worried that some 1.x
> releases would point to the sf site and some to the github site. I am
> less concerned about that now because we can simply keep the old data
> on the sf site and so releases pointing to it will continue to work
> for the vast majority of examples, and because Jouni has verified that
> the same code works on sf and github modulo a url change.
>
> I will invest some time in the upcoming week getting ready for the
> release. We can target a release candidate for testing a week from
> now. Everyone who has some free time should tackle outstanding bugs
> on the tracker. I am aware of a compile problem on solaris with CXX6
> that we now use, so I will see if I can make some progress on that.
>
John,
Do you have in mind a dual release--maintenance branch and trunk--or is 
v0_99_maint abandoned with no release? Another option would be to make 
a 99 release ASAP and delay the 1.0.
Eric
> JDH
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> I agree that there should be a release before the transition.
I was initially reluctant to do a release before the transition
because of the get_sample_data issue. I was worried that some 1.x
releases would point to the sf site and some to the github site. I am
less concerned about that now because we can simply keep the old data
on the sf site and so releases pointing to it will continue to work
for the vast majority of examples, and because Jouni has verified that
the same code works on sf and github modulo a url change.
I will invest some time in the upcoming week getting ready for the
release. We can target a release candidate for testing a week from
now. Everyone who has some free time should tackle outstanding bugs
on the tracker. I am aware of a compile problem on solaris with CXX6
that we now use, so I will see if I can make some progress on that.
JDH

Malte Dik <mal...@we...> writes:
> Eric Firing wrote:
>
>> 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. 
>
> 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.
The github TOS allow only one person per account. I guess that's why
Eric refers to an exception being required.
I'm not entirely sure what Github's "public collaborator" feature means
(I can only find documentation about private collaborators, which you
can add if you have a paid account and a private project), but if it
means push access, then I suppose it would help.
>> 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.
Sounds good to me. One possibility is to have an automated tool push
reviewed and tested changes to the "official" repository, similarly to
how the Android Open-Source Project uses Gerrit:
http://source.android.com/source/life-of-a-patch.html
The "verifier" could be just a buildbot-run script that sets the
verified flag if the code passes tests. The "reviewers" could be the
core developers - so instead of pulling other people's changes and
pushing to the official repository, they would just flag the changes as
verified, and the rest would happen automatically.
But maybe that's too much overhead for a project the size of matplotlib.
>> 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.
I agree that there should be a release before the transition. 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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