Dave Miner wrote:

>>> What if I just want to create custom branding to use on my own 
>>> desktop?  From that perspective it doesn't seem to fit into DC at all.
>>>
>>
>> Sure that's different. That's not the point.
>>
> 
> It's entirely the point.  There are multiple needs to do essentially the 
> same thing.
> 
>> Suppose I want to construct my own distribution of OpenSolaris
>> as a delivery vehicle for my FOO software (which doesn't use
>> Solaris packaging). Does it really make sense to have me go off and
>> have to learn Solaris packaging, or should DC just make it
>> easy to do that?
>>
> 
> I don't believe I said anything about requiring such a hypothetical 
> developer to know anything about packaging.  Having a tool which hides 
> that is fine if there's a constituency which it would serve.
> 
>> I understand your concern about scope creep, but so far, 100% of
>> the people I've talked with about this have IMMEDIATELY asked
>> about rebranding or placing stuff on the desktop. I think it's
>> a legit need for this audience.
>>
> 
> It's not a matter of scope creep, but ensuring that the right people own 
> solving a problem.  The distro constructor shouldn't, IMHO, know 
> anything about the mechanics of branding a desktop, nor should the 
> functionality to do so be specific to it.  APOC, for example, provides 
> some of this sort of thing in a run-time context for enterprise 
> environments.  Does it already have a tool for generating such things? 
> If not, should it?  Understanding the answers to those sorts of 
> questions seems important context to this discussion.

Are we creating an ISO constructor, or a Distro constructor? If the
former, I agree with your more restrictive view. If the latter,
though, I think that we should attempt to meet the big picture
needs of the community. That doesn't mean that we have to write
all the code, but provide access to the tools needed.



> 
> Are there other things from those discussions that would be relevant to 
> capture (if we can't get them to engage here directly, which would be 
> much preferred)?  I'd like more understanding of the problems they're 
> wanting to solve, rather than just feature requests without context.

Problem 1) Wanting to provide a custom distro to be a 
delivery/distribution vehicle for an open storage software
solution.
Problem 2) Wanting to provide a vehicle for a firmware updater
that needs to run separate from an installed OS instance
Problem 3) Wanting to provide a custom distro with new
branding.

I've encouraged all of them to participate here, but the needs
are pretty straightforward, in these cases.

Reply via email to