#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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
