[Pyrex] ANN: Pyrex 0.9.6

[Gustavo Sverzut Barbieri]

On 10/8/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Gustavo Sverzut Barbieri wrote:
> > Greg, what are your points to not have a public repository with
> > incremental changes?
>
> I'm considering it, but I haven't thought through all the
> implications of how it would work.
>
> I don't think I'm ready to let people make direct patches
> to it yet. I find it an extreme intellectual challenge to
> keep track of how it all works. I don't just apply patches
> as-is -- I need to examine each one carefully to make sure
> it isn't going to have any unforeseen consequences, and to
> keep my own mental model of the whole thing up to date.
>
> I could perhaps establish a repository and let people add
> things in branches, but the main trunk wouldn't look much
> different from the current sequence of released versions.
> Any contributed patches would likely end up in the trunk
> in a quite different form, if at all.

I understand what you mean and I'd suggest "GIT" as your tool. Its
usage is basically "your repo is your repo, nobody touches it". You
can publish, have branches, merge and keep the history, but just you
can import others changes, no matter if it's automatically or
hand-writing.

Then Stefan, Robert, me and other guys could just "rebase" our work on
yours, develop our own branches and when we're stable enough we could
ask you to review some changes and possible integrate or just base
your work on it. The point here, for us externals, is that with GIT
we're able to rewrite/edit commits, that is, GIT makes easy to go to
past, fix some issues and then recommit, having very clean tree (and
not a bunch of "fix this issue with previous commit", "add missing
file"). You could just request us to "fix that coding style from the
1st patch and that algorithm from the 3rd" and it's doable.

This is the way our team is working here at INdT and also how the
Linux Kernel works, so it scales from a 3-4 people to hundreds, can be
hierarchical and will let you have all the control over the "official"
repository.


> Keep in mind that I'm still *designing* Pyrex. When I
> modify it, I'm not just patching the code, I'm patching
> the design, and that's not something you can automate with
> a source code control tool.

sure


> > We were not aware that you were about to release
> > a new version and couldn't help you with testing, that's really bad!
>
> Well, you're helping now. :-) I suppose I could have called
> it 0.9.6rc1 or something, but there's little practical
> difference. The version number is still less than 1.0,
> you'll notice. As far as I'm concerned, *all* of the
> versions released so far are alpha, beta, rc, or whatever
> you like to call them.
>
> > Sorry, but those points lead my team to change from Pyrex to Cython.
>
> I'll give the idea of a repository further consideration.
> In the meantime, if Cython fills a need as a repository of
> experimental Pyrex patches, I'm very happy for you to use it
> as such.

If you want to try GIT, just install version >= 1.5 and "git init",
"git add" and then "git commit", that's the basics, but you'll find
tons of reference manuals, tutorials, cheat sheets and even crash
course for CVS and SVN users. Newer versions work on Linux, MacOS and
even Windows.

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbieri at gmail.com
   MSN: barbieri at gmail.com
  ICQ#: 17249123
 Skype: gsbarbieri
Mobile: +55 (81) 9927 0010