Future changes in the new package and new branch processes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:

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


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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux