Hosted CI (#7)
Josh Moore
I'm open to suggestions, but if we decide to stick with hudson.o.o.uk, then I'll probably add an "integration" job which merges all branches matching some pattern and builds that integration commit (cF. https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin). Then, instead of merging into "master" we merge into "integration" (or whatever) and Jenkins should do the testing for us.
Cheers,
~Josh.
Anthony Scopatz
Antonio Valentino
On 13 Set, 22:15, Josh Moore <josh.mo...@gmx.de> wrote:
> Just ran across another hosting solution,https://www.shiningpanda.com/pricing/, which has a FOSS plan. I found it while looking into their plugin (https://wiki.jenkins-ci.org/display/JENKINS/ShiningPanda+Plugin) for virtualenv builds. I don't know if I can get the rest of the dev team logins to hudson.o.o.uk, which may eventually become a barrier. For example, testinghttps://github.com/PyTables/PyTables/pull/111would probably be easier if you could spin up another job.
>
Very interesting.
It looks that shiningpanda.com only offers 1 hour/day per project so
running heavy test there is impossible.
Anyway I like the idea of having direct access to the CI platform.
Makes it sense to use both (maybe with different tasks)?
> I'm open to suggestions, but if we decide to stick with hudson.o.o.uk, then I'll probably add an "integration" job which merges all branches matching some pattern and builds that integration commit (cF.https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin). Then, instead of merging into "master" we merge into "integration" (or whatever) and Jenkins should do the testing for us.
Josh, I was thinking to send a mail next week (after 2.3 final) to
decide with you all some details about the repository management:
stable/maintenance branches, development branches, if and when to
create a branch for py3k and so on.
I'm OK with the idea of having an "integration" branch but IMO it
would be nice also to define an "official" policy for the repository.
What do you think about?
regards
--
Antonio Valentino
Josh Moore
On Sep 14, 2011, at 9:11 AM, Antonio Valentino wrote:
> Hi Josh,
>
> On 13 Set, 22:15, Josh Moore <josh.mo...@gmx.de> wrote:
>> Just ran across another hosting solution,https://www.shiningpanda.com/pricing/, which has a FOSS plan. I found it while looking into their plugin (https://wiki.jenkins-ci.org/display/JENKINS/ShiningPanda+Plugin) for virtualenv builds. I don't know if I can get the rest of the dev team logins to hudson.o.o.uk, which may eventually become a barrier. For example, testinghttps://github.com/PyTables/PyTables/pull/111would probably be easier if you could spin up another job.
>>
>
> Very interesting.
> It looks that shiningpanda.com only offers 1 hour/day per project so
> running heavy test there is impossible.
> Anyway I like the idea of having direct access to the CI platform.
>
> Makes it sense to use both (maybe with different tasks)?
Quite possibly, yes. Perhaps the more day to day checking of pulls requests on shiningpanda if/when they accept us! (I just registered us under https://jenkins.shiningpanda.com/pytables/ -- this will need to be added to the front page of the webpage). And then the more release focused/cross-platform/heavy testing on the OME resources.
>> I'm open to suggestions, but if we decide to stick with hudson.o.o.uk, then I'll probably add an "integration" job which merges all branches matching some pattern and builds that integration commit (cF.https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin). Then, instead of merging into "master" we merge into "integration" (or whatever) and Jenkins should do the testing for us.
>>
>> Cheers,
>> ~Josh.
>>
>> See:https://github.com/PyTables/PyTables/issues/7
>
>
> Josh, I was thinking to send a mail next week (after 2.3 final) to
> decide with you all some details about the repository management:
> stable/maintenance branches, development branches, if and when to
> create a branch for py3k and so on.
>
> I'm OK with the idea of having an "integration" branch but IMO it
> would be nice also to define an "official" policy for the repository.
>
> What do you think about?
Completely agreed. I'd suggest IRC. ;)
~J.
> regards
>
> --
> Antonio Valentino
Antonio Valentino
Il giorno Wed, 14 Sep 2011 09:32:52 +0200
Josh Moore <josh....@gmx.de> ha scritto:
>
> On Sep 14, 2011, at 9:11 AM, Antonio Valentino wrote:
>
> > Hi Josh,
> >
> > On 13 Set, 22:15, Josh Moore <josh.mo...@gmx.de> wrote:
> >> Just ran across another hosting
> >> solution,https://www.shiningpanda.com/pricing/, which has a FOSS
> >> plan. I found it while looking into their plugin
> >> (https://wiki.jenkins-ci.org/display/JENKINS/ShiningPanda+Plugin)
> >> for virtualenv builds. I don't know if I can get the rest of the
> >> dev team logins to hudson.o.o.uk, which may eventually become a
> >> barrier. For example,
> >> testinghttps://github.com/PyTables/PyTables/pull/111would probably
> >> be easier if you could spin up another job.
> >>
> >
> > Very interesting.
> > It looks that shiningpanda.com only offers 1 hour/day per project so
> > running heavy test there is impossible.
> > Anyway I like the idea of having direct access to the CI platform.
> >
> > Makes it sense to use both (maybe with different tasks)?
>
> Quite possibly, yes. Perhaps the more day to day checking of pulls
> requests on shiningpanda if/when they accept us! (I just registered
> us under https://jenkins.shiningpanda.com/pytables/ -- this will need
> to be added to the front page of the webpage). And then the more
> release focused/cross-platform/heavy testing on the OME resources.
>
The code for generating http://pytables.github.com/ is currently in the
docs branch on my fork (you all should have commit access).
We also have a couple of wiki pages that point to/should point to the
CI page:
https://github.com/PyTables/PyTables/wiki/Links
https://github.com/PyTables/PyTables/wiki/Development
I will wait for a final confirmation from you to update them.
> >> I'm open to suggestions, but if we decide to stick with
> >> hudson.o.o.uk, then I'll probably add an "integration" job which
> >> merges all branches matching some pattern and builds that
> >> integration commit
> >> (cF.https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin). Then,
> >> instead of merging into "master" we merge into "integration" (or
> >> whatever) and Jenkins should do the testing for us.
> >>
> >> Cheers,
> >> ~Josh.
> >>
> >> See:https://github.com/PyTables/PyTables/issues/7
> >
> >
> > Josh, I was thinking to send a mail next week (after 2.3 final) to
> > decide with you all some details about the repository management:
> > stable/maintenance branches, development branches, if and when to
> > create a branch for py3k and so on.
> >
> > I'm OK with the idea of having an "integration" branch but IMO it
> > would be nice also to define an "official" policy for the
> > repository.
> >
> > What do you think about?
>
> Completely agreed. I'd suggest IRC. ;)
> ~J.
>
> > regards
> >
> > --
> > Antonio Valentino
>
Well, my idea was to have a couple o mail rounds to collect ideas and
alternatives (we could also use the wiki for drafts).
Which are common schemas?
We could schedule the IRC meeting after, if there is still something to
discuss.
If there is a large agreement during the mail discussion we could just
formalize the decision with a vote on the ML.
I'm relatively newbie with DVCS management so I would like that a
proposal for the repository management could come for someone more
expert than me.
If no one has time to do it I could try to submit one in next days.
Regards
--
Antonio Valentino
Josh Moore
In OME, we are following pretty closely http://nvie.com/posts/a-successful-git-branching-model/ (i.e. "git-flow"). We're just starting to evaluate github, in which case that may change.
The first thing that needs to be decided really is whether version management is going to take a rebase or a merge workflow. Briefly, in a rebasing model bug fix commits from 2_3 (2_2, etc) are rebase --onto'd/cherry-picked/format-patched to master (or "develop" in the case of git-flow). I've got some infrastructure for doing that kind of tracking[1]. In the merge workflow, a branch would be created from 2_3 (2_2 etc) with any bug fixes and that branch could also be merged into master.
The danger of the merge workflow is that you can pull things in which you didn't mean to if we're not careful. Similarly for the rebase workflow, it's possible to lose commits if we're not careful. Mixing and matching is possible but also not ideal.
In terms of just the branch names themselves, we've currently got "2.0-pro", "2.1-pro", "2.2-pro", I'd suggest we add "2.3". Tags all have the prefix "v." so there won't be any conflict. If we're not planning on starting work on 2.4 while working on 2.3.1, I'm fine with branches 2.3 and master being synonymous until we need to differentiate them, but I know Antonio has quite a few items lined up, so it's probably time to split them.
When would the 3.0 branch become active? Also immediately?
Cheers,
~Josh.
P.S. An alternate opinion to git-flow though we aren't deploying a web framework: http://scottchacon.com/2011/08/31/github-flow.html
On Sep 14, 2011, at 10:07 AM, Antonio Valentino wrote:
>>>
>>> Josh, I was thinking to send a mail next week (after 2.3 final) to
>>> decide with you all some details about the repository management:
>>> stable/maintenance branches, development branches, if and when to
>>> create a branch for py3k and so on.
>>>
>>> I'm OK with the idea of having an "integration" branch but IMO it
>>> would be nice also to define an "official" policy for the
>>> repository.
>>>
>>> What do you think about?
>>
>
Antonio Valentino
Hash: SHA1
Hi Josh,
Il 26/09/2011 08:57, Josh Moore ha scritto:
> Finally getting around to branching....
>
> In OME, we are following pretty closely
> http://nvie.com/posts/a-successful-git-branching-model/ (i.e.
> "git-flow"). We're just starting to evaluate github, in which case
> that may change.
>
Thank you very much for the link, very instructive for me.
> The first thing that needs to be decided really is whether version
> management is going to take a rebase or a merge workflow. Briefly, in
> a rebasing model bug fix commits from 2_3 (2_2, etc) are rebase
> --onto'd/cherry-picked/format-patched to master (or "develop" in the
> case of git-flow). I've got some infrastructure for doing that kind
> of tracking[1]. In the merge workflow, a branch would be created from
> 2_3 (2_2 etc) with any bug fixes and that branch could also be merged
> into master.
>
> The danger of the merge workflow is that you can pull things in which
> you didn't mean to if we're not careful. Similarly for the rebase
> workflow, it's possible to lose commits if we're not careful. Mixing
> and matching is possible but also not ideal.
>
Regarding rebase vs merge workflows I think I have a small preference
for merge.
It is simply because it preserves commits that can, eventually, be
referred in ticket comments.
Often I implement some feature/bugfix on my repo and then I publish it
on a temporary branch on my github fork.
This is useful for reviews and for asking comments to other developers
e.g. putting a link to a specific SHA in a comment associated to an issue.
If all is OK and the branch is merged into master/development that SHA
and that link keeps staying valid even if I delete the temporary branch
in my fork.
If rebase is used, instead, all links in issue comments would become
invalid as son as the temp branch is deleted.
IMHO comments on the github issue tracker are a form of documentation
and I would like to preserve them if it is possible.
> In terms of just the branch names themselves, we've currently got
> "2.0-pro", "2.1-pro", "2.2-pro", I'd suggest we add "2.3". Tags all
> have the prefix "v." so there won't be any conflict.
If we decide to follow [1] then branches "2.0-pro", "2.1-pro", "2.2-pro"
should be removed.
Is it correct?
And also, I suppose we are going to support only one version of PyTables
at time,
Isn't it?
> If we're not planning on starting work on 2.4 while working on 2.3.1,
> I'm fine with branches 2.3 and master being synonymous until we need
> to differentiate them, but I know Antonio has quite a few items lined
> up, so it's probably time to split them.
>
2.3.1 will be a bugfix release and IMHO we can make an RC just after the
merge of [#98] (still waiting an OK from you all).
We can handle this using the 2.3 maintenance branch or, following [1],
creating a 2.3.1 release branch (temporary).
I can't say right now if we will ever need a 2.4 release but currently I
start to have too much branches in my repo so I would like to be able to
pushing on a development branch on github.com/PyTables/PyTables.
Maybe it is a good idea to use two different branches:
* one (master or development) for all changes that do not break
compatibility with 2.x line and are not too py3k specific (these
changes can potentially go in 2.4, if it will ever be released)
* and one (py3k or 3.x) for changes that are specific for py3k and
changes that break the API or cause incompatibilities (like numarray,
Numeric and netcdf3 removal, etc.)
The second one can be a temporary branch.
Makes it sense?
[1] http://nvie.com/posts/a-successful-git-branching-model/
[#98] https://github.com/PyTables/PyTables/issues/98
ciao
- --
Antonio Valentino
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6A3oQACgkQ1JUs2CS3bP6CIwCdFsmPe+khmtA+dqh808DXwzje
W/oAniFz2r7Cj7IIcvCwq7Uregzp2mvk
=wFsD
-----END PGP SIGNATURE-----
Josh Moore
On Sep 26, 2011, at 10:20 PM, Antonio Valentino wrote:
>
> Hi Josh,
>
> Il 26/09/2011 08:57, Josh Moore ha scritto:
>> Finally getting around to branching....
>>
>> In OME, we are following pretty closely
>> http://nvie.com/posts/a-successful-git-branching-model/ (i.e.
>> "git-flow"). We're just starting to evaluate github, in which case
>> that may change.
>>
>
> Thank you very much for the link, very instructive for me.
np
>> The first thing that needs to be decided really is whether version
>> management is going to take a rebase or a merge workflow. Briefly, in
>> a rebasing model bug fix commits from 2_3 (2_2, etc) are rebase
>> --onto'd/cherry-picked/format-patched to master (or "develop" in the
>> case of git-flow). I've got some infrastructure for doing that kind
>> of tracking[1]. In the merge workflow, a branch would be created from
>> 2_3 (2_2 etc) with any bug fixes and that branch could also be merged
>> into master.
>>
>> The danger of the merge workflow is that you can pull things in which
>> you didn't mean to if we're not careful. Similarly for the rebase
>> workflow, it's possible to lose commits if we're not careful. Mixing
>> and matching is possible but also not ideal.
>>
>
> Regarding rebase vs merge workflows I think I have a small preference
> for merge. It is simply because it preserves commits that can, eventually, be
> referred in ticket comments.
We're (OME) still not to the point of having a full merge workflow yet, so I can't really comment. If we (PyTables) could come up with one, I'd definitely support it. At the same time, a rebase workflow doesn't necessarily lose commits, though it does change the commit timestamps (as opposed to the author timestamps)
> Often I implement some feature/bugfix on my repo and then I publish it
> on a temporary branch on my github fork.
> This is useful for reviews and for asking comments to other developers
> e.g. putting a link to a specific SHA in a comment associated to an issue.
>
> If all is OK and the branch is merged into master/development that SHA
> and that link keeps staying valid even if I delete the temporary branch
> in my fork.
>
> If rebase is used, instead, all links in issue comments would become
> invalid as son as the temp branch is deleted.
Ah, I understand. You're right, of course. On the OME side, we have private branches where we do the rebasing. Once something's published to the world, we don't delete the SHA1s. With our current (unpaid) github setup, everything is public, so a merge workflow makes much more sense.
> IMHO comments on the github issue tracker are a form of documentation
> and I would like to preserve them if it is possible.
>
>> In terms of just the branch names themselves, we've currently got
>> "2.0-pro", "2.1-pro", "2.2-pro", I'd suggest we add "2.3". Tags all
>> have the prefix "v." so there won't be any conflict.
>
> If we decide to follow [1] then branches "2.0-pro", "2.1-pro", "2.2-pro"
> should be removed.
> Is it correct?
No, I don't think so. Or at least, we don't have to. We're not really planning on committing to those branches, so perhaps it's cleaner to remove them. Every person who forks PyTables/PyTables will have all of those branches locally, so if we don't intend to do something with them, then we can probably chunk them. (We still have the tags, of course).
> And also, I suppose we are going to support only one version of PyTables
> at time,
> Isn't it?
I could imagine having to support 2.x and 3.x simultaneously.
>> If we're not planning on starting work on 2.4 while working on 2.3.1,
>> I'm fine with branches 2.3 and master being synonymous until we need
>> to differentiate them, but I know Antonio has quite a few items lined
>> up, so it's probably time to split them.
>>
>
> 2.3.1 will be a bugfix release and IMHO we can make an RC just after the
> merge of [#98] (still waiting an OK from you all).
commented.
> We can handle this using the 2.3 maintenance branch or, following [1],
> creating a 2.3.1 release branch (temporary).
>
> I can't say right now if we will ever need a 2.4 release but currently I
> start to have too much branches in my repo so I would like to be able to
> pushing on a development branch on github.com/PyTables/PyTables.
> Maybe it is a good idea to use two different branches:
> * one (master or development) for all changes that do not break
> compatibility with 2.x line and are not too py3k specific (these
> changes can potentially go in 2.4, if it will ever be released)
> * and one (py3k or 3.x) for changes that are specific for py3k and
> changes that break the API or cause incompatibilities (like numarray,
> Numeric and netcdf3 removal, etc.)
>
> The second one can be a temporary branch.
>
> Makes it sense?
I think so, but I guess there's the question of whether or not we want to follow git-flow. If so, we'd setup:
* master -- branched off of the v.2.3 tag
* develop -- current state of master (3c3aede)
* feature/py3k -- branches off of either of the other.
In a more traditional setup, I guess that'd leave us with:
* 2.3 -- branched off of v.2.3
* master -- would become 2.4
* 3.0 -- or "py3k" etc.
~J.
Antonio Valentino
Hash: SHA1
Hi Josh,
Il 27/09/2011 19:03, Josh Moore ha scritto:
>
> On Sep 26, 2011, at 10:20 PM, Antonio Valentino wrote:
>>
>> Hi Josh,
>>
>> Il 26/09/2011 08:57, Josh Moore ha scritto:
[CUT]
>>
>> Regarding rebase vs merge workflows I think I have a small
>> preference for merge. It is simply because it preserves commits
>> that can, eventually, be referred in ticket comments.
>
> We're (OME) still not to the point of having a full merge workflow
> yet, so I can't really comment. If we (PyTables) could come up with
> one, I'd definitely support it. At the same time, a rebase workflow
> doesn't necessarily lose commits, though it does change the commit
> timestamps (as opposed to the author timestamps)
>
>> Often I implement some feature/bugfix on my repo and then I publish
>> it on a temporary branch on my github fork. This is useful for
>> reviews and for asking comments to other developers e.g. putting a
>> link to a specific SHA in a comment associated to an issue.
>>
>> If all is OK and the branch is merged into master/development that
>> SHA and that link keeps staying valid even if I delete the
>> temporary branch in my fork.
>>
>> If rebase is used, instead, all links in issue comments would
>> become invalid as son as the temp branch is deleted.
>
> Ah, I understand. You're right, of course. On the OME side, we have
> private branches where we do the rebasing. Once something's published
> to the world, we don't delete the SHA1s. With our current (unpaid)
> github setup, everything is public, so a merge workflow makes much
> more sense.
>
I don't know how much it is important with respect to other aspects.
Just a think I noticed using github.
>> IMHO comments on the github issue tracker are a form of
>> documentation and I would like to preserve them if it is possible.
>>
>>> In terms of just the branch names themselves, we've currently
>>> got "2.0-pro", "2.1-pro", "2.2-pro", I'd suggest we add "2.3".
>>> Tags all have the prefix "v." so there won't be any conflict.
>>
>> If we decide to follow [1] then branches "2.0-pro", "2.1-pro",
>> "2.2-pro" should be removed. Is it correct?
>
> No, I don't think so. Or at least, we don't have to. We're not really
> planning on committing to those branches, so perhaps it's cleaner to
> remove them. Every person who forks PyTables/PyTables will have all
> of those branches locally, so if we don't intend to do something with
> them, then we can probably chunk them. (We still have the tags, of
> course).
>
Yes.
IMHO it is not a vital aspect so we are free to decide without constraints.
>> And also, I suppose we are going to support only one version of
>> PyTables at time, Isn't it?
>
> I could imagine having to support 2.x and 3.x simultaneously.
>
This is an important point.
If my understanding is correct PyTables 3.x will support bot python 2.x
(maybe 2.6+) *and* python 3.x.
Is it correct?
In this context how much time after the release of 3.0 we are going to
support 2.x?
... only bugfix releases or also additional backports and features?
[CUT]
>>
>> 2.3.1 will be a bugfix release and IMHO we can make an RC just
>> after the merge of [#98] (still waiting an OK from you all).
>
> commented.
>
OK thanks, thate is something else that can go in 2.3.1?
[CUT]
>> Maybe it is a good idea to use two different branches: * one
>> (master or development) for all changes that do not break
>> compatibility with 2.x line and are not too py3k specific (these
>> changes can potentially go in 2.4, if it will ever be released) *
>> and one (py3k or 3.x) for changes that are specific for py3k and
>> changes that break the API or cause incompatibilities (like
>> numarray, Numeric and netcdf3 removal, etc.)
>>
>> The second one can be a temporary branch.
>>
>> Makes it sense?
>
>
> I think so, but I guess there's the question of whether or not we
> want to follow git-flow. If so, we'd setup:
>
> * master -- branched off of the v.2.3 tag * develop -- current state
> of master (3c3aede) * feature/py3k -- branches off of either of the
> other.
>
> In a more traditional setup, I guess that'd leave us with:
>
> * 2.3 -- branched off of v.2.3 * master -- would become 2.4 * 3.0 --
> or "py3k" etc.
>
> ~J.
Right now I'm +1 for git-flow
Just a note: currently master is v.2.3 + fixes for gh-111 and gh-113
that will go in 2.3.1. in any case, so, IMHO, we don't need to branch
from the v.2.3 tag in any case.
regards
- --
Antonio Valentino
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6CE9UACgkQ1JUs2CS3bP6mLQCeKA2q764gF7zq1HWGOHMND4dB
QtsAnjLpHXCXJAOiRbmXfm6fu6I2uiZt
=4TV3
-----END PGP SIGNATURE-----
Josh Moore
Np, it makes sense.
>>> IMHO comments on the github issue tracker are a form of
>>> documentation and I would like to preserve them if it is possible.
>>>
>>>> In terms of just the branch names themselves, we've currently
>>>> got "2.0-pro", "2.1-pro", "2.2-pro", I'd suggest we add "2.3".
>>>> Tags all have the prefix "v." so there won't be any conflict.
>>>
>>> If we decide to follow [1] then branches "2.0-pro", "2.1-pro",
>>> "2.2-pro" should be removed. Is it correct?
>>
>> No, I don't think so. Or at least, we don't have to. We're not really
>> planning on committing to those branches, so perhaps it's cleaner to
>> remove them. Every person who forks PyTables/PyTables will have all
>> of those branches locally, so if we don't intend to do something with
>> them, then we can probably chunk them. (We still have the tags, of
>> course).
>>
>
> Yes.
> IMHO it is not a vital aspect so we are free to decide without constraints.
>
>
>>> And also, I suppose we are going to support only one version of
>>> PyTables at time, Isn't it?
>>
>> I could imagine having to support 2.x and 3.x simultaneously.
>>
>
> This is an important point.
> If my understanding is correct PyTables 3.x will support bot python 2.x
> (maybe 2.6+) *and* python 3.x.
> Is it correct?
The difficulty of supporting, say, 2.5 and 3.x is quite high, no? I'd certainly vote for the most backwards compatibility we can get (for the moment).
> In this context how much time after the release of 3.0 we are going to
> support 2.x?
>
> ... only bugfix releases or also additional backports and features?
I guess I meant the latter. I.e. are there any largish features we want to introduce that would need to maintain 2.4/2.5 support. This obviously depends on the question of how much we can support in the 3.x line.
> [CUT]
>
>>>
>>> 2.3.1 will be a bugfix release and IMHO we can make an RC just
>>> after the merge of [#98] (still waiting an OK from you all).
>>
>> commented.
>>
>
> OK thanks, thate is something else that can go in 2.3.1?
Personally, I'd hold off. As you replied, it's more something new. No reason to introduce any unintended stability. Once we know if we are more likely to have a 2.4 or not, then it'll be easier to make these decisions. For example, if we *don't* plan on ever having a 2.4, then we'll likely want to put these patches in the 2.3 line.
> [CUT]
>
>>> Maybe it is a good idea to use two different branches: * one
>>> (master or development) for all changes that do not break
>>> compatibility with 2.x line and are not too py3k specific (these
>>> changes can potentially go in 2.4, if it will ever be released) *
>>> and one (py3k or 3.x) for changes that are specific for py3k and
>>> changes that break the API or cause incompatibilities (like
>>> numarray, Numeric and netcdf3 removal, etc.)
>>>
>>> The second one can be a temporary branch.
>>>
>>> Makes it sense?
>>
>>
>> I think so, but I guess there's the question of whether or not we
>> want to follow git-flow. If so, we'd setup:
>>
>> * master -- branched off of the v.2.3 tag * develop -- current state
>> of master (3c3aede) * feature/py3k -- branches off of either of the
>> other.
>>
>> In a more traditional setup, I guess that'd leave us with:
>>
>> * 2.3 -- branched off of v.2.3 * master -- would become 2.4 * 3.0 --
>> or "py3k" etc.
>>
>> ~J.
>
> Right now I'm +1 for git-flow
>
> Just a note: currently master is v.2.3 + fixes for gh-111 and gh-113
> that will go in 2.3.1. in any case, so, IMHO, we don't need to branch
> from the v.2.3 tag in any case.
Agreed. Then it'd just be a matter of swapping master to develop, and branching master off of v.2.3.
Anyone else have an opinion?
~J.
Antonio Valentino
Hash: SHA1
Hi Josh,
Il 28/09/2011 11:56, Josh Moore ha scritto:
[CUT]
>>> I could imagine having to support 2.x and 3.x simultaneously.
>>>
>>
>> This is an important point. If my understanding is correct PyTables
>> 3.x will support bot python 2.x (maybe 2.6+) *and* python 3.x. Is
>> it correct?
>
> The difficulty of supporting, say, 2.5 and 3.x is quite high, no? I'd
> certainly vote for the most backwards compatibility we can get (for
> the moment).
>
yes
>> In this context how much time after the release of 3.0 we are going
>> to support 2.x?
>>
>> ... only bugfix releases or also additional backports and
>> features?
>
> I guess I meant the latter. I.e. are there any largish features we
> want to introduce that would need to maintain 2.4/2.5 support. This
> obviously depends on the question of how much we can support in the
> 3.x line.
>
Mmm, the senario that I figured out was a little bit simpler:
* only one version supported at time
* drom python 2.4 and 2.5 wthout too much problems
Are there known projects using pytables that are non cmpatible witn
python > 2.5?
>> [CUT]
>>
>>>>
>>>> 2.3.1 will be a bugfix release and IMHO we can make an RC just
>>>> after the merge of [#98] (still waiting an OK from you all).
>>>
>>> commented.
>>>
>>
>> OK thanks, thate is something else that can go in 2.3.1?
>
> Personally, I'd hold off. As you replied, it's more something new. No
> reason to introduce any unintended stability. Once we know if we are
> more likely to have a 2.4 or not, then it'll be easier to make these
> decisions. For example, if we *don't* plan on ever having a 2.4, then
> we'll likely want to put these patches in the 2.3 line.
Well, IMHO we should make a 2.4 only if 3.0 takes to long to be
completed (which is not so improbable).
After all, is seems to me that there are not too much big features
planned at the moment, apart py3k support.
[CUT]
>>> I think so, but I guess there's the question of whether or not
>>> we want to follow git-flow. If so, we'd setup:
>>>
>>> * master -- branched off of the v.2.3 tag * develop -- current
>>> state of master (3c3aede) * feature/py3k -- branches off of
>>> either of the other.
>>>
>>> In a more traditional setup, I guess that'd leave us with:
>>>
>>> * 2.3 -- branched off of v.2.3 * master -- would become 2.4 * 3.0
>>> -- or "py3k" etc.
>>>
>>> ~J.
>>
>> Right now I'm +1 for git-flow
>>
>> Just a note: currently master is v.2.3 + fixes for gh-111 and
>> gh-113 that will go in 2.3.1. in any case, so, IMHO, we don't need
>> to branch from the v.2.3 tag in any case.
>
> Agreed. Then it'd just be a matter of swapping master to develop, and
> branching master off of v.2.3.
>
> Anyone else have an opinion?
>
> ~J.
>
>
- --
Antonio Valentino
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6DaHsACgkQ1JUs2CS3bP48cwCeInSkgoVC2O2+bOebie0yVayV
cC0AoIXs3HIlPMMKfnlAEAordEPSzXQ8
=HVrT
-----END PGP SIGNATURE-----
Antonio Valentino
Il giorno Wed, 28 Sep 2011 23:18:09 +0200
Josh Moore <josh....@gmx.de> ha scritto:
>
Ops :)
Sorry
--
Antonio Valentino
Antonio Valentino
Hash: SHA1
Hi Josh,
Josh, it was very ingenuous from my part to think that none of the
PyTables projects needs to support Python versions older than 2.6.
And it would be paradoxical that a project drops a feature that one of
the project developers itself needs.
Also I think that we have still some time before making a final
decision since we still should:
* make a decision about the repo policy (blocker)
* release PyTables 2.3.1 (RC and final)
* start pushing a certain amount of changes that are can be safely
included in both the 2.x and 3.x line
* depending on how long it takes, decide if we want to release a 2.4
version or not
... so IMO the final decision about how long to support older version
of python can be delayed to the moment in which we will have a more
clear idea of what PyTables 3.0 will be.
What do you think about it?
Now I think it is time to make a call for vote for the repo policy.
We could use the users' mailing list to have more feedback from users
even if, probably, only developers (the ones with commit access)
should vote a thing like this.
In alternative we can use the dev mailing list or IRC if it do not
takes to long to organize it.
If you are not too busy, please could you coordinate the thing?
ciao
- --
Antonio Valentino
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6GvBsACgkQ1JUs2CS3bP4mHgCbBjuaetGYDJEcrLWNKHrWgcIe
FiEAn3F7hyCIiMRYRRGu3kkYevxz7Ycj
=Smlv
-----END PGP SIGNATURE-----
Josh Moore
:) No worries. I need to organize some discussion on our side to see how long we want or need to support 2.4 and 2.5.
> Also I think that we have still some time before making a final
> decision since we still should:
>
> * make a decision about the repo policy (blocker)
> * release PyTables 2.3.1 (RC and final)
> * start pushing a certain amount of changes that are can be safely
> included in both the 2.x and 3.x line
> * depending on how long it takes, decide if we want to release a 2.4
> version or not
>
> ... so IMO the final decision about how long to support older version
> of python can be delayed to the moment in which we will have a more
> clear idea of what PyTables 3.0 will be.
>
> What do you think about it?
Sounds sensible. Perhaps add to the list asking the community for needed versions. If OME is the only project, it'd similarly be ingenuous to expect everything to wait on it.
> Now I think it is time to make a call for vote for the repo policy.
> We could use the users' mailing list to have more feedback from users
> even if, probably, only developers (the ones with commit access)
> should vote a thing like this.
I think keeping everyone abreast is a good idea. I'll draft an email asking for feedback tomorrow.
> In alternative we can use the dev mailing list or IRC if it do not
> takes to long to organize it.
>
> If you are not too busy, please could you coordinate the thing?
In general, I'm not too busy, and will start kicking things off. I've just recently been traveling and will be away the latter part of this week, as well.
> ciao
> Antonio Valentino
Cheers,
~Josh.