Re: Future changes in the new package and new branch processes
On Mon, Sep 08, 2014 at 11:55:06AM +0200, Pierre-Yves Chibon wrote: On Mon, Sep 08, 2014 at 11:31:58AM +0200, Tomas Tomecek wrote: Quoting Pierre-Yves Chibon (2014-09-05 17:08:39) 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 How about taking this from specfile? (and therefore provide a tool for maintaining specfiles srpms for reviews) That would imply parsing the bugzilla ticket to find the spec file and then parse it again which itself implies knowing the bugzilla ticket number. I think it's just as easy to ask the user to do it. Note that we have an API endpoint to edit a package's information: https://admin.fedoraproject.org/pkgdb/api/#edit_a_package and a script to do it in pkgdb2: https://git.fedorahosted.org/cgit/pkgdb2.git/tree/utility/update_package_info.py In case you did not notice, know that the cron has been deployed and is now running for two weeks on a weekly basis. So pkgdb's information about packages is now up to date with the information contained in yum's meta-data fom the rawhide repo (yes that does mean that packages retired from repo or present only in epel aren't up to date atm). By curiousity: The first time we ran the script: 16638 packages checked 15723 packages updated Last week's run: 16690 packages checked 50 packages updated Piere -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
Quoting Pierre-Yves Chibon (2014-09-08 11:55:06)
On Mon, Sep 08, 2014 at 11:31:58AM +0200, Tomas Tomecek wrote:
Quoting Pierre-Yves Chibon (2014-09-05 17:08:39)
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
How about taking this from specfile? (and therefore provide a tool for
maintaining specfiles srpms for reviews)
That would imply parsing the bugzilla ticket to find the spec file and then
parse it again which itself implies knowing the bugzilla ticket number.
My point was mainly that if you are working on improving the process, there
should be automated as much stuff as possible.
I've read a topic by Mirek Suchy on fedora-devel today about hooking dist-git
with
copr and I think that review process could benefit out of it. Roughly, something
like this:
$ fedpkg new-package create-repo
Creating new dist-git repo with sample specfile.
$ ${EDITOR} *.spec
$ fedpkg copr new
Sets owner, project name, arches... and links the repo with copr project
together
$ fedpkg copr build --with-fedora-review
$ fedpkg new-package create-bugzilla
$ fedpkg new-package add-to-pkgdb
This is roughly from top of my head, but I think you'll get my point.
The new-package process would be so much easier (at least to me).
I think it's just as easy to ask the user to do it.
Note that we have an API endpoint to edit a package's information:
https://admin.fedoraproject.org/pkgdb/api/#edit_a_package
and a script to do it in pkgdb2:
https://git.fedorahosted.org/cgit/pkgdb2.git/tree/utility/update_package_info.py
(Although we still need to deploy this one in a cron job)
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Cheers,
Tomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
Quoting Christopher (2014-09-08 21:35:23) It'd be great if the fedpkg tool could do some of this. For example, fedpkg could create git repos locally, from a template and a few questions, for new packages, which could be pushed somewhere for review (usually GitHub, I'd imagine). It could even create the review bug automatically, as well as assist in the review process for the reviewer (setting the correct flags). Once approved and the package is created in pkgdb, git could be adjusted automatically from a clone of this original repo created by the fedpkg tool. This puts some burden on the reviewer to review not only the package, but also the use of the packaging process: ensure that the user created the git repo correctly. But, that might not be a bad thing. I was struck by how manual the new package process was, and how automated everything is later. It's a big gap that could be closed with more tools on the prepare for review side of things. I think this is excellent idea. (Mocked something already in response to Pierre) On the other hand, I think that webui process should be kept (just for sake of people who don't prefer CLI tools). Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: 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-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce Couldn't we finally rename cvs to scm? It's confusing for newcommers. Otherwise, process seems to be much better. I hope now it won't be possible that someone asks for new branch and make me a maintainer of branch, which I don't want to maintain. It was a bug in old process. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
Pierre-Yves Chibon pin...@pingoured.fr wrote: * packager creates the scm-request and set fedora-cvs flag to ? I find this step counter intuitive. I accidentally set it to '+' rather than '?' and then was confused about why things weren't progressing. Can it be split into two flags? On requesting git creation and one showing that git creation has been performed? David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
Quoting Pierre-Yves Chibon (2014-09-05 17:08:39) 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 How about taking this from specfile? (and therefore provide a tool for maintaining specfiles srpms for reviews) - 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 Tomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Mon, Sep 08, 2014 at 10:15:33AM +0100, David Howells wrote: Pierre-Yves Chibon pin...@pingoured.fr wrote: * packager creates the scm-request and set fedora-cvs flag to ? I find this step counter intuitive. I accidentally set it to '+' rather than '?' and then was confused about why things weren't progressing. Can it be split into two flags? On requesting git creation and one showing that git creation has been performed? Well there is already two flags: fedora-cvs = ? - Request git creation fedora-cvs = + - git creation performed But anyway, the idea is to drop this flag completely. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Mon, Sep 08, 2014 at 11:31:58AM +0200, Tomas Tomecek wrote: Quoting Pierre-Yves Chibon (2014-09-05 17:08:39) 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 How about taking this from specfile? (and therefore provide a tool for maintaining specfiles srpms for reviews) That would imply parsing the bugzilla ticket to find the spec file and then parse it again which itself implies knowing the bugzilla ticket number. I think it's just as easy to ask the user to do it. Note that we have an API endpoint to edit a package's information: https://admin.fedoraproject.org/pkgdb/api/#edit_a_package and a script to do it in pkgdb2: https://git.fedorahosted.org/cgit/pkgdb2.git/tree/utility/update_package_info.py (Although we still need to deploy this one in a cron job) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Sun, Sep 07, 2014 at 05:23:15AM +0200, Ralf Corsepius wrote: I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can My proposal is to point new branches to the first commit in the master branch in each repo. This is also what is done initially, when a new repo is set up. Empty branches, i.e. only the ACL but no commit in the branch might lead to maintainers accidentally creating the wrong branch. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On 09/08/2014 06:12 PM, Till Maas wrote: On Sun, Sep 07, 2014 at 05:23:15AM +0200, Ralf Corsepius wrote: I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can My proposal is to point new branches to the first commit in the master branch in each repo. I fail to understand the rationale for this. It doesn't make any sense to me. The pkgdb simply doesn't have any knowledge about what is right or wrong. Imagine you were going to branch a package for EPEL5. If you are going to populate it from master, the likelihood, this package will be incompatible to EPEL5 is almost 100%. This is also what is done initially, when a new repo is set up. Empty branches, i.e. only the ACL but no commit in the branch might lead to maintainers accidentally creating the wrong branch. I fail to understand once more. Empty branches are the status quo ever since Fedora is using git. I feel you are trying to introduce a solution to a non-problem, Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Mon, Sep 08, 2014 at 06:46:10PM +0200, Ralf Corsepius wrote: On 09/08/2014 06:12 PM, Till Maas wrote: This is also what is done initially, when a new repo is set up. Empty branches, i.e. only the ACL but no commit in the branch might lead to maintainers accidentally creating the wrong branch. I fail to understand once more. Empty branches are the status quo ever since Fedora is using git. I feel you are trying to introduce a solution to a non-problem, No, repos are setup with empty .gitignore and sources files, which is also the first commit in the master branch. So I guess you actually agree to me. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Mon, Sep 08, 2014 at 06:46:10PM +0200, Ralf Corsepius wrote: On 09/08/2014 06:12 PM, Till Maas wrote: On Sun, Sep 07, 2014 at 05:23:15AM +0200, Ralf Corsepius wrote: I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can My proposal is to point new branches to the first commit in the master branch in each repo. I fail to understand the rationale for this. It doesn't make any sense to me. The pkgdb simply doesn't have any knowledge about what is right or wrong. Imagine you were going to branch a package for EPEL5. If you are going to populate it from master, the likelihood, this package will be incompatible to EPEL5 is almost 100%. I think you mis-read or mis-understood Till's proposal. Basically Till is proposing that we point every new branch to the commit that created the git repo, for example for perl-MooX-Types-MooseLike-Numeric that you maintain it would be: http://pkgs.fedoraproject.org/cgit/perl-MooX-Types-MooseLike-Numeric.git/commit/?id=101a14a33 But looking through other repo, Till, it seems that older repo do not have this commit. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Mon, Sep 8, 2014 at 5:31 AM, Tomas Tomecek ttome...@redhat.com wrote: Quoting Pierre-Yves Chibon (2014-09-05 17:08:39) 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 How about taking this from specfile? (and therefore provide a tool for maintaining specfiles srpms for reviews) It'd be great if the fedpkg tool could do some of this. For example, fedpkg could create git repos locally, from a template and a few questions, for new packages, which could be pushed somewhere for review (usually GitHub, I'd imagine). It could even create the review bug automatically, as well as assist in the review process for the reviewer (setting the correct flags). Once approved and the package is created in pkgdb, git could be adjusted automatically from a clone of this original repo created by the fedpkg tool. This puts some burden on the reviewer to review not only the package, but also the use of the packaging process: ensure that the user created the git repo correctly. But, that might not be a bad thing. I was struck by how manual the new package process was, and how automated everything is later. It's a big gap that could be closed with more tools on the prepare for review side of things. - 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 Tomas Overall, I like the proposal, but I think it could be made simpler on new packagers (and reviewers) with better tooling (which I suppose could be considered out of scope for this proposal, but something to consider in future). -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On 09/06/2014 09:23 PM, Ralf Corsepius wrote: On 09/06/2014 03:09 PM, Pierre-Yves Chibon wrote: On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can be added to an older branch. E.g. a package may have a chain of dependencies, which can't be fullfilled because something else is missing on this older release and can't be upgraded to a compatible version. Agreed. And it is trivial to merge from wherever the packager feels most appropriate to. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 06:35:45PM +0200, Haïkel wrote: 2014-09-05 17:08 GMT+02:00 Pierre-Yves Chibon pin...@pingoured.fr: 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 ? We can go several ways there: a) let it the way it is now - Closed manualy - Closed via bodhi - Closed after a while when somone goes through his/her list of tickets and see that some can be closed b) let pkgdb close the ticket (once the package is created) c) let pkgdb close the ticket when the only branch requested is rawhide (once the package is created) Obviously, a) requires the less work, b) is easy but c) kind of make more sense as in theory it should be bodhi that closes the ticket (cf a)). 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 ?) Since the checks will be performed by cvsadmins, manually, I think it make more sense to do them when the admin runs the script rather than automatically based on a fedmsg. Integrated back from fedmsg to pkgdb this type of information might not be easiest thing for no clear advantage, I think. Thanks for the feedbacks and ideas, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 08:12:49PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Sep 05, 2014 at 05:08:39PM +0200, Pierre-Yves Chibon wrote: 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 ? Is this necessary? Normally having status=ASSIGNED is enough to know that the review is handling the review. One of the issues with current procedure is that this step can be forgotten, and then some automatic steps don't happen when the flag to +. (One that I noticed it that the email with subject 'fedora-review granted' is not sent.) Since you're simplifying the procedure, this manual step could be pruned too. That's a good question, but I don't know how many tools we have that relies on this flag and I suspect there are some. That's a question to bring to releng I guess. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: * 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) I guess, EPEL is just an example for a new branch to create? Indeed, it's just an example. We also have cases were packages only exists in newer Fedoras (eg. rawhide only), until someone comes along and asks for branches to be created in older Fedoras. We would have to clear it with releng, but I wonder what are the mandatory checks to perform when creating a new *fedora* branch for a package that has already been reviewed. If the only check is: is the person a packager?, then I guess we may be able to automatically create the fedora branch in pkgdb (which would then propagate the change to git). * cvsadmin approves the creation of the new branch in pkgdb = branch creation broadcasted on fedmsg * git adjusted automatically What does this sentence mean? Create an empty branch or even to populate it from some other branch? The script creating the git branches has a mapping of which branch to create a new branch from [1]. So new epel7 branches will be created from the f19 branch. I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? Pierre [1] http://infrastructure.fedoraproject.org/infra/ansible/roles/distgit/templates/pkgdb_sync_git_branches.py see BRANCHES_FROM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On 09/06/2014 03:09 PM, Pierre-Yves Chibon wrote: On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: * cvsadmin approves the creation of the new branch in pkgdb = branch creation broadcasted on fedmsg * git adjusted automatically What does this sentence mean? Create an empty branch or even to populate it from some other branch? The script creating the git branches has a mapping of which branch to create a new branch from [1]. So new epel7 branches will be created from the f19 branch. I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can be added to an older branch. E.g. a package may have a chain of dependencies, which can't be fullfilled because something else is missing on this older release and can't be upgraded to a compatible version. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Future changes in the new package and new branch processes
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-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
2014-09-05 17:08 GMT+02:00 Pierre-Yves Chibon pin...@pingoured.fr: 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-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 05:08:39PM +0200, Pierre-Yves Chibon wrote: 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 ? Is this necessary? Normally having status=ASSIGNED is enough to know that the review is handling the review. One of the issues with current procedure is that this step can be forgotten, and then some automatic steps don't happen when the flag to +. (One that I noticed it that the email with subject 'fedora-review granted' is not sent.) Since you're simplifying the procedure, this manual step could be pruned too. Zbyszek * 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-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: * 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) I guess, EPEL is just an example for a new branch to create? We also have cases were packages only exists in newer Fedoras (eg. rawhide only), until someone comes along and asks for branches to be created in older Fedoras. * cvsadmin approves the creation of the new branch in pkgdb = branch creation broadcasted on fedmsg * git adjusted automatically What does this sentence mean? Create an empty branch or even to populate it from some other branch? I don't think, the later is applicable, because e.g. rawhide packages often aren't applicable on older EPELs, while branches based on older versions are. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
