c4c-dev team mailing list archive

[KI7MT <ki7mt@xxxxxxxxx>]

HI Israel,

I'm still looking at the branching aspect with respect to series goals.

I think, for our purposes, if were going to follow the LTS model, this
should be fairly simple, something like:

The main release / trunk + series
lp:c4c-destop/14.04.3 --> 14.04.4 and so on.

This assumes the first new release is in August when 14.04.3 is released
by Ubuntu.

The dev-branch could be whatever we want it to be
c4c-desktop-dev/16.04 / 15.10

Then when 16.04 is released, that becomes the new focus, and the 14.04
series moves to maintenance only, something like that.

As for the main tasks, I would definitely need access to the server for
development. For future reference, what sort of server it is, private,
hosted, Linux / Windows? Do you have root / sudo or super user access to
it via SSH ?


best regards,

Greg

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.
>>>
>>
> 
>