Hi Gaspard,
> 1. tests are not easy to read
Ack.
> 2. they cannot serve as "examples"
The test cases often tend to be pretty convoluted. Thus using them as
example is not always a good idea.
However, taking examples from the guide and turning them into tests
could be nice.
> 3. setup/assert
On Wed, Feb 16, 2011 at 10:41 AM, Martin Sustrik wrote:
> On 02/16/2011 07:05 PM, Brian Granger wrote:
>
> Linux kernel uses "merge windows" to address both aspects of the
> problem. Same with FreeBSD (check Vick Khera's note in this thread).
>
> The idea is to make a release, then merge all the o
On Wed, Feb 16, 2011 at 5:24 PM, Vick Khera wrote:
> I really like the FreeBSD model. They use subversion, and I'm most
> familiar with it, so forgive me if I use svn terminology. The
> PostgreSQL project works similarly and they just switched to git, but
> I am not that familiar with how they d
Concerning tests, I find the current testing framework in zmq too trivial
and not useful:
1. tests are not easy to read
2. they cannot serve as "examples"
3. setup/assert/teardown are not clearly highlighted
4. It is not clear how someone should run all tests.
This means that people won't write n
On 02/16/2011 07:05 PM, Brian Granger wrote:
> I think this comes down to a fundamental question: it is more
> important to have often and stable releases (in which case, master
> should always be stable) or is it more important to get new code into
> the hands to developers as soon as it exists,
On Wed, Feb 16, 2011 at 7:05 PM, Brian Granger wrote:
> The first defense against instability should be a solid test suite,
> not simply having lots of people try it and find bugs.
Yes, but we don't have a solid test suite, nor do we have anyone
volunteering to make it. The best strategy propose
>> Because of the scale of zeromq development, I would recommend that all
>> new development go on in topic branches.
>
> There's a real conflict of interest here. Code stays on topic branches
> until it's 'ready' but without being tried by fairly large numbers of
> people it takes a long time to b
On Wed, Feb 16, 2011 at 12:44 AM, Pieter Hintjens wrote:
> On Wed, Feb 16, 2011 at 7:32 AM, Dhammika Pathirana
> wrote:
>
>>> 1. Stop using topic branches for new development, use the master for this
>> But we need a more robust testing framework.
>
> (a) if new work comes onto master earlier, i
On Wed, Feb 16, 2011 at 6:12 PM, Martin Sustrik wrote:
>> Ah excellent! Then I'm volunteering to apply those patches to a
>> stabilization branch of 2.1.1, and make sure the results work by the
>> time it's marked 'stable'.
>
> Great! Let's try that then.
OK, to recap the plan:
* create a clone
On 02/16/2011 06:06 PM, Pieter Hintjens wrote:
> On Wed, Feb 16, 2011 at 5:29 PM, Martin Sustrik wrote:
>
>> I am volunteering to pass on the patches that should be backported to the
>> stable. However, I probably won't be able to do the actual backports,
>> testing etc.
>
> Ah excellent! Then I'm
On Wed, Feb 16, 2011 at 5:29 PM, Martin Sustrik wrote:
> I am volunteering to pass on the patches that should be backported to the
> stable. However, I probably won't be able to do the actual backports,
> testing etc.
Ah excellent! Then I'm volunteering to apply those patches to a
stabilization
On 02/16/2011 05:16 PM, Pieter Hintjens wrote:
> Presumably this means you, as a developer, would be unwilling to
> submit pull requests for bugs you fix.
I am volunteering to pass on the patches that should be backported to
the stable. However, I probably won't be able to do the actual
backpor
On Wed, Feb 16, 2011 at 10:02 AM, Pieter Hintjens wrote:
> Do you have alternative proposals? Just saying "it won't work" isn't
> terribly helpful.
I really like the FreeBSD model. They use subversion, and I'm most
familiar with it, so forgive me if I use svn terminology. The
PostgreSQL project
On Wed, Feb 16, 2011 at 5:01 PM, Martin Sustrik wrote:
> I would propose just doing it.
>
> Fork the master from a convenient point in the project history. Backport any
> subsequent patches that should go into stable. Make a release. It should
> take at most couple of days.
>
> Let's see then whe
On 02/16/2011 04:02 PM, Pieter Hintjens wrote:
> Do you have alternative proposals? Just saying "it won't work" isn't
> terribly helpful.
I would propose just doing it.
Fork the master from a convenient point in the project history. Backport
any subsequent patches that should go into stable. M
On Wed, Feb 16, 2011 at 3:29 PM, Martin Sustrik wrote:
> That's not going to fly IMO.
>...
> Given that the latter requires half the work and that developers are (in
> general) lazy, I would expect everyone take that path, making stable branch
> little more than a simple tag on the master.
>
> In
On 02/16/2011 12:28 AM, Pieter Hintjens wrote:
> You've perhaps missed the 'pull request' part of the proposal. Pull
> requests apply to specific branches. The contributor of a change
> explicitly makes a patch against _each_ version branch that he wishes
> to support or fix. There is no back port
As the author of a pretty big Rails CMS (http://zenadmin.org), here are the
tools that I use to solve the grow but don't fall issue:
1. more then 2400 unit tests
2. "gold" utility
The "gold" utility works with any git account (default is github) and works
this way:
The user forks the project and
On Feb 16, 2011, at 2:28 AM, Pieter Hintjens wrote:
> On Wed, Feb 16, 2011 at 4:57 AM, Brian Granger wrote:
>
>>> 4. Use github pull requests instead of email patches
>>
>> I highly recommend going to this workflow (github pull requests). We
>> are using this for a number of other projects (i
On Wed, Feb 16, 2011 at 7:32 AM, Dhammika Pathirana wrote:
>> 1. Stop using topic branches for new development, use the master for this
> But we need a more robust testing framework.
(a) if new work comes onto master earlier, it gets tested faster and better.
(b) what suggestions do you have for
On Wed, Feb 16, 2011 at 4:57 AM, Brian Granger wrote:
> Because of the scale of zeromq development, I would recommend that all
> new development go on in topic branches.
There's a real conflict of interest here. Code stays on topic branches
until it's 'ready' but without being tried by fairly la
On 02/16/2011 07:32 AM, Dhammika Pathirana wrote:
> -1
> github pull requests are specifically for maintainers, but email
> patches get "more eyeballs" effect.
> Also github is a company, they might pull a nokia-elop(TM) move.
Agreed. Tying the project workflow to a particular commercial entity i
Hi Pieter,
>
> Proposals:
>
> 1. Stop using topic branches for new development, use the master for this
But we need a more robust testing framework.
> 2. Rename the maintenance branch to match the actual version it covers (2.0.x)
> 3. Start a new maintenance branch for 2.1.x so that patches can
Hi,
I was wondering if git flow (https://github.com/nvie/gitflow) would be of
benefit for this situation?
Cheers,
Henry
On February 15, 2011 12:09:36 pm Pieter Hintjens wrote:
> Hi all,
>
> I'd like to get feedback on a thread we had on IRC yesterday. I'll
> start by noting a number of problem
Hi,
> Proposals:
>
> 1. Stop using topic branches for new development, use the master for this
Because of the scale of zeromq development, I would recommend that all
new development go on in topic branches. When a topic branch is ready
for merging into master, open a pull request, do a review
Automated tests can alleviate some of the pain of being a maintainer. Of course
only good patches alleviate the pain of being a maintainer.
Joshua
On Feb 15, 2011, at 5:40 PM, Martin Sustrik wrote:
> Hi all,
>
> This is a good discussion to have.
>
> However, I believe the most important part
My 2 cents
>
> Proposals:
>
> 1. Stop using topic branches for new development, use the master for this
Normal development (safe features/bug fixes/etc) should be done on master. The
master should be mostly stable which means quick, tested patches. Riskier
features such as experimental cha
On Wed, Feb 16, 2011 at 12:13 AM, Martin Sustrik wrote:
> To backport the patches from master you have to understand the code.
You've perhaps missed the 'pull request' part of the proposal. Pull
requests apply to specific branches. The contributor of a change
explicitly makes a patch against _ea
Hi Pieter,
> I'm more than happy to help maintain one or more of the release
> branches if/once we've cleaned up the process so that a maintainer is
> not required per-se to know the details of every patch applied. This
> will require some refinement of the actual release process for a
> version
On Tue, Feb 15, 2011 at 10:31 PM, Michael Kogan
wrote:
> I think there should also be clear connection between the wrapper libraries
> (in my case Java) and 0MQ proper in terms of which version should be used.
> For example the current jzmq tests break when using 0MQ 2.1.0 due to the way
> con
On Tue, Feb 15, 2011 at 11:40 PM, Martin Sustrik wrote:
> However, I believe the most important part of the whole thing haven't
> been mentioned:
>
> To have a sane stable branch someone has to step forward and become the
> maintainer (upstreaming patches from stable, backporting patches from
> m
Hi all,
This is a good discussion to have.
However, I believe the most important part of the whole thing haven't
been mentioned:
To have a sane stable branch someone has to step forward and become the
maintainer (upstreaming patches from stable, backporting patches from
master etc.)
Martin
_
I think there should also be clear connection between the wrapper libraries (in
my case Java) and 0MQ proper in terms of which version should be used. For
example the current jzmq tests break when using 0MQ 2.1.0 due to the way
context is terminated.
Mike.
On Feb 15, 2011, at 11:21 AM, Pieter
On Tue, Feb 15, 2011 at 7:27 PM, Chuck Remes wrote:
>> - The master HEAD has no formality, and can't be used except by small teams
>
> I'm not sure what you mean here. I agree it has little formality but the
> "small teams" part confuses me.
It's impossible to make a formal release of any prod
>From the pyzmq side, I have encountered quite a few users who refuse to use
HEAD or 2.1.0 because they are in production situations and have policy
guidelines preventing the use of beta code. Even if the code is actually
*more* stable than 2.0.10, the simple fact that it's called 'beta' means
man
Comments are inline.
On Feb 15, 2011, at 11:09 AM, Pieter Hintjens wrote:
> Problems:
>
> 1. It is rather hard to know what version of 0MQ to use:
> - The stable release is too out of date, has numerous flaws that
> have been properly fixed in later versions
Agreed. IMO, stable 2.0.10 causes p
Hi all,
I'd like to get feedback on a thread we had on IRC yesterday. I'll
start by noting a number of problems we face today using/packaging
0MQ, and then propose some solutions.
Problems:
1. It is rather hard to know what version of 0MQ to use:
- The stable release is too out of date, has nu
37 matches
Mail list logo
