c4c-dev team mailing list archive

[Eric Bradshaw <ericbradshaw@xxxxxxxxxxxxxxxxxxxxxxxx>]

Guys,

An interesting direction, or several. While this seems to be a better
way to integrate and disseminate C4C moving forward, let me speak with
Tim and Grant off-list a bit...

Eric

On 05/21/2015 07:29 AM, Israel wrote:
> Hi,
> sorry I have been very busy here...
> I think we should use the normal workflow.
> Main stable branch.
> unstable branches for testing.
> The stable branch should be modified only when the unstable branch (or
> branches for testing) does what we intend.
>
> I think only 1 main developer should work on the packaging, with others
> contributing.  This way, there can be an 'authority' on the package. 
> And my vote is Greg, since he has come up with the simple and effective
> way to bring in all the media and install them in a way that complies
> very effectively with Eric's agreement with the owners of the content.
>
> The main tasks, would seem to be:
> 1. hosting all the media on a c4c server.
> 2. giving Greg access to that server to complete his authentication goal.
> 3. creating the keys, and scripts to get/check/etc.. the keys
> 4. creating a meta package to bring in all the programs we want
> 5. creating smaller packages for the meta to depend on (music, pictures,
> etc..)
>
> On 05/20/2015 11:22 PM, Eric Bradshaw wrote:
>> Guys,
>>
>> It is my unlearned opinion that *Centralized* workflow be used.
>>
>> Eric
>>
>> On 05/17/2015 11:48 AM, KI7MT wrote:
>>> Hello All,
>>>
>>> I'm was branching (checking out) the source code for the current c4c-dev
>>> branch and soon realized there are a *ton* of binary files in the
>>> repository.
>>>
>>> Branch: https://code.launchpad.net/~israeldahl/c4c-desktop/trunk
>>>
>>> It makes little sense to have binaries in a VCS (version control system)
>>> as they cannot be version controlled by their content (thus defeating
>>> the purpose of VCS), only by file name can they be re-visioned.
>>>
>>> Is there a reason why we're adding all these files?
>>>
>>> Additionally, we need a blueprint to flush this out, what is the
>>> proposed workflow for the project:
>>>
>>> * Centralised
>>> * Centralised with local commits
>>> * Decentralised with shared main line
>>> * Other ?
>>>
>>> More information on workflows can be found at the link below, but,
>>> before we can push forward, we need to determine what workflow we want
>>> to use:
>>>
>>> http://wiki.bazaar.canonical.com/Workflows
>>>
>>> This is a show stopper for us all until resolved.
>>>
>>> best regards,
>>>
>>> Greg.
>>>
>