reviewing PCL in preparation for 1.0

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

reviewing PCL in preparation for 1.0

Radu B. Rusu
Administrator
In preparation for a "base" PCL 1.0, with a target goal set for D-Turtle, we should involve ourselves in a review process.

My plan is to collect information from all, regarding:

* what should we review: PCL, PCL_ROS, both?

* do we look at the ROS API only or should we touch documentation and maybe the C++ API?


The review process is necessary in order to understand what our needs are for something "stable" that we can guarantee
that we won't change for some time after its release. Think about it as a discussion on how the interfaces should look
like, what needs to go in that's not already in, etc. Basically if you want to write software that is based on PCL, we
need to know what your needs are, so that we don't break that software with newer releases of PCL.


Once we collect this information (so simply answer to the two bullet points above), I'll set up wiki pages for each
package that we will review, and invite you all to participate.

For completeness, see:

* http://www.ros.org/wiki/Get%20Involved (section 7. Participating in Software Reviews)
* http://www.ros.org/wiki/QAProcess

--
Cheers,
Radu.

_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: reviewing PCL in preparation for 1.0

Geoffrey Biggs
I think that if you want to be in D-Turtle, you need to review both PCL
and PCL_ROS. Everything should be reviewed before a 1.0 release.

Geoff

On 12/10/10 07:25, Radu Bogdan Rusu wrote:

> In preparation for a "base" PCL 1.0, with a target goal set for D-Turtle, we should involve ourselves in a review process.
>
> My plan is to collect information from all, regarding:
>
> * what should we review: PCL, PCL_ROS, both?
>
> * do we look at the ROS API only or should we touch documentation and maybe the C++ API?
>
>
> The review process is necessary in order to understand what our needs are for something "stable" that we can guarantee
> that we won't change for some time after its release. Think about it as a discussion on how the interfaces should look
> like, what needs to go in that's not already in, etc. Basically if you want to write software that is based on PCL, we
> need to know what your needs are, so that we don't break that software with newer releases of PCL.
>
>
> Once we collect this information (so simply answer to the two bullet points above), I'll set up wiki pages for each
> package that we will review, and invite you all to participate.
>
> For completeness, see:
>
> * http://www.ros.org/wiki/Get%20Involved (section 7. Participating in Software Reviews)
> * http://www.ros.org/wiki/QAProcess
>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: reviewing PCL in preparation for 1.0

Radu B. Rusu
Administrator
Whoops forgot to send this too: http://www.ros.org/wiki/StackVersionPolicy

Geoff, you're right, but we can also just do a:

* "perception_pcl" stack that contains some form of a "stable" 1.0, usable 3D library, and

* keep "point_cloud_perception" for things which will be 0.4-0.9 but are still not definitive, as we're trying to find
solutions for them.

I'd rather wait some more and iterate with the PCL developers/users, than hurry up and do something just to mark it at
"1.0" and then discover later that it was wrong and it suddenly became a maintenance nightmare. :)

The question is what is more important right now? The ROS API (PCL_ROS) or the C++ API (PCL)?


Cheers,
Radu.


On 10/11/2010 06:39 PM, Geoffrey Biggs wrote:

> I think that if you want to be in D-Turtle, you need to review both PCL
> and PCL_ROS. Everything should be reviewed before a 1.0 release.
>
> Geoff
>
> On 12/10/10 07:25, Radu Bogdan Rusu wrote:
>> In preparation for a "base" PCL 1.0, with a target goal set for D-Turtle, we should involve ourselves in a review process.
>>
>> My plan is to collect information from all, regarding:
>>
>> * what should we review: PCL, PCL_ROS, both?
>>
>> * do we look at the ROS API only or should we touch documentation and maybe the C++ API?
>>
>>
>> The review process is necessary in order to understand what our needs are for something "stable" that we can guarantee
>> that we won't change for some time after its release. Think about it as a discussion on how the interfaces should look
>> like, what needs to go in that's not already in, etc. Basically if you want to write software that is based on PCL, we
>> need to know what your needs are, so that we don't break that software with newer releases of PCL.
>>
>>
>> Once we collect this information (so simply answer to the two bullet points above), I'll set up wiki pages for each
>> package that we will review, and invite you all to participate.
>>
>> For completeness, see:
>>
>> * http://www.ros.org/wiki/Get%20Involved (section 7. Participating in Software Reviews)
>> * http://www.ros.org/wiki/QAProcess
>>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: reviewing PCL in preparation for 1.0

Geoffrey Biggs
On 12/10/10 14:14, Radu Bogdan Rusu wrote:

> Whoops forgot to send this too: http://www.ros.org/wiki/StackVersionPolicy
>
> Geoff, you're right, but we can also just do a:
>
> * "perception_pcl" stack that contains some form of a "stable" 1.0,
> usable 3D library, and
>
> * keep "point_cloud_perception" for things which will be 0.4-0.9 but are
> still not definitive, as we're trying to find solutions for them.
>
> I'd rather wait some more and iterate with the PCL developers/users,
> than hurry up and do something just to mark it at "1.0" and then
> discover later that it was wrong and it suddenly became a maintenance
> nightmare. :)
>
> The question is what is more important right now? The ROS API (PCL_ROS)
> or the C++ API (PCL)?

The C++ API will drive the ROS API, so I think that it's more important
to get the C++ one stabalised, reviewed, and a 1.0 release out. Then you
can work on reviewing the ROS API and get it stable for whatever the
next ROS release at that time is.

As you say, rushing is bad. I think an important question that you need
to ask is, do you *really* need a 1.0 API in the next ROS release? What
benefit does that give that you would miss by waiting for the next ROS
release in another 6 months?

Geoff
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: reviewing PCL in preparation for 1.0

Radu B. Rusu
Administrator

On 10/11/2010 10:27 PM, Geoffrey Biggs wrote:
> On 12/10/10 14:14, Radu Bogdan Rusu wrote:
>> The question is what is more important right now? The ROS API (PCL_ROS)
>> or the C++ API (PCL)?
>
> The C++ API will drive the ROS API, so I think that it's more important
> to get the C++ one stabalised, reviewed, and a 1.0 release out. Then you
> can work on reviewing the ROS API and get it stable for whatever the
> next ROS release at that time is.

Good point. Most stuff in ROS however gets reviewed first at the ROS level (e.g., are the messages "stable" / going to
stay the same, etc) and only later the internal C++ API gets reviewed (if ever). However, our goal is to get PCL used
outside of ROS too, so I agree that we should look at the C++ API more.

> As you say, rushing is bad. I think an important question that you need
> to ask is, do you *really* need a 1.0 API in the next ROS release? What
> benefit does that give that you would miss by waiting for the next ROS
> release in another 6 months?

Personally I don't care if we call it 1.0 (though the ROS versioning policy does indicate that "stable" should be called
something like that) or 0.x. :) I think what's important for us right now is to go over whatever it is that we need to
go over, and make sure that a big as possible chunk of it will not be changed in the next few months, so that people can
already start building solutions for their problems, based on PCL.


What about documentation?

Cheers,
Radu.
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: reviewing PCL in preparation for 1.0

Geoffrey Biggs
On 12/10/10 14:43, Radu Bogdan Rusu wrote:

>
> On 10/11/2010 10:27 PM, Geoffrey Biggs wrote:
>> On 12/10/10 14:14, Radu Bogdan Rusu wrote:
>>> The question is what is more important right now? The ROS API (PCL_ROS)
>>> or the C++ API (PCL)?
>>
>> The C++ API will drive the ROS API, so I think that it's more important
>> to get the C++ one stabalised, reviewed, and a 1.0 release out. Then you
>> can work on reviewing the ROS API and get it stable for whatever the
>> next ROS release at that time is.
>
> Good point. Most stuff in ROS however gets reviewed first at the ROS
> level (e.g., are the messages "stable" / going to stay the same, etc)
> and only later the internal C++ API gets reviewed (if ever). However,
> our goal is to get PCL used outside of ROS too, so I agree that we
> should look at the C++ API more.

I agree, too.

>> As you say, rushing is bad. I think an important question that you need
>> to ask is, do you *really* need a 1.0 API in the next ROS release? What
>> benefit does that give that you would miss by waiting for the next ROS
>> release in another 6 months?
>
> Personally I don't care if we call it 1.0 (though the ROS versioning
> policy does indicate that "stable" should be called something like that)
> or 0.x. :) I think what's important for us right now is to go over
> whatever it is that we need to go over, and make sure that a big as
> possible chunk of it will not be changed in the next few months, so that
> people can already start building solutions for their problems, based on
> PCL.

That's a good point. In that case, a review of the C++ PCL library (with
all related documentation) is in order. It will also indicate where
things are lacking, helping drive the improvements towards the first
stable release.

Geoff
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: reviewing PCL in preparation for 1.0

Brian Gerkey
In reply to this post by Radu B. Rusu
On Mon, Oct 11, 2010 at 10:43 PM, Radu Bogdan Rusu
<[hidden email]> wrote:

> On 10/11/2010 10:27 PM, Geoffrey Biggs wrote:
>> As you say, rushing is bad. I think an important question that you need
>> to ask is, do you *really* need a 1.0 API in the next ROS release? What
>> benefit does that give that you would miss by waiting for the next ROS
>> release in another 6 months?
>
> Personally I don't care if we call it 1.0 (though the ROS versioning policy does indicate that "stable" should be called
> something like that) or 0.x. :) I think what's important for us right now is to go over whatever it is that we need to
> go over, and make sure that a big as possible chunk of it will not be changed in the next few months, so that people can
> already start building solutions for their problems, based on PCL.

My two cents: the reason to shoot for 1.0 is that being <1.0 is a
barrier to entry for using PCL in anything that's >=1.0.  To take a
specific example, navigation could benefit from using PCL to do things
like ground-plane extraction, and in fact there's some experimental
code in a branch somewhere that does that.  But it won't be released
in navigation, a stable stack, until PCL is also stable.  I suspect
that there are many other stacks (and perhaps non-ROS projects) that
would make use of a stable, >=1.0 version of PCL.  Of course, there
are ways around this issue, such as releasing a
navigation_experimental stack at some lower version, and putting the
ground-plane stuff in there.  But creating foo_experimental for every
foo that would benefit from using PCL is a maintenance headache.

We're already seeing PCL creep in as a dependency in a lot of our work
(pretty much everything that Radu touches :).  This is good, because
PCL is powerful and useful.  But it's bad, because we incur a
dependency on an immature piece of code, which might change
substantially in the near future.  I understand the desire to get more
people using and testing PCL, but you can't have it both ways forever:
if people start using PCL (as you encourage them to), they'll come to
depend on it, and then they'll be stuck if they want to call their own
code "stable."

I agree with Radu's suggestion of identifying a appropriate chunk of
the code, coming to agreement on its API, and calling it stable.  That
can be version 1.0.  Development of 1.1 can start the next day; the
important thing is to establish a fixed feature set that everyone can
start using and depending on.  And, btw, after this happens, you
should really encourage people to use 1.0.x, *not* pull the latest,
greatest thing from trunk, no matter how much better it is.

I realize that my position on this issue puts a burden on the PCL
developers.  But you're a victim of your own success; PCL is just so
damn useful, we need a version of it that's stable, well-documented,
and usable by non-3d-perception-researchers.  As one of those people,
I'm happy to live without the latest and greatest.

        brian.
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users