On Tue, Oct 20, 2015 at 12:50 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
On Tuesday, October 20, 2015 10:47:56 AM Adam Miller wrote:
> Hello all,
> I wanted to make a few suggestions/proposals to the Koji project
> to get feedback.
>
> First off, I'd like to propose that koji officially move out of
> FedoraHosted and into pagure[0] so that people can easily fork, create
> topic branches and open pull requests for interactive peer review.
>
> In the event that is acceptable I would also like to propose that all
> documentation move out of the Fedora Wiki and move into the koji git
> repo itself under the docs directory either formatted as Sphinx[1]
> reStructured Text, or markdown[2]. This could either be hosted
> directly in pagure.io or in readthedocs.org[3].
+1 though maybe we should use pagure's docs repo rather than a docs dir.
> From there I would like to suggest a formal website for koji, maybe
> koji.io or similar. I don't really have a preference or suggestion on
> the specific url. This website would be a simple landing page for all
> information that someone interested in Koji would be looking for. It
> would briefly explain what koji is, provide references on how to use
> it, deploy it, how to administer it, and how get involved in
> development of it. My idea is that the website itself would be a
> static site that is generated using something like pelican[4] or
> nikola[5], the source code for the site would also live in koji's git
> repository such that all content would be in a central location and
> could even be shared between the site and docs where appropriate. We
> could later get clever and have the website be updated automatically
> when a pull request gets merged that updates it's content, but I don't
> want to get ahead of myself.
Sounds good to me.
> In the event that is acceptable, I would also like to propose a
> "recommended developer workflow" and introduce the use of the tito[6]
> utility for koji to assist in both the release tasks but also for
> iterative development and/or eventual CI without giving up the
> standard rpm install process. I have started mocking up what I think
> would be a good starting place for a workflow, it's currently a work
> in progress and doesn't actually function as described for reasons I
> don't yet know (koji-hub and I are fighting with the database) but
> before chewing up more time working on it I wanted to make sure that
> this is even something that the group at large is open to.
What does tito give us? how would you see it helping the workflow? I ask
because as to the deployment of koji it is not possible to use, We have a
permanent patch in fedora pointing the default koji config to fedora's koji
instance, at the moment we have a special build of koji internally in fedora
with additional patches we need that are not suitable for upstream inclusion.
I am all for getting CI and a test suite up and running. enabling people to
more easily test patches is also a needed thing. I am just not 100% sure of
the best way to do so.
Tito basically just adds the automation to do RPM builds off your
current git branch and can even farm them out to mock so you can
deploy a set of RPMs as part of an iterative development workflow.
This lends itself to CI pretty naturally from that point.
We did this in the OpenShift team, basically the workflow there is
that you would have a Developer Environment, work on things in your
local git topic branch, then run a "devenv sync" (we had a devenv
script that did all sort of things) and the sync would push your local
changes in your branch to your remote DevEnv (Amazon EC2 instances),
it would then fire off a tito build of all the packages (there were
many, in koji space it would just be the one), create a local yum
repo, perform an update process including 'yum update' the packages
and then run the test suite against the DevEnv.
This allows for a "real world" deployment scenario as the packages are
built into RPMs and applied as an update along with any update
procedures needed so that it can be tested as a deployed environment
instead of as just a dev instance running on someone's laptop.
I'm effectively proposing this workflow but catered a little more to
the way Koji is and trying to decouple the restrictions on the DevEnv,
tito is just an utility that helps in the process.
-AdamM
>
https://github.com/maxamillion/koji-dev
>
> Eventually if this developer workflow (or really any documented
> developer workflow) was deemed as "recommended" by the group, I would
> like to also have it live within the koji git repository such that it
> can be a part of the official documentation for new and potential
> contributors on how to get started working with koji development and
> be highlighted on the (new) proposed website.
>
> This is effectively a multi-part "step 1", as I would like to build on
> top of this and move towards having CI for the project but getting
> things in a place where we can easily facilitate iterative developer
> workflows is something that I consider as a prerequisite.
>
> I'm definitely looking forward to feedback, thanks for reading this far :)
Thanks for putting a proposal out there
Dennis
_______________________________________________
koji-devel mailing list
koji-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/koji-devel