#123: Document process for using Fedora-Dockerfile branches ----------------------+-------------------- Reporter: scollier | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Keywords: ----------------------+-------------------- This should probably go on the github repo home page. Need to provide instructions for users to submit to a specific branch, and not just to master.
#123: Document process for using Fedora-Dockerfile branches ----------------------+--------------------- Reporter: scollier | Owner: Type: task | Status: new Priority: normal | Milestone: Future Component: --- | Resolution: Keywords: meeting | ----------------------+--------------------- Changes (by scollier):
* keywords: => meeting
#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 adimania):
Does [https://github.com/fedora-cloud/Fedora-Dockerfiles/wiki/Guidelines- for-Creating-Dockerfiles#branches-in-fedora-dockerfiles-repo this] looks good?
#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/<directory-in-this-repo> .'"
#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 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.
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.
- "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.
- 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.
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.
- 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.
#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
#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 maxamillion):
+1 to the branching doc
#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 scollier):
now that we are basically standardized on f23, and f20 has been deprecated, I'm going to collapse all the branches into master, we'll work from there.
#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 scollier):
I deleted all non-master branches.
#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 scollier):
added https://github.com/fedora-cloud/Fedora- Dockerfiles/blob/master/CONTRIBUTING.md
#123: Document process for using Fedora-Dockerfile branches ----------------------+--------------------- Reporter: scollier | Owner: Type: task | Status: closed Priority: normal | Milestone: Future Component: --- | Resolution: fixed Keywords: meeting | ----------------------+--------------------- Changes (by scollier):
* status: new => closed * resolution: => fixed
-
Fedora Cloud Trac Tickets