| 247 | | Github: lack of file service, pull request... |
| 248 | | Release process, release contents (QuattorFS, Dashboard...) |
| | 249 | === GitHub Migration === |
| | 250 | |
| | 251 | Most Quattor components already migrated. Main missing parts are SCDB and QWG templates |
| | 252 | * Aquilon: a clone of the SF repository because of MS restrictions to access GitHub |
| | 253 | * Still willing to move to GitHub as soon as it is possible |
| | 254 | * New Aquilon book decided: make it a subdirectory of the Aquilon repo |
| | 255 | * spma and rpmt-py still here but not built by Jenkins |
| | 256 | * SCDB and QWG in progress: what is in GitHub is only test repos |
| | 257 | * Also missing QuattorFS |
| | 258 | * Currently in SF SVN |
| | 259 | * SVN still enabled at SF: turn it off? |
| | 260 | * Seems painful to disable only write access: seems to require modifying entry for each user |
| | 261 | |
| | 262 | Configuration module status |
| | 263 | * ncm-network not migrated because of the rewrite in progress |
| | 264 | * ncm-openldap in a bad shape but probably used by StratusLab |
| | 265 | * Cal will have a look |
| | 266 | |
| | 267 | Almost every GitHub repository has a matching Jenkins job |
| | 268 | * Several components with a good coverage in terms of unit testing: accessible from GitHub main page from the repository ('Passing' button) |
| | 269 | * GitHub received a pull request after each commit in a Quattor Git repo |
| | 270 | |
| | 271 | Component testing using `prove` |
| | 272 | * No config file required, except to produce XML reports |
| | 273 | * Every `.t` file present in component sources (under `src/test`) is executed |
| | 274 | |
| | 275 | Git branches: prefer private forks rather than branches in main repositories |
| | 276 | * Easily tracked if forks also hosted on GitHub through pull requests |
| | 277 | * A command line tool `hub` available to avoid going through the web interfaces |
| | 278 | * Specific comments possible for pull requests |
| | 279 | * Changes pulled as one commit using a rebase |
| | 280 | * Just require adding a remote in a personal repo to track several related repositories |
| | 281 | |
| | 282 | Main pom file and build tools in a separate repository. |
| | 283 | * Documentaton on how to make a new version of the pom file |
| | 284 | * Pushing them to the central repository requires specific rights: only Cal and Luis |
| | 285 | |
| | 286 | === Release Workflow === |
| | 287 | |
| | 288 | Released pushed to YUM repo |
| | 289 | * One repo per release |
| | 290 | * Have one symlink pointing to the last release: to be used by sites who want to upgrade automatically to the last release |
| | 291 | |
| | 292 | Manual step involved in making a release: create the release file |
| | 293 | * Requires Jenkins to be green |
| | 294 | * Currently only running the unit/functional tests but no test deployment |
| | 295 | * discuss the possibility to deploy VMs on StratusLab cloud: checks how to automate analysis of the installation/upgrade result |
| | 296 | * Keep AII as a separate thing in a first stage |
| | 297 | |
| | 298 | Release numbering: everything renumbered according to the release number whether there was a component change or not |
| | 299 | * Try to see if it is possible to generate a ChangeLog that will contain the list of commits since the last version |
| | 300 | * After a release was made, maven will generate `.1-SNAPSHOT` |
| | 301 | |
| | 302 | Non RPM files: continue to use SF as there is no file service in GitHub |
| | 303 | * Must be done manually |
| | 304 | * Improve the link documentation on quattor.org |
| | 305 | * For documentation, include html (or markdown) version into the quattor.org site |
| | 306 | |
| | 307 | |
