[katello-devel] Codebase Split-up

Fri Apr 12 15:14:30 UTC 2013

I vote for option 3.

David

----- Original Message -----
> From: "Eric D Helms" <ericdhelms at gmail.com>
> To: "katello-devel" <katello-devel at redhat.com>
> Sent: Friday, April 12, 2013 10:50:40 AM
> Subject: Re: [katello-devel] Codebase Split-up
> 
> This discussion has stagnated enough that it seems like a good time to layout
> the options that have come out of the discussion and vote on one to go
> forward with. Please vote and we'll go forth with what we as a community
> want.
> 
> Option 1: Do Nothing.
> - Self explanatory
> 
> Option 2: Re-organize within single repository
> - create a few new directories and move related entities into those
> directories
> - add documentation to attempt to explain the organization
> - example (from Petr's email):
> 
> packaging/katello-configure/
> packaging/katello-utils/
> packaging/rel-eng/
> packaging/repos/
> packaging/selinux/
> packaging/certs-tools/
> cli/
> rails_app/
> agent/
> 
> Option 3: Break out components into separate repositories
> - create a couple of new git repositories to hold logical components
> - example (from Justin's email):
> 
> katello
> katello-installer
> katello-selinux
> katello-cli
> 
> 
> - Eric
> 
> 
> On Wed, Apr 10, 2013 at 8:56 AM, Justin Sherrill < jsherril at redhat.com >
> wrote:
> 
> 
> 
> On 04/10/2013 03:05 AM, Petr Chalupa wrote:
> 
> 
> 
> 
> On 09.04.13 19:27, Eric D Helms wrote:
> 
> 
> On Tue, Apr 9, 2013 at 12:23 PM, Petr Chalupa < pchalupa at redhat.com
> <mailto: pchalupa at redhat.com >> wrote:
> 
> I am not strongly against splitting the main repository, but better
> directory structure and documentation seems to me like a better choice.
> 
> AFAIK There are 2 main reason for splitting the repositories:
> 
> 1) Make orientation easier for newcomers.
> 2) Make Travis run faster.
> 
> 
> I'd add splitting should create focused pull requests, focused
> documentation and makes it clearer that a 'katello-packaging' git
> repository is where all things packaging live and can be monitored.
> While 'katello-cli' would reflect the a command line project which is
> not the application itself but stands apart consuming the API's in a
> more 'independent' way. I may be a bit biased or different in how I work
> given that I have been able to do a couple of separate projects
> (runcible, trebuchet, trebuchet-mount) that were more focused on one thing.
> 
> On the other hand I saw a lot of pull-requests adding features composed from
> both API and CLI part. I think it is a good think, the pull-request is
> containing whole feature. If we split the repository we have to also split
> the pull-request and cross-link the newly created pull-requests. Most of the
> time this would be done by a single person who would be developing it in
> parallel. Seems to me like unnecessary overhead.
> 
> 
> One good thing about multiple pull requests is that it would reduce the
> average size of our pull requests and make them easier to review.
> 
> 
> 
> 
> 
> I think splitting would make sense if we also start viewing the new
> repositories as projects with its backlogs, stories, bugs, and people
> responsible for the project.
> 
> If each developer would work on only 2 of these projects it would be easier
> to maintain internal conventions/integrity of the project. It would be
> easier for these small sub-teams to share information and to align theirs
> approaches to the sub-project.
> 
> Since I've touched splitting into sub-projects one think would make sense to
> me in future to split katello rails app into UI and core with API. UI would
> only use API same as CLI. Whole UI could be done in AngularJS, we are
> already playing with it in nutupane and alchemy, why not to go all the way?
> It also probably deserves its own thread.
> 
> 
> 
> 
> I think 1) can be fixed by better directory names e.g.
> 
> packaging/katello-configure/
> packaging/katello-utils/
> packaging/rel-eng/
> packaging/repos/
> packaging/selinux/
> packaging/certs-tools/
> cli/
> rails_app/
> agent/
> 
> and by placing README into each directory describing what is it.
> 
> Also I thing top-level organization of the source code is not the
> biggest barriers we have: source code lacking documentation and
> outdated wiki. So the split may or may not help.
> 
> And if there are objections in our current community (us) I would
> not go against it.
> 
> 2) Yes it would make run Travis faster, but we will leave Travis at
> some point anyway. Travis cannot be used to test packaging,
> installation, configuration and smoke tests. Which we need for
> nightly not to be broken all the time. I already have story for it
> on Trello [1].
> 
> This is probably an entirely different conversation worth having. I
> like the spirit of this idea, but what is the time estimate for all of
> these actions to happen on every pull request, every update to a pull
> request ? Packaging, installation, configuration and smoke tests are not
> cheap time wise combined with our unit tests. There is also the factor
> of a public Jenkins which haven't solved. Again, probably worth another
> thread to flush this out entirely because I believe there are a number
> of people that have some opinions and ideas on this topic.
> 
> You are right, I was already planning to send email about this topic, I'll do
> it. On my machine the whole package-install-config-smoke cycle takes under 1
> hour. It will be probably little bit faster if I add proxy to cache the
> downloaded rpms.
> 
> 
> 
> 
> [1] https://trello.com/card/ci/__ 511bd7357c52d1c61c00510e/55
> < https://trello.com/card/ci/ 511bd7357c52d1c61c00510e/55 >
> 
> Petr
> 
> 
> On 08.04.13 14:46, Eric D Helms wrote:
> 
> I am not claiming all the top level directories in our
> repository are
> candidates for breakout, but as I see it we have this breakdown:
> 
> Needed to run Katello:
> src/
> 
> Needed for a production installation via RPM:
> katello-configure/
> katello-utils/
> rel-eng/
> repos/
> selinux/
> certs-tools/
> 
> Needed for advanced system interaction:
> agent/
> 
> Needed to interact with a Katello server via command line:
> cli/
> 
> 
> The claim keeps being made that because code is in a single git
> repository, people are more aware of it. And I'd argue, that if you
> took a survey of our developers, you'd find the overwhelming
> majority of
> time is spent in src/ and that there are some parts of
> repository that
> are complete mysteries (selinux, katello-utils). And that's
> acceptable
> because not everybody needs to be a domain expert on every aspect.
> 
> But if I saw the above breakdowns as very clearly broken out
> pieces, I'd
> have a better understanding of all the components and how they
> fit into
> the overall landscape of our project. Further, Ruby/Rails
> developers
> would not come to our project confused by the lack of standard
> project
> layout, and the chunk of python code stuck in alongside
> everything. And
> sure, you can claim that we don't have enough upstream developers to
> warrant their consideration, but as usual I think that is a terrible
> excuse or reason since our goal is to be upstream friendly so
> that when
> upstream developers do come knocking they aren't overwhelmed. (And I
> agree Petr, documentation can help go a long way for some of this)
> 
> Eric
> 
> On Mon, Apr 8, 2013 at 7:51 AM, Miroslav Suchý
> 
> < msuchy at redhat.com <mailto: msuchy at redhat.com >
> <mailto: msuchy at redhat.com <mailto: msuchy at redhat.com >>> wrote:
> 
> On 04/06/2013 09:23 PM, Eric D Helms wrote:
> 
> I didn't lose track of anything. I am lost as to what
> exactly
> you are
> referencing or trying to imply here.
> 
> 
> Ok, different example. The git repo rail-restapi.git
> (discussed in
> different thread from Friday) which was fork of
> apipie-rails and now
> it was dead. No one noticed that, no one bother about that.
> Because
> no one was forced to check it out.
> I'm trying to say that if that would be part of main git repo,
> someone would notice it much much sooner and done something
> with that.
> When it was standalone git repo everybody ignored it.
> 
> --
> Miroslav Suchy
> Red Hat Systems Management Engineering
> 
> 
> ______________________________ _____________________
> katello-devel mailing list
> katello-devel at redhat.com <mailto: katello-devel at redhat. com >
> <mailto: katello-devel at redhat. _ _com
> <mailto: katello-devel at redhat. com >>
> https://www.redhat.com/____ mailman/listinfo/katello-devel
> < https://www.redhat.com/__ mailman/listinfo/katello-devel >
> < https://www.redhat.com/__ mailman/listinfo/katello-devel
> < https://www.redhat.com/ mailman/listinfo/katello-devel >__>
> 
> 
> 
> 
> 
> ______________________________ ___________________
> katello-devel mailing list
> katello-devel at redhat.com <mailto: katello-devel at redhat. com >
> https://www.redhat.com/__ mailman/listinfo/katello-devel
> < https://www.redhat.com/ mailman/listinfo/katello-devel >
> 
> 
> ______________________________ ___________________
> katello-devel mailing list
> katello-devel at redhat.com <mailto: katello-devel at redhat. com >
> https://www.redhat.com/__ mailman/listinfo/katello-devel
> < https://www.redhat.com/ mailman/listinfo/katello-devel >
> 
> 
> 
> ______________________________ _________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/ mailman/listinfo/katello-devel
> 
> ______________________________ _________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/ mailman/listinfo/katello-devel
> 
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel