Malte Dik <malte.dik@...9...> 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
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
···
On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen <jks@...278...> wrote:
I agree that there should be a release before the transition.
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
···
On 05/30/2010 05:54 AM, John Hunter wrote:
On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen<jks@...278...> wrote:
JDH
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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 Sun, May 30, 2010 at 12:05 PM, Eric Firing <efiring@...229...> 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.
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 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
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
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.
JDH
···
On Sun, May 30, 2010 at 1:15 PM, John Hunter <jdh2358@...149...> wrote:
On Sun, May 30, 2010 at 12:05 PM, Eric Firing <efiring@...229...> 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.
John Hunter wrote:
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3
I'm running Fedora 13, and it mostly works but the config output says that
Tkinter isn't there, but it is. It finds Qt4 OK, but seems to have trouble
finding tkinter and agg. I just did the yum install for these things, it's
only with matplotlib that I have a devel version. What is it looking for and
where do I look to see?
···
--
Dr. Tom
---
I would dance and be merry,
Life would be a ding-a-derry,
If I only had a brain.
-- The Scarecrow
John Hunter wrote:
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3
I'm running Fedora 13, and it mostly works but the config output says that
Tkinter isn't there, but it is. It finds Qt4 OK, but seems to have trouble
finding tkinter and agg. I just did the yum install for these things, it's
only with matplotlib that I have a devel version. What is it looking for and
where do I look to see?
Make sure you have the tk-devel and tcl-devel packages installed.
Also, try editing setup.cfg
> cp setup.cfg.template setup.cfg
and set
tkagg = True
to force a tkagg build (rather than an autobuild).
Do a clean rebuild (rm -rf build) and post the results of the
build/compile if you have problems.
JDH
···
On Wed, Jun 2, 2010 at 12:34 PM, Tom Holroyd (NIH/NIMH) [E] <tomh@...234...> wrote: