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. 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.
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.
-Seb
_______________________________________________
opensolaris-arc mailing list
[email protected]
