Proposal for some Project Updates/Changes

[Adam Miller]

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

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

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.

    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 :)

-AdamM

[0] - https://pagure.io/
[1] - http://sphinx-doc.org/
[2] - https://en.wikipedia.org/wiki/Markdown
[3] - https://readthedocs.org/
[4] - http://blog.getpelican.com/
[5] - https://getnikola.com/
[6] - https://github.com/dgoodwin/tito

[Neal Gompa]

On Tue, Oct 20, 2015 at 11:47 AM, Adam Miller <maxamillion(a)fedoraproject.org
>  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].
>
>  
​Yes, please! Having the documentation in one central location will make
working with it much easier.​



>  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.
>  ​
>  
​This sounds good. It would also be awesome if there were some "quick
testing/deployment" images that could be used for people to try out Koji
locally, along the lines of how the Open Build Service advertises
itself[0]. It might even be worth it to have Koji itself construct these
images as a demonstration of its abilities (just like how OBS does it for
their appliance images).​


>  ​
>
>  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.
>
>      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.
>
>  
​The Koschei service should probably also be moved into the Koji project,
as it's really the CI component for Koji. So I would imagine that your
workflow stuff needs to cover the setup and integration of Koschei with
Koji.​



>  I'm definitely looking forward to feedback, thanks for reading
> this far :)
>  
​No problem. :)
​


>  -AdamM
>
>  [0] - https://pagure.io/
>  [1] - http://sphinx-doc.org/
>  [2] - https://en.wikipedia.org/wiki/Markdown
>  [3] - https://readthedocs.org/
>  [4] - http://blog.getpelican.com/
>  [5] - https://getnikola.com/
>  [6] - https://github.com/dgoodwin/tito
>
>  
​[0]: http://openbuildservice.org/download/​


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Dennis Gilmore]

On Tuesday, October 20, 2015 12:07:19 PM Neal Gompa wrote:
>  On Tue, Oct 20, 2015 at 11:47 AM, Adam Miller
> <maxamillion(a)fedoraproject.org 
<snip>
>  > 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.
>  
>  ​The Koschei service should probably also be moved into the Koji project,
>  as it's really the CI component for Koji. So I would imagine that your
>  workflow stuff needs to cover the setup and integration of Koschei with
>  Koji.​ 
koschei is abusive to koji. While the service it provides is really useful, i 
personally find it a hindrance to being effective when using kojiweb  and I 
wish it was implemented in some other way not using koji.  Perhaps we need to 
figure out a better way to make it work better.

Dennis

[Mike McLean]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/20/2015 01:40 PM, Dennis Gilmore wrote:
>  On Tuesday, October 20, 2015 12:07:19 PM Neal Gompa wrote:
> > On Tue, Oct 20, 2015 at 11:47 AM, Adam Miller
> > <maxamillion(a)fedoraproject.org
>  <snip>
> >> 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.
> > 
> > ​The Koschei service should probably also be moved into the Koji
> > project, as it's really the CI component for Koji. So I would
> > imagine that your workflow stuff needs to cover the setup and
> > integration of Koschei with Koji.​
>  
>  koschei is abusive to koji. While the service it provides is really
>  useful, i personally find it a hindrance to being effective when
>  using kojiweb  and I wish it was implemented in some other way not
>  using koji.  Perhaps we need to figure out a better way to make it
>  work better. 
Agreed. Koshei should not be pulled into Koji.

Also, not everything koji-related needs to be merged in. There is room
for multiple interacting tools. That's why Koji has an api, after all.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWJpuGAAoJEI4ybUZMjaclYtwP+gIp5eyIfoccM4TUQnV/ZQb1
> bapKxEa8DiDdSAsxs63Hq4dbgYWI5kgKMsvZQ29e9WdbDw8BOepAREUw+THKQuYi
> xwEErZjpCovND/4SwfkbCvRD3XpmdQmlIuCuqn+0IJjGui8UtTx3MGM6JmK3VeLV
> +ik6swJ9DkVS7iJhrvfP+ugSUbuWAv9xAw44k/h6R+7OZemHhqnT3xcOc5WLV/Hr
> +74fMykj8SIEG6qb50uZWSV55ub2RXH+RFN8064yXs8nzI3px7/+DZ5ydWZkQsO2
> WiPDRikBWVb7kkmINiLOuRLQQNSI7CD1uVC9LCz2ETJOQfw5tWNIhkY6Lx6q0UV8
> hPkTZJQ2KckxDiP56W7LhQTwbz+N+e5F7Q4rGlhYssE0LKOF2rsEXaR8iqaM9V0x
> s+FacPlRIn9M8cFUBpk9I37rVj314FIAyaZYL6lyVGyx1CN3JVGqRPz0sySjDxIT
> hotZpLHevaf8HaMt2l5oY12g98FVk70U+OPS5ejBkW6CvoLJtSUcNt/XwchP1H/p
> g2uLIfzRsA54820nqKRshaElO9Q7136WRD3Dv5AsIe5waEYZPyEMGeFUjR3r3M+f
> MpRijVlCzszeN9gmFLN6+RAdPh9HezbmDnb3wgF4/sBQlBz+lnoo65qBF1nB5xzq
> THPUkAO5ZvcAVbDDyxIM
> =wgyT
> -----END PGP SIGNATURE-----

[Adam Miller]

On Tue, Oct 20, 2015 at 11:07 AM, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Oct 20, 2015 at 11:47 AM, Adam Miller
>  <maxamillion(a)fedoraproject.org&gt; 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].
> >
>
>  Yes, please! Having the documentation in one central location will make
>  working with it much easier.
>
>
> >
> > 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.
>
>
>  This sounds good. It would also be awesome if there were some "quick
>  testing/deployment" images that could be used for people to try out Koji
>  locally, along the lines of how the Open Build Service advertises itself[0].
>  It might even be worth it to have Koji itself construct these images as a
>  demonstration of its abilities (just like how OBS does it for their
>  appliance images).
>
> >
> >
> > 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.
> >
> >     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.
> >
>
>  The Koschei service should probably also be moved into the Koji project, as
>  it's really the CI component for Koji. So I would imagine that your workflow
>  stuff needs to cover the setup and integration of Koschei with Koji.
>  
While I don't really have a firm opinion on Koschei being a part of
Koji or not, I think that caters to CI of other projects and not of
Koji. I'm more concerned about doing CI on Koji itself such that we
could have CI tests run on new commits or pull requests to the Koji
code base if/when it's in pagure.io

-AdamM

> >
> > I'm definitely looking forward to feedback, thanks for reading this far :)
>
>
>  No problem. :)
>
> >
> >
> > -AdamM
> >
> > [0] - https://pagure.io/
> > [1] - http://sphinx-doc.org/
> > [2] - https://en.wikipedia.org/wiki/Markdown
> > [3] - https://readthedocs.org/
> > [4] - http://blog.getpelican.com/
> > [5] - https://getnikola.com/
> > [6] - https://github.com/dgoodwin/tito
> >
>
>  [0]: http://openbuildservice.org/download/
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>
>  _______________________________________________
>  koji-devel mailing list
>  koji-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/koji-devel
>

[Dennis Gilmore]

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.


>      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

[Adam Miller]

On Tue, Oct 20, 2015 at 12:50 PM, Dennis Gilmore <dennis(a)ausil.us&gt; 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
>

[Miroslav Suchý]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/20/2015 07:50 PM, Dennis Gilmore wrote:
>  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. 
This is actually perfect task for Tito.
You can have upstream git of koji (where is configured normal tito
builder) and then your own fork of koji with patches applied and set
the upstream as remote branch.
When you change Tito config to use DistributionBuilder in your fork,
then any time you build package (just "tito build --rpm") it will
construct pristine tar (original as upstream release) and
automatically create those patches and put them in spec file.
So it give you the comfort of working and developing in git with all
patches applied. And you can still create the binary rpm (or srpm)
with one simple command.

And of course it gives you some other benefits:
 * it create rpm only from committed code.
 * it create release only from properly tagged commit
 * before doing release it check if those commits were pushed (it
previously happened a lot to me that I seen project release, but the
responsible colleague forgot to git-push).
 * you can very easily build development builds, which easy testing
and CI.

Mirek
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWJpkIAAoJEODXORnxaDVAfFgP/2H+xKyHzuWR+R1/6SUCmGJT
> NS1wEKq1p6UwqBMjf8dZkTuoeJG1pvpdk/tmwY6ztHwwEPNjiURbCtHUZpNMyagL
> R2f0E2kJkjg1dSpboZF5lgRsEtwxzdLhrJrC3QAUIBOSPiFfmVa+aAwekMKFPQiq
> 3q63bxRS1OqvSpH3W4Y7A2tzFUoHozB72DxYrFC2jyF5cxcSjnbl+D04jG2Wb78t
> c7x8KSTtvOWx8phASQNjgliHrF5jKtjXvbbT8xGeuWJ2q2qVQcohrf4tdX+o52lo
> MgF9I2iNGfmG+Pk1xeuT4DWQ7+Dn6ITV907DJCGRDzguMkeh2rzkEIZVEqU8YvOB
> 5LGuB98pBfs9UgJUb6f9jQQVAQQPK4qA06pb3TNf49I6TqzYsp14p68LibPNxzu9
> LDJjrOyL1BaZAYbTj7kNpPsz7j1ypyVYXpl1thAh/x/IUDz44fS6dwhItTQdGhvn
> HQ2TuQLb0p/soa9D2Bl+TZ0ve6MQqbzfBZJwTrEcUkhtM2GcD7a4e5FjcXFmDsSl
> T1uAgqpf36FJW1UspvJG15DzLNS88kAMXDCLChV+2chuKnX248C6M8dOVyoSczG0
> jj5fYSn1odgw5h7yDVtxzZOqUBiqOQTFismfUiBrS7qVcVOLLHyGOPlIQjNcYufW
> ixYFk3Tb6j/7UZMx3AUW
> =aAGO
> -----END PGP SIGNATURE-----

[Mike McLean]

On 10/20/2015 11:47 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. 
This has come up separately, and think I am agreeable, but still just
slightly cautious to embrace a tool that is so recently out of beta.

There's also the question of pagure vs github. Some would argue that the
benefits you list are even more pronounced on github.

>  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]. 
Fixing docs is definitely a goal. Both pagure and github seem to have
separate docs features and I'm not sure what the best approach is.

I appreciate a nice web view for docs, but I also want the docs to be
usable from just a checkout.

>  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. 
Agreed. I would like to have a project website.

>  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. 
tito seems to be a popular tool that solves a real problem. I haven't
really had the chance to use it much, though.

>      https://github.com/maxamillion/koji-dev 
Thanks for the mock up

>  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. 
Seems that that will fall in with docs, whether that ends up in the main
repository, or a separate git repository.

>  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 :)
>  
>  -AdamM
>  
>  [0] - https://pagure.io/
>  [1] - http://sphinx-doc.org/
>  [2] - https://en.wikipedia.org/wiki/Markdown
>  [3] - https://readthedocs.org/
>  [4] - http://blog.getpelican.com/
>  [5] - https://getnikola.com/
>  [6] - https://github.com/dgoodwin/tito
>  _______________________________________________
>  koji-devel mailing list
>  koji-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/koji-devel
>

[Mike McLean]

On 10/20/2015 03:47 PM, Mike McLean wrote:
>  On 10/20/2015 11:47 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.
>  
>  This has come up separately, and think I am agreeable, but still just
>  slightly cautious to embrace a tool that is so recently out of beta. 
So I really am a bit torn on this. Afaict, pagure requires a Fedora
account (I don't see a generic openid login option).

I asked another contributer how they felt about github and they balked
at the notion of having to create a github account. However, that
aversion could easily go the other way for potential contributers. There
are plenty of Koji instances besides Fedora's and it is entirely
possible to be interested in Koji and not Fedora.

Side note: I realize that this is entirely where we are now, as
fedorahosted also requires a fedora login, but if we're making this move
to improve participation, shouldn't we consider the larger community?

Or maybe I'm worried over nothing. The old ways will still work, and git
is still git.

Is there anyone on the list that wants to contribute and is averse to
creating a Fedora account?

[Neal Gompa]

On Tue, Oct 20, 2015 at 5:01 PM, Mike McLean <mikem(a)redhat.com&gt; wrote:

>  On 10/20/2015 03:47 PM, Mike McLean wrote:
>  > On 10/20/2015 11:47 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.
>  >
>  > This has come up separately, and think I am agreeable, but still just
>  > slightly cautious to embrace a tool that is so recently out of beta.
>
>  So I really am a bit torn on this. Afaict, pagure requires a Fedora
>  account (I don't see a generic openid login option).
>
>  I asked another contributer how they felt about github and they balked
>  at the notion of having to create a github account. However, that
>  aversion could easily go the other way for potential contributers. There
>  are plenty of Koji instances besides Fedora's and it is entirely
>  possible to be interested in Koji and not Fedora.
>
>  Side note: I realize that this is entirely where we are now, as
>  fedorahosted also requires a fedora login, but if we're making this move
>  to improve participation, shouldn't we consider the larger community?
>
>  Or maybe I'm worried over nothing. The old ways will still work, and git
>  is still git.
>
>  Is there anyone on the list that wants to contribute and is averse to
>  creating a Fedora account?
>
>  
​I personally have no problems having a Fedora account (I've had one for
years). But I know folks who are interested that balk at the idea of having
to set up a Fedora account., especially if they intend to work on Koji in a
way that really is more for "beyond Fedora" in their view.

​Perhaps maybe GitLab.com could work? GitLab.com lets people use their
Google, Twitter, GitHub, or BitBucket accounts to log in​. If they don't
have an account with any of those services, they can create a regular
account. It also helps that GitLab is FOSS in its own right, and while we
don't have it in Fedora (I don't know to what extent how many of the
dependent gems we are missing), I think it's more appealing than GitHub for
a lot of people. I believe even the GNU Mailman folks recently made the
move to GitLab.com, too.

Of course, Fedora could host its own GitLab CE instance by installing
their... erm... "Omnibus" RPM that contains all the stuff to make it work.
But I think that it would probably make more sense to roll out to
GitLab.com and potentially move it in-house if Fedora can get GitLab into
the repositories.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Adam Miller]

On Tue, Oct 20, 2015 at 4:01 PM, Mike McLean <mikem(a)redhat.com&gt; wrote:
>  On 10/20/2015 03:47 PM, Mike McLean wrote:
> > On 10/20/2015 11:47 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.
> >
> > This has come up separately, and think I am agreeable, but still just
> > slightly cautious to embrace a tool that is so recently out of beta.
>
>  So I really am a bit torn on this. Afaict, pagure requires a Fedora
>  account (I don't see a generic openid login option).
>
>  I asked another contributer how they felt about github and they balked
>  at the notion of having to create a github account. However, that
>  aversion could easily go the other way for potential contributers. There
>  are plenty of Koji instances besides Fedora's and it is entirely
>  possible to be interested in Koji and not Fedora.
>
>  Side note: I realize that this is entirely where we are now, as
>  fedorahosted also requires a fedora login, but if we're making this move
>  to improve participation, shouldn't we consider the larger community? 
That's actually a good point to bring up. Something that I would like
to highlight about this proposal that I don't think I did a good job
of doing before hand is making it stand out more as it's own
independent upstream project from Fedora to potentially broaden the
contributor base. I don't personally have an issue with making
accounts all over the place but others might and github is kind of a
common ground for developers all over.

-AdamM

>  Or maybe I'm worried over nothing. The old ways will still work, and git
>  is still git.
>
>  Is there anyone on the list that wants to contribute and is averse to
>  creating a Fedora account?
>  _______________________________________________
>  koji-devel mailing list
>  koji-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/koji-devel

[Peter Robinson]

> >> 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.
> >
> > This has come up separately, and think I am agreeable, but still just
> > slightly cautious to embrace a tool that is so recently out of beta.
>
>  So I really am a bit torn on this. Afaict, pagure requires a Fedora
>  account (I don't see a generic openid login option).
>
>  I asked another contributer how they felt about github and they balked
>  at the notion of having to create a github account. However, that
>  aversion could easily go the other way for potential contributers. There
>  are plenty of Koji instances besides Fedora's and it is entirely
>  possible to be interested in Koji and not Fedora.
>
>  Side note: I realize that this is entirely where we are now, as
>  fedorahosted also requires a fedora login, but if we're making this move
>  to improve participation, shouldn't we consider the larger community?
>
>  Or maybe I'm worried over nothing. The old ways will still work, and git
>  is still git.
>
>  Is there anyone on the list that wants to contribute and is averse to
>  creating a Fedora account? 
There is plans to allow automatic creation/linking of FAS accounts to
things like google/facebook/other accounts to make it easier for this
side of things for "drive by" style contributions so it might not be
an issue for long .

Peter

[Adam Miller]

On Tue, Oct 20, 2015 at 2:47 PM, Mike McLean <mikem(a)redhat.com&gt; wrote:
>  On 10/20/2015 11:47 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.
>
>  This has come up separately, and think I am agreeable, but still just
>  slightly cautious to embrace a tool that is so recently out of beta.
>
>  There's also the question of pagure vs github. Some would argue that the
>  benefits you list are even more pronounced on github. 
I don't have a hard preference. I generally default to suggesting
pagure.io when it comes to things that are within the Fedora ecosystem
but I have no qualms with github personally.

> > 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].
>
>  Fixing docs is definitely a goal. Both pagure and github seem to have
>  separate docs features and I'm not sure what the best approach is.
>  
readthedocs.org is popular both in the Fedora dev community and the
python community at large so if we went that route we could decouple
it from github or pagure.

>  I appreciate a nice web view for docs, but I also want the docs to
> be
>  usable from just a checkout. 
+1 - This is definitely something that I'd like. I think well
formatted/written Markdown or reStructured Text is readable/usable on
it's own but I'm open to suggestion, was mostly just wanting to point
out suggestions that are popular in the python ecosystem.

> > 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.
>
>  Agreed. I would like to have a project website.
>
> > 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.
>
>  tito seems to be a popular tool that solves a real problem. I haven't
>  really had the chance to use it much, though. 
Overall I'm a tito fan, but I'm not married to it as part of the
proposal if there are reservations or alternatives that others prefer.

> >     https://github.com/maxamillion/koji-dev
>
>  Thanks for the mock up
>
> > 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.
>
>  Seems that that will fall in with docs, whether that ends up in the main
>  repository, or a separate git repository. 
+1

Thanks,
-AdamM
> > 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 :)
> >
> > -AdamM
> >
> > [0] - https://pagure.io/
> > [1] - http://sphinx-doc.org/
> > [2] - https://en.wikipedia.org/wiki/Markdown
> > [3] - https://readthedocs.org/
> > [4] - http://blog.getpelican.com/
> > [5] - https://getnikola.com/
> > [6] - https://github.com/dgoodwin/tito
> > _______________________________________________
> > koji-devel mailing list
> > koji-devel(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/koji-devel
> >
>
>  _______________________________________________
>  koji-devel mailing list
>  koji-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/koji-devel