Re: Becoming comaintainer for Fedora-Dockerfiles

[Bohuslav Kabrda]

- Original Message -
> On Fri, Oct 02, 2015 at 05:01:51AM -0400, Bohuslav Kabrda wrote:
> > Heh, it seems that my career as Fedora-Dockerfiles comaintainer may
> > be rather short :) I think having a web frontend with pull requests
> > for the new dist-git is an awesome idea. I'm +0.9 for pagure. The
> > advantage is that it will be completely under Fedora control, the
> > small downside is that potential contributors from outside Fedora
> > will have to create Fedora account, which might scare some people
> > off.
> 
> We want to make the web-pull-request process really easy for using
> Pagure as a documentation tool, too, so support for
> non-fedora-contributor drive-by contributions might come.

Cool, this would really be a nice feature to have.

> > > Maybe? Would it make sense for these to go together with the
> > > dockerfiles they're associated with in a git repo at that level, or
> > > would they be stand-alone and reference other repos? (Do you have
> > > some concrete examples?)
> > So I think that kubernetes/Nulecule examples should be standalone,
> > since most often they'll reference multiple images. What I mean is
> > that they would be a good fit for the current fedora-dockerfiles
> > repo, but if we split the repo into multiple dist-git repos, they
> > won't fit in any one of these.
> 
> So, would all of _those_ examples go into a single entity (package,
> repo, whatever)? What should the distribution method for _these_ be?

I'm not sure :) In fact, I'm wondering whether it's really necessary to be 
shipping these as RPMs. Dockerfiles are good candidates for shipping via RPMs, 
since they are the recipes used to build images that are actually out there (on 
dockerhub, etc). kubernetes/Nulecule examples, on the other hand, will be just 
*examples*, not something you would want to build, deploy and use as is.

> --
> Matthew Miller
> 
> Fedora Project Leader

-- 
Regards,
Slavek Kabrda
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #123: Document process for using Fedora-Dockerfile branches

[Fedora Cloud Trac Tickets]

#123: Document process for using Fedora-Dockerfile branches
--+-
 Reporter:  scollier  |   Owner:
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Future
Component:  ---   |  Resolution:
 Keywords:  meeting   |
--+-

Comment (by bkabrda):

 Hi, I'd suggest creating a CONTRIBUTING.md file and putting the
 contribution guidelines in there. This way, Github will show it as a link
 in all pull requests. Perhaps you could create a pull request that would
 add this file and we could discuss the guidelines there?

 As for the part you created, I think it looks good overall, I just have
 some minor comments:
 * "It is done to ensure that we do not break the package in different
 releases of Fedora" - what do you mean by "break the package"? Which
 package is that?
 * "We would test the Dockerfile against right the Fedora release"
   * Did you mean to write "against the right Fedora release"?
   * If so, what exactly does that mean? What is the right Fedora release
 to test an image against?

 If you do decide to create a pull request as I suggested above, I also
 have several more suggestions:
 * Remove the section "The version of Docker that it was created and tested
 on."; it's not really important and it makes the READMEs look obsolete.
 * Remove the section "Instructions on how to build the Docker image.".
 Building instructions are pretty much the same for all the images and I
 don't think it's necessary to have them in all READMEs. Let's just have
 one instruction in the top level README file like "you can build any of
 the images as 'docker build --rm -t fedora/ .'"

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct