[katello-devel] Codebase Split-up
Petr Chalupa
pchalupa at redhat.com
Wed Apr 10 07:05:51 UTC 2013
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.
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>
>
>
More information about the katello-devel
mailing list