[katello-devel] Summary: Breaking up Codebase

[Eric Helms]

This is a summary of the proposal "Breaking up Codebase" originally 
started here [1] and continued here [2].  The following is broken up 
such that Section I contains the original proposal, Section II contains 
a general summary and thoughts post-discussion and lastly Section III 
provides a more in-depth summary of the conversation thus far.

Section I: Original Proposal

    Prior to using Github for source control management, the project had one logical repository available that made
    sense for keeping the various components of Katello contained within.  As the project has grown, and as our
    community efforts increase I propose we break out code base elements from our mainline repository for the
    following reasons:

    1) Reduces the overall size of the project repository.
    2) Provides smaller, logical components that users and developers can work from and on.  This makes it easier
        for the community to contribute as they can work on components that are important to them, that they are
        more comfortable working on and are smaller (a.k.a less imposing due to size).
    3) Decreases "tag-mania" on the mainline repository and lets the tags and the packages they are associated
        with live on their own.  Provides direct connection between package and repository (e.g. katello-cli.rpm is
        derived from katello-cli git repository)
    4) Some components just have no logical reason to be contained within the same repository.  (e.g. I don't need
        the CLI code to run and work on Katello)
    5) The Github Organization concept with multiple repositories makes it easy to manage multiple applications and
         pull requests associated with each.


    Components I currently see that could be stand-alone repositories:

    cli/
    agent/
    certs-tools/
    puppet/
    repos/
    src/ (a.k.a Katello)


Section II: General Summary

There is an even mix of +1 and apprehensive -1's around this topic.  The 
general feel of the points against is how it affects the ability to 
build the Katello RPMs and keep proper versions in check.  The general 
feel for points for is that it would make components more logical, mimic 
the seeming successes other projects have seen with broken out 
components with regards to community, and make viewing of component 
progress easier with regards to development.

Thoughts:

  * Broken out packages would allow each to have a more cohesive
    development focused around the package, pull requests, and tags are
    specific to the repository/package contained within.  And would
    reduce the number of PRs and potentially the time to accept sitting
    in our central Katello repository and let those focused on certain
    areas focus on the areas they want to focus on.
  * Feels natural that I should be able to checkout or install the CLI
    without having to setup a Katello server myself.
  * While Git repository currently is not large in bytes, it is large in
    layout which can be overwhelming or confusing and will only grow
    from here on out.


Questions:

  * Pardon any ignorance on how building is done here, do all packages,
    rel-eng, tags and spec files get managed centrally in the current
    layout? Or does each require its own editing, maintenance and tagging?
  * How would broken out components affect ability to build cohesive set
    of packages?
  * Does working on Katello really required knowledge about
    katello-configure?  I have never worked on katello-configure but
    manage to work on Katello everyday.  The same was true with regards
    to the CLI.
  * Does this break-up really make contribution easier?
  * Would this break-up of the codebase feel weird if it had been done
    from the start or are we just accepting the status quo?


Other Thoughts:

  * Breaking out components could allow for language-specific packaging
    install for those who prefer it. For example, allowing CLI to
    stand-alone and be installed via python-disutils or being able to
    install Katello via a gem.
  * We should consider the idea of not only breaking out logical package
    based components but potentially other areas of code (e.g. api, ui,
    backend layer, APIs down to backend services)


Section III: Summary of points for and against.

Points For:

  * Previously listed ones above
  * Since we use Github, easier to offer different repository
    permissions, easier to browse and see progress of each component
  * This is how Foreman community works and it seems it made it easier
    for people to contribute
  * OpenStack takes similar approach to proposal and works well for them
  * Layout of source tree currently, and the way each is packaged lends
    themselves to individual package per repo


Points Against:

  * Git repository is currently not large
  * Working on Katello requires knowledge of katello-configure and
    working on katello-configure requires knowledge of Katello
  * One package per git repository means managing more /rel-eng/
    directories and keeping them in sync
  * When we deliver Katello, we deliver all components
  * Does breaking it up really make it easier to contribute?
  * If we eventually build on EC2, more repositories could mean getting
    charged more for increased internet traffic
  * Feeling that it would be harder to ensure correct version in all
    repositories


General Notes:

  * Delay until current build setup is stable
  * Break out each component one-by-one instead of "big bang" approach
  * Could we go a step further and think about other re-usable chunks
    that can be broken out into gems, helpers, generators, engines?
  * Adding a README to describe project layout


- Eric

[1] https://www.redhat.com/archives/katello-devel/2012-August/msg00071.html
[2] https://github.com/Katello/katello/issues/450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/katello-devel/attachments/20120815/3591cabd/attachment.htm>