c4c-dev team mailing list archive

[KI7MT <ki7mt@xxxxxxxxx>]

Hello All,

I forgot to comment on the Packaging aspect here.

With a centralized workflow, all of us ( the admins ) will be able to
commit to the main line, as it should be. If the team grows, we can add
more folks to c4c-dev team and create a separate teams for those that
have Commit privileges; like C4C-Admin, or C4C-Comitters or whatever you
deem appropriate. This would force the use of Merge Proposals by those
that do no have commit access, and the Admins would approve the merge,
thus creating a centralized workflow + Gatekeper sort of setup. Except
in this case, the Gatekeeper is a Team rather than one individual.

As for packaging, I don't think one person should own / control all the
packages. Everyone needs to learn packaging, and the best way to do that
is to create and maintain the packages themselves. They don't have to be
complicated. It can be a simple menu package or something. There should
be package owners for sure but they should not own all of the packages
themselves.

All of us should be able to work on all the packages. We may not be the
subject matter expert for a particular package, or even understand the
language used to develop it, but the packaging files / elements itself
should be understood by all as they are plain text files, written to a
Very well documented Debian standard.

To accommodate the "One Person" model, you create / assign what is
called the Release Manager, or in our case, Series Release Manager. This
can and should shift to different folks within the Team with each series.

For instance
* 14.04 Series, maybe that is Eric
* 16.04 Series, maybe that is Myself, Israel, Tim, Grant

You can further break this down into the sub-release updates, the
14.04.3 and 14.04.4 updates, etc. After the Series release, the Series
Release Manager becomes the Maintenance Manager for that series. More
often than not, there's nothing to do unless out packages need updating,
but it should be tracked and managed by someone.

The release manager (project manager) sets the goals and priorities for
that series release and works with the team to accomplish them ;  Drive
the Action Items lists (W3 ??) , tracking Milestones, manage Blueprints
etc.

That's my thoughts on packaging and series management.


Any additional thoughts ???


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