On 04/21/10 02:40 PM, Sebastien Roy wrote:
On 04/21/10 03:07 PM, Norm Jacobs wrote:
On 04/21/10 12:37 PM, Sebastien Roy wrote:
On 04/21/10 01:19 PM, Bart Smaalders wrote:
It seems that someone actually needs to own and maintain contrib
for this plan to go forward; right now contrib is not well
maintained, and maintainers are not responsive to bugs.
Indeed. This case is obviously not unique; there are a significant
number of cases coming through the process with the shared goal of
vacating the SFW consolidation of software that the project team has
identified as being better suited for the /contrib repository. Perhaps
it would be productive to have a discussion about this greater goal
and the type of infrastructure that is needed to accomplish it. An
umbrella case would be a good medium to have such a discussion.
-Seb
While I agree that the /contrib repository is in need of some care and
feeding, it doesn't contain software that is part of the Solaris
architecture. As a result, this isn't really the right forum for a
discussion of /contrib.
Call me confused, but the project team initially brought it up by
including this in the case materials:
2. Technical Issues
2.1. Availability through OpenSolaris /contrib repository
The OpenSolaris /contrib repository [1] is a more appropriate
mechanism for delivering Areca Backup to interested consumers.
A separate and independent project will provide Areca Backup
availability through the OpenSolaris /contrib repository.
I think there is perhaps general confusion about the relationship
between the /contrib repository and the product.
Yes, they did bring up the /contrib repository and they do intend on
making it available there, but the reality is that /contrib doesn't
contain pieces of Solaris architecture and should not. /contrib is not
part of the product and you can't layer anything that is part of the
product on it. From an architectural standpoint, it doesn't exist.
Now, from a more practical standpoint, it is a place where people can
build and deliver software not in the product, but may be useful as an
add-on to the product.
Regardless of the /contrib issue, there seems to be some overarching
driver for these cases, and I'm suggesting that communicating the
overall goal and plan to accomplish it separate would save every
individual case from having the same kind of discussion, and would
give greater context to these cases.
The goal of this case and similar cases is to remove software from the
Solaris WOS that should not have been integrated into the WOS in the
first place. If you disagree and believe that the software fits a
significant architectural need, then you should say so, so that we might
better apply the resources available.
You should be looking at each of these cases on the merit of it's
architectural significance to Solaris. The intention of this case and
similiar cases is to remove interfaces from the Solaris architecture
that don't address a specific architectural need or where it might make
sense to address a user requirement outside of the Solaris architecture.
The fact that they are being added to /contrib should have little or no
bearing on any recommendation you make.
Perhaps that's true, but my general point is that this is something
that could have been discussed in an umbrella case in order to
facilitate the formulation and review of each of these piece-meal
removal cases.
There may be an umbrella case to be had, though it's likely to involve
more than just an architectural discussion.
-Norm
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
