Hi Chris,

The read access control work in 2.0 is project area scoped but for components you'll still be able to mix and match. What you'll have to do, is have a project area for each of the components that needs isolation, ensure that the "build" users are on each project. Even though components may be private, the "uber/build" who has read access to all projects will be able to create a stream in one of them and add all 3 components to it. The other team members will have visibility on their respective components.

But, this still brings up interesting questions. What happens if there are components in the stream that a developer can't see? They won't be able to accept change sets, so why is it in the stream to begin with? What we were thinking for selfhosting is to have the private code in a special stream which developers don't see and during the build process, we pull from these other streams and integration and build. The developers just need access to the stream that contain the components they have read access to.

So, yes, we are working to enable these use cases in 2.0 with project level read access and we have a bit more work to figure out the "best practices" for stream configuration based on this. Please stay tuned and download the M3 milestone in 8 weeks with most of this implemented and give it a spin.

Cheers,
Jean-Michel

Hmm,

It feels like this runs counter to our goals when it comes to the project management side of things. From what we've been reading and testing, project management for a project like this would involve a single project area, where overall work item tracking and iteration planning for the `Calculator' project is tracked centrally.

I'm wondering what sorts of restrictions breaking up the source code into separate project areas would have on the way we manage our high level planning.

For some perspective, we have tried using multiple project areas to track individual component's progress, but were unable to find ways to do some things like transfer work items across project areas, or get a single high level view of the entire project.

Any insights on this problem, when we also consider the project management side of things?

- chris

Hi Chris,

The read access control work in 2.0 is project area scoped but for components you'll still be able to mix and match. What you'll have to do, is have a project area for each of the components that needs isolation, ensure that the "build" users are on each project. Even though components may be private, the "uber/build" who has read access to all projects will be able to create a stream in one of them and add all 3 components to it. The other team members will have visibility on their respective components.

But, this still brings up interesting questions. What happens if there are components in the stream that a developer can't see? They won't be able to accept change sets, so why is it in the stream to begin with? What we were thinking for selfhosting is to have the private code in a special stream which developers don't see and during the build process, we pull from these other streams and integration and build. The developers just need access to the stream that contain the components they have read access to.

So, yes, we are working to enable these use cases in 2.0 with project level read access and we have a bit more work to figure out the "best practices" for stream configuration based on this. Please stay tuned and download the M3 milestone in 8 weeks with most of this implemented and give it a spin.

Cheers,
Jean-Michel

Hi Chris,

Here's the way I think about it:

For inherently inter-project shared objects like components, the
"project area" that controls access to the component is really a
"process area", i.e. the place where the process controls for reading
and writing the component are defined. So don't try to overload a
component process area with workitems etc, unless it really makes sense
to do so.

Cheers,
Geoff


cntaylor wrote:

Hmm,

It feels like this runs counter to our goals when it comes to the
project management side of things. From what we've been reading and
testing, project management for a project like this would involve a
single project area, where overall work item tracking and iteration
planning for the `Calculator' project is tracked centrally.

I'm wondering what sorts of restrictions breaking up the source code
into separate project areas would have on the way we manage our high
level planning.

For some perspective, we have tried using multiple project areas to
track individual component's progress, but were unable to find ways
to do some things like transfer work items across project areas, or
get a single high level view of the entire project.

Any insights on this problem, when we also consider the project
management side of things?

- chris

Hi Chris,

The read access control work in 2.0 is project area scoped but for
components you'll still be able to mix and match. What you'll have to
do, is have a project area for each of the components that needs
isolation, ensure that the "build" users are on each
project. Even though components may be private, the
"uber/build" who has read access to all projects will be
able to create a stream in one of them and add all 3 components to
it. The other team members will have visibility on their respective
components.

But, this still brings up interesting questions. What happens if there
are components in the stream that a developer can't see? They won't be
able to accept change sets, so why is it in the stream to begin with?
What we were thinking for selfhosting is to have the private code in
a special stream which developers don't see and during the build
process, we pull from these other streams and integration and build.
The developers just need access to the stream that contain the
components they have read access to.

So, yes, we are working to enable these use cases in 2.0 with project
level read access and we have a bit more work to figure out the
"best practices" for stream configuration based on this.
Please stay tuned and download the M3 milestone in 8 weeks with most
of this implemented and give it a spin.

Cheers,
Jean-Michel

I'm experimenting with M3D1 but haven't determined the correct mix of projects/teams I'd use to restrict access to source without handicapping project management and testing activities. I could be missing something - the lack of documentation, technotes, or otherwise is making this difficult (not to mention my lack of RTC experience). I'm looking forward to some "Best Practices" on the topic.

I can see how separate projects allow us to compartmentalize our sources, but it does the same thing with project management and testing activities (planning, work items, reports, etc).

On the other hand, if we do all project management in the top level project (calculator) and use the component projects (backend, parser, expression evaluator) for SCM only, we lose the linkage with the development work being done in the component projects.

Do I have that right?

Are there more enhancements in M3 (not in M3D1) that will make this easier (or more obvious)?

I'd suggest the following:

First define a project area for each distinct parallel release
"timeline". So if one set of teams have 6 iterations this year, while
another set of teams just have 4 (or have 6 iterations with different
dates as the first team), then create a separate project area for the
second set of teams.

Then, for a given project area, if not everyone in that project area
should have read access to all the workitems assigned to that project
area, you will need to further sub-divide that project area into
separate project areas (so they can be protected separately).

Now take a look at each of your SCM components. If for a given SCM
component, there is a project area that happens to have the right set of
people in it, then you can just make that project area be the owner of
that component. If not, then you have to create a new project area,
give it the right membership, and then assign the SCM component to that
new project area. These SCM component project areas won't have work
items or plans in them ... they are just defined to allow you to control
read access to SCM components.

If you follow those steps, and get stuck, please let me know (:-).

Cheers,
Geoff

eanderso wrote:

I'm experimenting with M3D1 but haven't determined the correct mix of
projects/teams I'd use to restrict access to source without
handicapping project management and testing activities. I could be
missing something - the lack of documentation, technotes, or
otherwise is making this difficult (not to mention my lack of RTC
experience). I'm looking forward to some "Best Practices"
on the topic.

I can see how separate projects allow us to compartmentalize our
sources, but it does the same thing with project management and
testing activities (planning, work items, reports, etc).

On the other hand, if we do all project management in the top level
project (calculator) and use the component projects (backend, parser,
expression evaluator) for SCM only, we lose the linkage with the
development work being done in the component projects.

Do I have that right?

Are there more enhancements in M3 (not in M3D1) that will make this
easier (or more obvious)?

I think I'm starting to see how this could be used (especially the bit about "These SCM component project areas won't have work items or plans in them ... they are just defined to allow you to control read access to SCM components."). I was getting hung up thinking we'd be working in all the projects when in fact we would work in a single project using components from a mix of projects.

I'll give it a shot.

Thanks

eanderso wrote:

I think I'm starting to see how this could be used (especially the bit
about "These SCM component project areas won't have work items or
plans in them ... they are just defined to allow you to control read
access to SCM components."). I was getting hung up thinking
we'd be working in all the projects when in fact we would work in a
single project using components from a mix of projects.

I'll give it a shot.

Thanks

We recognize the need for more flexible grouping. We will likely

provide that in a future release.

JohnC
SCM Server