#123 Document process for using Fedora-Dockerfile branches
Closed None Opened 8 years ago by scollier.

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.


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

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.

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

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.

I deleted all non-master branches.

Login to comment on this ticket.

Metadata