#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): Replying to [comment:4 adimania]: > Replying to [comment:3 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? > Sounds good. Let us discuss with others and close this in the meeting. Please do. My timezone combined with my personal duties makes it almost impossible to attend the cloud WG meetings. > > > > 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? > fedora-dockerfiles package is built for fedora repos and for epel. So could you instead write "... break the fedora-dockerfiles package that is built in Fedora from this repo ..." or something similar to make this clear? > > * "We would test the Dockerfile against right the Fedora release" > > * Did you mean to write "against the right Fedora release"? > Yes. I have corrected this. Cool, thanks. > > * If so, what exactly does that mean? What is the right Fedora release to test an image against? > An image which comes to f22 branch should be tested against fedora 22 release. Yes, but what does that *mean*? What does testing image against a Fedora release mean? How can people do it? How is testing image against e.g. F22 different than testing it against e.g. F23? > > > > 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. > I am not sure about this. If we had CI, I could let go of it. Without CI, I am not really sure. So let's say we have an old(ish) Dockerfile in the repo and readme says it was tested on Docker 1.2. What does this information bring us except showing that noone touched the readme since then? I do agree that having CI would be awesome, but since it looks that the repo may be moved to dist-git and split (as discussed at [1]), I find it hard to convince myself to invest lots of time in this. > > * 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/<directory-in-this-repo> .'" > This sounds good. I will go through some of the Dockerfiles and will make the suggested changes if I don't see any anomaly. Great, thanks! [1] https://lists.fedoraproject.org/pipermail/cloud/2015-October/005902.html -- Ticket URL: <https://fedorahosted.org/cloud/ticket/123#comment:5> cloud <https://fedorahosted.org/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