Skip to content
This repository has been archived by the owner on Apr 12, 2021. It is now read-only.

Update HACKING #58

Closed
wants to merge 10 commits into from
Closed

Update HACKING #58

Changes from 8 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
0179b23
Update HACKING
lbazan Apr 8, 2014
c7e7b8b
Update HACKING
lbazan Apr 8, 2014
c073256
Update HACKING
lbazan Apr 9, 2014
0208c6a
App Best Practice
lbazan Apr 9, 2014
bb24187
update link
lbazan Apr 9, 2014
853a784
step 1
lbazan Apr 9, 2014
f15c95a
Update HACKING
lbazan Apr 9, 2014
06c36d4
Update HACKING
lbazan Apr 9, 2014
d1318ce
Add valid sshkey ecdsa
lbazan Apr 14, 2014
bac7180
sshkey ecdsa
lbazan Apr 14, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 48 additions & 19 deletions HACKING
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -241,40 +241,67 @@ not commit mo files.
MAKING A RELEASE
----------------

1. Make sure that any feature branches you want have been merged.
2. If time allows, read and do the :id:`Getting Translated` section below.
3. Pull in new translations using tx pull -a -f. Add any new translations to
1) Any features, hotfixes, etc go to branches before being merged
to develop then master.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, let's rework step 1 better as my comment is really not a step.
Here's what I think should be helpful.

  1. Release has to be done from branch "develop". Make sure you have a working and up-to-date develop's branch (your local branch must not be behind any remote-server's commits)
  • if you have no local copy of fas's repository
    git clone [...]
  • if you have a local copy of fas's repository already
    git pull develop
    /!\ WARNING: this will overwrite any uncommited changes.


2) Make sure that any feature branches you want have been merged.
git clone git@github.com:fedora-infra/fas.git
cd fas/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Step 2 should tell about our use of git-flow.


3) Create a release branch for all of our work
Releases end up on the master branch
git flow release start 0.8.17
make some edits, bump version numbers, commit, release to pypi.
git flow release finish 0.8.17
git push --all
git push --tags
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm.. this step is messing up with all following's.
it must refers to only "git flow release start %_version"
move "make some edits, bump version numbers, commit, release to pypi." to step 4 as stated in my comment below.


# More information about please visit:
https://fedoraproject.org/wiki/Infrastructure/AppBestPractices

4) If time allows, read and do the :id:`Getting Translated` section below.

5) Pull in new translations using tx pull -a -f. Add any new translations to
the fas.cfg.sample file. Commit the changes.
4. Update the version in fas.spec and fas/release.py. Commit the changes to
the master branch.
5. Make sure the NEWS file is up to date
6. Push the results to the server.
7. Make a fresh clone of the repository::

6) Make sure that the NEWS file is accurate (use git log if needed).
After that, push the develop branch to the server::
# Update files
git flow publish
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's too many steps regarding common files to update.
Make 1 step for all with bullet-point.
such as:
4) Add some modifications/updates to common files

  • Update rpm's spec file
  • Update NEWS file.
  • pull in new [...]
  • etc


7) Push the results to the release branch. Otherwise, no need to.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's missing infos here.
7) Optional: publish release branch to remote server, if you're not the only one working
on the release so that other can add commits
git flow release publish %_version


8) Make a fresh clone of the repository::
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too many steps to build tarball here also.
8) Release new tarball
a. make a fresh clone fas's repo --> cmd-line
b. build tarball --> cmd-line
c. etc

cd /var/tmp
git clone git://git.fedorahosted.org/git/fas
8. Make the source tarball in that directory::
git clone git@github.com:fedora-infra/fas.git

9) Make the source tarball in that directory::
cd /var/tmp/fas
python setup.py sdist
9. Make rpms from the tarball. You can use the koji dist-5E-epel-infra build

10) Make rpms from the tarball. You can use the koji dist-5E-epel-infra build
target for that::
mv dist/*.tar.gz .
rpmbuild-md5 -bs --nodeps fas.spec
koji build --scratch dist-5E-epel-infra fas*.src.rpm
10. Upload the tarball to fedorahosted. Copy the rpms from koji to the

11) Upload the tarball to fedorahosted. Copy the rpms from koji to the
infrastructure repository::
scp fas*tar.gz fedorahosted.org:/srv/web/releases/f/a/fas/
ssh puppet1
wget # all rpm files from the scratch build
rpm --addsign *.rpm
# Move rpms to the epel infrastructure dir
# createrepo the new repository
11. tag the release::
cd [LOCAL GIT REPO]
git tag [RELEASE VERSION NUMBER]
git push --tags
12. Install in staging and test.
13. Finally, upgrade the production fas servers.

12) mark the release as finished in git::
cd ../fas
git flow release finish [RELEASE VERSION NUMBER]
git push -F
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not correct.
Just git flow release finish -F -p %_version


13) Install in staging and test.

14) Finally, upgrade the production fas servers.

Getting Translated
==================
Expand Down Expand Up @@ -303,17 +330,19 @@ release. Allow 8 to 10 days for this to happen.

* The staging fas server can be looked at for the running code:
https://admin.stg.fedoraproject.org/accounts/
* Code can be viewed at http://git.fedorahosted.org/git/?p=fas.git;a=tree
* Code can be viewed at https://github.com/fedora-infra/fas
* The date that you're going to release (Remember, you want it to be 8-10
days from this announcement)
* If you have the time to make daily, weekly, etc updates to stg to pull in
the new translations mention that so the translators know whether they can
expect to see their changes in a live environment or not.

4) When you make a new test release, be sure you remember the tx pull step from
above or you won't be pulling in the new translations. When you accept new
commits, be sure that there are no new strings. If new strings are
unavoidable in he fixing of a bug, email trans@lists.fedoraproject.org to
make people aware of it.

5) When the release date arrives, spin the new release into an rpm as above
(remembering to run tx pull -a :-) and make the release.

Expand Down