c4c-dev team mailing list archive

[KI7MT <ki7mt@xxxxxxxxx>]

Hi Eric,

Nothing has to be done or changed in a rush. IMHO, its much better to
have a well thought out plan in place before making any code shifts,
thus the reason I try to prompt discussion.

I had good laugh about this one "new-fangled ideas you kids have" ... I
would venture to guess, I am probably the oldest one in the group, by
far :)

One last thing to prevent any confusion. When I refer to Ubuntu, that
generally means all the various flavors Xub, Lub, Kub, etc etc, not just
Ubuntu Unity. If it's something specific to one of them only, I'll
normally state the full name of the distro e.g. Xubuntu ot Lubuntu.

As for older HW support, I think that is a must have. In the past, that
generally limited distro choices to Lubuntu / Xubuntu, but that is
changing and fairly quickly.

>From my perspective, while as fun as this all can be, we must not loose
sight of the end goal, which is providing Christian content to as many
users as we can, or if available, entire system + content.


best regards,

Greg





On 05/21/2015 10:21 PM, Eric Bradshaw wrote:
> Guys,
> 
> I'll say what I know below.
> 
> On 05/21/2015 12:43 PM, KI7MT wrote:
>> 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.
> I would think focusing only on LTS releases would be the best way to
> keep an easy/ier to deal with schedule and for support. We dropped
> "vanilla" Ubuntu initially because it became to resource intensive for
> anything but fairly new hardware. And 6 year old machines had been the
> newest that was ever donated to us. But, there seems to be a nice
> (growing?) selection of "light" distros that under the model being
> propsed we could respin or infuse with C4C stuff. Lubuntu, LXLE, MATE -
> maybe even Peppermint or Xubuntu? and, maybe C4C "respins" don't have to
> be limited to light distros at all. My hope that others will want to
> start and run C4C Chapters based on the model we have in Cheyenne may be
> limiting in and of itself.
>> 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 ?
>>
> We have very, very recently moved to BlueHost - and that's Tim's domain.
> I'm going to try to speak with both Tim and Grant off-list about these
> new-fangled ideas you kids have :)
> 
> Eric
>> 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.
>>>>>
>>>
> 
>