2014-09-05 17:08 GMT+02:00 Pierre-Yves Chibon <pingou@xxxxxxxxxxxx>: > Dear all, > > In the last months, Till and I together with infrastructure and > release-engineering have been thinking and working on how we could improve the > current workflow for new package and new branch. > > To give you an idea, this is the current workflow: > > Current new-package procedure: > ============================== > > * packager opens a review-request on bugzilla > * reviewer sets the fedora-review flag to ? > * reviewer does the review > * reviewer sets the fedora-review flag to + > * packager creates the scm-request and set fedora-cvs flag to ? > * cvsadmin checks the review (check reviewer is a packager, check if reviewee > required a sponsor or not, check if there was a review) > * cvsadmin processes the scm-request: > - Create git repo > - Create package in pkgdb > * cvsadmin sets fedora-cvs flag to + > > We thought that a number of these steps could be automated. For example, > creating the git repos themselve could be automated using information from pkgdb. > > Our idea has been to port part of this procedure to pkgdb itself. > > This is our proposal: > overall, kudos for this proposal, it looks better than the current workflow. One question, when do we close the review ticket ? Currently, it is supposed to be handled by the reviewee after the first build but it is often forgotten. Off course, it's the responsability of the reviewer to check this but it's an impediment. Astute people use bodhi to automatically close the ticket when it's build on a branched release, but it's not possible on rawhide. >From what I understand, pkgdb2 would be able to link a package to its review, so it should be possible to automatically close the review ticket, am I right ? > New procedure > ============= > > * packager opens a review-request on bugzilla > * reviewer sets the fedora-review flag to ? > * reviewer does the review > * reviewer sets the fedora-review flag to + > * packager goes to pkgdb2 to request new package and specifies: > - package name > - package summary > - package branches > - link to review on bugzilla > => requests added to the scm admin queue > * cvsadmin checks the review (check reviewer is a packager¹) > * cvsadmin approves the creation of the package in pkgdb > => package creation broadcasted on fedmsg > * git adjusted automatically > > What are the main changes: > - More work for the packager that asks for the package to be created directly > in pkgdb instead of using the SCM request mechanism in bugzilla > - No more use of the fedora-cvs flag in bugzilla > - Simplied work for releng that just checks the review and approves/denies in > pkgdb > > > Similarly, for new-branch: > > Current new-branch procedure: > ============================= > > * packager find the original package review ticket / opens a new ticket > * packager make the change request and sets fedora-cvs flag to ? > * cvsadmin checks the request/package (check if user is a packager, check if > package exists in the RHEL for EPEL branch request) > * cvsadmin processes the scm-request: > - Adjust git repo > - Adjust package in pkgdb > * cvsadmin sets fedora-cvs flag to + > > New new-branch procedure: > ========================= > > * packager requests new branch in pkgdb (2 clicks) > => requests added to the scm admin queue > * cvsadmin checks the request/package (check if package exists in the RHEL for > EPEL branch request - check if the user is a packager done in pkgdb itself) > * cvsadmin approves the creation of the new branch in pkgdb > => branch creation broadcasted on fedmsg > * git adjusted automatically > *nods* Silly question, some of those cvsadmins checks could be automated too, at least, providing hints to the scm admins. Something like a script listening to fedmsg, doing these checks and then sending the results that could be consumed by pkgdb2 (maybe displaying them as flash messages ?) Best regards, H. > > Currently, we are working towards these workflows but of course they are not > set in stone and we would like to discuss them as early as possible to be sure > we're not going in a completely wrong direction. > > Thanks for your feedbacks, > > Pierre and Till > > > ¹ We should be able to automate the check if the reviewee/reviewer are > packagers or not. > _______________________________________________ > devel-announce mailing list > devel-announce@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel-announce > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
