9:35 a.m.
Good morning everyone,
Couple of weeks back we started the discussion around the procedures to include
new packages or request new branches for an existing packages [ticket, 1].
The ticket that started this whole discussion is:
At the meeting [2] we started to browse multiple scenario of procedure we could
have around these processes.
In order to kick-off the discussion further, I have tried to summarize below the
procedure as it is nowadays and the two different procedures we came up with
during the meeting.
So here it is :)
Cheers,
Pierre
[1] https://fedorahosted.org/rel-eng/ticket/5931
[2]
http://meetbot.fedoraproject.org/meetbot/fedora-meeting-1/2014-06-30/rele...
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)
* cvsadmin processes the scm-request:
- Create git repo
- Create package in pkgdb
* cvsadmin sets fedora-cvs flag to +
New procedure (1)
=================
* 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
- precises package name
- precises package summary
- precises package branches
- precises 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 is broadcasted on fedmsg
* git adjusted automatically
¹ we could check this automatically by checking which comment mentions 'approved'
and checking who set the fedora-review flag to +
New procedure (2) - Relies on fedmsg/bugzilla integration
=================
* 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 +
* automatically set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packager)
* cvsadmin sets the fedora-cvs flag to +
* flag change is broadcasted onto fedmsg
* pkgdb automatically creates the package (w/ name and summary provided in the
review)
* packager goes to pkgdb2 to request new branches
* requests added to the scm admin queue
* cvsadmin approves the creation of the branches in pkgdb
* branch creation is broadcasted on fedmsg
* git adjusted automatically
10:01 a.m.
On Tue, Jul 15, 2014 at 04:35:04PM +0200, Pierre-Yves Chibon wrote:
Good morning everyone,
Couple of weeks back we started the discussion around the procedures to include
new packages or request new branches for an existing packages [ticket, 1].
The ticket that started this whole discussion is:
At the meeting [2] we started to browse multiple scenario of procedure we could
have around these processes.
In order to kick-off the discussion further, I have tried to summarize below the
procedure as it is nowadays and the two different procedures we came up with
during the meeting.
So here it is :)
Cheers,
Pierre
[1] https://fedorahosted.org/rel-eng/ticket/5931
[2]
http://meetbot.fedoraproject.org/meetbot/fedora-meeting-1/2014-06-30/rele...
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)
* cvsadmin processes the scm-request:
- Create git repo
- Create package in pkgdb
* cvsadmin sets fedora-cvs flag to +
New procedure (1)
=================
* 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
- precises package name
- precises package summary
- precises package branches
- precises link to review on bugzilla
s/precises/specifies/g
Bloody French people :)
* 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 is broadcasted on fedmsg
* git adjusted automatically
¹ we could check this automatically by checking which comment mentions
'approved'
and checking who set the fedora-review flag to +
New procedure (2) - Relies on fedmsg/bugzilla integration
=================
* 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 +
* automatically set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packager)
* cvsadmin sets the fedora-cvs flag to +
* flag change is broadcasted onto fedmsg
* pkgdb automatically creates the package (w/ name and summary provided in the
review)
* packager goes to pkgdb2 to request new branches
* requests added to the scm admin queue
* cvsadmin approves the creation of the branches in pkgdb
* branch creation is broadcasted on fedmsg
* git adjusted automatically
_______________________________________________
rel-eng mailing list
rel-eng(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/rel-eng
10:04 a.m.
2014-07-15 16:35 GMT+02:00 Pierre-Yves Chibon <pingou(a)pingoured.fr>:
Good morning everyone,
Couple of weeks back we started the discussion around the procedures to
include
new packages or request new branches for an existing packages [ticket, 1].
The ticket that started this whole discussion is:
At the meeting [2] we started to browse multiple scenario of procedure we
could
have around these processes.
In order to kick-off the discussion further, I have tried to summarize
below the
procedure as it is nowadays and the two different procedures we came up
with
during the meeting.
So here it is :)
Cheers,
Pierre
[1] https://fedorahosted.org/rel-eng/ticket/5931
[2]
http://meetbot.fedoraproject.org/meetbot/fedora-meeting-1/2014-06-30/rele...
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)
* cvsadmin processes the scm-request:
- Create git repo
- Create package in pkgdb
* cvsadmin sets fedora-cvs flag to +
New procedure (1)
=================
* 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
- precises package name
- precises package summary
- precises package branches
- precises 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 is broadcasted on fedmsg
* git adjusted automatically
¹ we could check this automatically by checking which comment mentions
'approved'
and checking who set the fedora-review flag to +
New procedure (2) - Relies on fedmsg/bugzilla integration
=================
* 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 +
* automatically set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packager)
* cvsadmin sets the fedora-cvs flag to +
* flag change is broadcasted onto fedmsg
* pkgdb automatically creates the package (w/ name and summary provided in
the
review)
How does pkgdb know the fas name of the packager? By the email of the
reporter?
Maybe pkgdb2 could wait for the packager to approve the automatically
filled values and then could kick off, when the packager confirms?
This could then be merged with the next item below
* packager goes to pkgdb2 to request new branches
Why is there a second check of an cvsadmin needed, when a new branch is
created by the "Main Contact" of the new package?
Shouldn't it be enough, to check above, if the review was sane with setting
fedora-cvs to +?
Another possibility would be to remove anything from above with
"fedora-cvs" and only one check of an cvsadmin below would be required.
* requests added to the scm admin queue
* cvsadmin approves the creation of the branches in pkgdb
* branch creation is broadcasted on fedmsg
* git adjusted automatically
Greetings,
Tom
10:16 a.m.
On Tue, Jul 15, 2014 at 05:04:26PM +0200, Thomas Spura wrote:
2014-07-15 16:35 GMT+02:00 Pierre-Yves Chibon
<pingou(a)pingoured.fr>:
New procedure (1)
=================
* 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
A - precises package name
A - precises package summary
A - precises package branches
A - precises link to review on bugzilla
* requests added to the scm admin queue
* cvsadmin checks the review (check reviewer is a packagerA^1)
* cvsadmin approves the creation of the package in pkgdb
* package creation is broadcasted on fedmsg
* git adjusted automatically
A^1 we could check this automatically by checking which comment mentions
'approved'
and checking who set the fedora-review flag to +
New procedure (2) A - Relies on fedmsg/bugzilla integration
=================
* 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 +
* automatically set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packager)
* cvsadmin sets the fedora-cvs flag to +
* flag change is broadcasted onto fedmsg
* pkgdb automatically creates the package (w/ name and summary provided
in the
A review)
How does pkgdb know the fas name of the packager? By the email of the
reporter?
The email would be the way indeed. We do require packager to have the same email
in FAS and bugzilla and the admins get an hourly message when someone doesn't.
Maybe pkgdb2 could wait for the packager to approve the
automatically
filled values and then could kick off, when the packager confirms?
The idea is that summary will be updated via a cron taking the info from yum
anyway, so, if there was a typo in the summary, fixing it in the spec file will
fix it in pkgdb.
This could then be merged with the next item below
A
* packager goes to pkgdb2 to request new branches
Merging validating name/summary with requesting new branches is possible, but it
will make things a little more complex as my idea is that this part of the
process would/could be used when requesting additional branches on an existing
package.
Why is there a second check of an cvsadmin needed, when a new
branch is
created by the "Main Contact" of the new package?
That is the same check as the one we do already when requesting new branches
Shouldn't it be enough, to check above, if the review was sane
with
setting fedora-cvs to +?
Another possibility would be to remove anything from above with
"fedora-cvs" and only one check of an cvsadmin below would be required.
One advantage of keeping fedora-cvs is that it gives us the flexibility when/if
we miss or fedmsg drops a message.
But, we could consider it as well, I just seems to remember that Dennis wanted
to keep it in at the meeting.
* requests added to the scm admin queue
* cvsadmin approves the creation of the branches in pkgdb
* branch creation is broadcasted on fedmsg
* git adjusted automatically
Pierre
11:36 a.m.
2014-07-15 17:16 GMT+02:00 Pierre-Yves Chibon <pingou(a)pingoured.fr>:
On Tue, Jul 15, 2014 at 05:04:26PM +0200, Thomas Spura wrote:
> 2014-07-15 16:35 GMT+02:00 Pierre-Yves Chibon <pingou(a)pingoured.fr>:
>
> New procedure (1)
> =================
>
> * 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
> A - precises package name
> A - precises package summary
> A - precises package branches
> A - precises link to review on bugzilla
> * requests added to the scm admin queue
> * cvsadmin checks the review (check reviewer is a packagerA^1)
> * cvsadmin approves the creation of the package in pkgdb
> * package creation is broadcasted on fedmsg
> * git adjusted automatically
>
> A^1 we could check this automatically by checking which comment
mentions
> 'approved'
> and checking who set the fedora-review flag to +
>
> New procedure (2) A - Relies on fedmsg/bugzilla integration
> =================
>
> * 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 +
> * automatically set fedora-cvs flag to ?
> * cvsadmin checks the review (check reviewer is a packager)
> * cvsadmin sets the fedora-cvs flag to +
> * flag change is broadcasted onto fedmsg
> * pkgdb automatically creates the package (w/ name and summary
provided
> in the
> A review)
>
> How does pkgdb know the fas name of the packager? By the email of the
> reporter?
The email would be the way indeed. We do require packager to have the same
email
in FAS and bugzilla and the admins get an hourly message when someone
doesn't.
There have been (many?) cases, where the reporter didn't want to finish the
review process and another one took over the review request in the same
bug. So I wouldn't rely on this check as there are chances where the
reviewer doesn't insisted on opening a new review request in such a case...
Or would it be possible to check all comments for SRPM/SPEC urls, so that
all have been posted by the bug reporter?
> Maybe pkgdb2 could wait for the packager to approve the automatically
> filled values and then could kick off, when the packager confirms?
The idea is that summary will be updated via a cron taking the info from
yum
anyway, so, if there was a typo in the summary, fixing it in the spec file
will
fix it in pkgdb.
> This could then be merged with the next item below
> A
>
> * packager goes to pkgdb2 to request new branches
Merging validating name/summary with requesting new branches is possible,
but it
will make things a little more complex as my idea is that this part of the
process would/could be used when requesting additional branches on an
existing
package.
> Why is there a second check of an cvsadmin needed, when a new branch
is
> created by the "Main Contact" of the new package?
That is the same check as the one we do already when requesting new
branches
Which should happen automatically by the process script of the cvsadmin,
isn't it?
If it is automatically there, it could also be done fully automatically
without this second check by a cvsadmin.
> Shouldn't it be enough, to check above, if the review was sane with
> setting fedora-cvs to +?
>
> Another possibility would be to remove anything from above with
> "fedora-cvs" and only one check of an cvsadmin below would be
required.
One advantage of keeping fedora-cvs is that it gives us the flexibility
when/if
we miss or fedmsg drops a message.
But, we could consider it as well, I just seems to remember that Dennis
wanted
to keep it in at the meeting.
>
> * requests added to the scm admin queue
> * cvsadmin approves the creation of the branches in pkgdb
> * branch creation is broadcasted on fedmsg
> * git adjusted automatically
Pierre
Tom
12:02 p.m.
On Tue, Jul 15, 2014 at 06:36:05PM +0200, Thomas Spura wrote:
2014-07-15 17:16 GMT+02:00 Pierre-Yves Chibon
<pingou(a)pingoured.fr>:
On Tue, Jul 15, 2014 at 05:04:26PM +0200, Thomas Spura wrote:
> A A 2014-07-15 16:35 GMT+02:00 Pierre-Yves Chibon
<pingou(a)pingoured.fr>:
>
> A A A New procedure (1)
> A A A =================
>
> A A A * packager opens a review-request on bugzilla
> A A A * reviewer sets the fedora-review flag to ?
> A A A * reviewer does the review
> A A A * reviewer sets the fedora-review flag to +
> A A A * packager goes to pkgdb2 to request new package
> A A A A A - precises package name
> A A A A A - precises package summary
> A A A A A - precises package branches
> A A A A A - precises link to review on bugzilla
> A A A * requests added to the scm admin queue
> A A A * cvsadmin checks the review (check reviewer is a packagerA^1)
> A A A * cvsadmin approves the creation of the package in pkgdb
> A A A * package creation is broadcasted on fedmsg
> A A A * git adjusted automatically
>
> A A A A^1 we could check this automatically by checking which
comment mentions
> A A A 'approved'
> A A A and checking who set the fedora-review flag to +
>
> A A A New procedure (2) A - Relies on fedmsg/bugzilla integration
> A A A =================
>
> A A A * packager opens a review-request on bugzilla
> A A A * reviewer sets the fedora-review flag to ?
> A A A * reviewer does the review
> A A A * reviewer sets the fedora-review flag to +
> A A A * automatically set fedora-cvs flag to ?
> A A A * cvsadmin checks the review (check reviewer is a packager)
> A A A * cvsadmin sets the fedora-cvs flag to +
> A A A * flag change is broadcasted onto fedmsg
> A A A * pkgdb automatically creates the package (w/ name and summary
provided
> A A A in the
> A A A A A review)
>
> A A How does pkgdb know the fas name of the packager? By the email of
the
> A A reporter?
The email would be the way indeed. We do require packager to have the
same email
in FAS and bugzilla and the admins get an hourly message when someone
doesn't.
There have been (many?) cases, where the reporter didn't want to finish
the review process and another one took over the review request in the
same bug. So I wouldn't rely on this check as there are chances where the
reviewer doesn't insisted on opening a new review request in such a
case...
Or would it be possible to check all comments for SRPM/SPEC urls, so that
all have been posted by the bug reporter?
That is a valid point and a nice argument to keep the fedora-cvs flag in :)
Packager is whoever update fedora-cvs to '?'
> A A Maybe pkgdb2 could wait for the packager to approve
the
automatically
> A A filled values and then could kick off, when the packager
confirms?
The idea is that summary will be updated via a cron taking the info from
yum
anyway, so, if there was a typo in the summary, fixing it in the spec
file will
fix it in pkgdb.
> A A This could then be merged with the next item below
> A A A
>
> A A A * packager goes to pkgdb2 to request new branches
Merging validating name/summary with requesting new branches is
possible, but it
will make things a little more complex as my idea is that this part of
the
process would/could be used when requesting additional branches on an
existing
package.
> A A Why is there a second check of an cvsadmin needed, when a new
branch is
> A A created by the "Main Contact" of the new package?
That is the same check as the one we do already when requesting new
branches
Which should happen automatically by the process script of the cvsadmin,
isn't it?
If it is automatically there, it could also be done fully automatically
without this second check by a cvsadmin.
I will let the cvs admins speak up here, but I'm not entirely sure it's fully
automatic.
> A A Shouldn't it be enough, to check above, if the review was sane
with
> A A setting fedora-cvs to +?
>
> A A Another possibility would be to remove anything from above with
> A A "fedora-cvs" and only one check of an cvsadmin below would be
required.
One advantage of keeping fedora-cvs is that it gives us the flexibility
when/if
we miss or fedmsg drops a message.
But, we could consider it as well, I just seems to remember that Dennis
wanted
to keep it in at the meeting.
>
> A A A * requests added to the scm admin queue
> A A A * cvsadmin approves the creation of the branches in pkgdb
> A A A * branch creation is broadcasted on fedmsg
> A A A * git adjusted automatically
Pierre
Tom
8:59 p.m.
On Tue, 15 Jul 2014 16:35:04 +0200
Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
Good morning everyone,
Couple of weeks back we started the discussion around the procedures
to include new packages or request new branches for an existing
packages [ticket, 1].
The ticket that started this whole discussion is:
At the meeting [2] we started to browse multiple scenario of
procedure we could have around these processes.
In order to kick-off the discussion further, I have tried to
summarize below the procedure as it is nowadays and the two different
procedures we came up with during the meeting.
So here it is :)
Cheers,
Pierre
[1] https://fedorahosted.org/rel-eng/ticket/5931
[2]
http://meetbot.fedoraproject.org/meetbot/fedora-meeting-1/2014-06-30/rele...
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)
* cvsadmin processes the scm-request:
- Create git repo
- Create package in pkgdb
* cvsadmin sets fedora-cvs flag to +
New procedure (1)
=================
* 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
- precises package name
- precises package summary
- precises package branches
- precises 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 is broadcasted on fedmsg
* git adjusted automatically
¹ we could check this automatically by checking which comment
mentions 'approved' and checking who set the fedora-review flag to +
Doing
everything automatically that we can should be done. another
area that needs automating is making sure epel requests are not in
RHEL proper, ideally a way to detect when a package is added to rhel
so we can automatically remove from EPEL
New procedure (2) - Relies on fedmsg/bugzilla integration
=================
* 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 +
* automatically set fedora-cvs flag to ?
* cvsadmin checks the review (check reviewer is a packager)
* cvsadmin sets the fedora-cvs flag to +
* flag change is broadcasted onto fedmsg
* pkgdb automatically creates the package (w/ name and summary
provided in the review)
* packager goes to pkgdb2 to request new branches
* requests added to the scm admin queue
* cvsadmin approves the creation of the branches in pkgdb
* branch creation is broadcasted on fedmsg
* git adjusted automatically
I do not like the idea of a package automatically being added to pkgdb
to me this is a non starter. if we were to do it this way then we would
paste the request in bugzilla as we do today and pkgdb would need to
parse the request.
Dennis
9:15 p.m.
On Tue, 15 Jul 2014 19:02:35 +0200
Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Tue, Jul 15, 2014 at 06:36:05PM +0200, Thomas Spura wrote:
> 2014-07-15 17:16 GMT+02:00 Pierre-Yves Chibon
> <pingou(a)pingoured.fr>:
>
> On Tue, Jul 15, 2014 at 05:04:26PM +0200, Thomas Spura wrote:
> > A A 2014-07-15 16:35 GMT+02:00 Pierre-Yves Chibon
> <pingou(a)pingoured.fr>:
> >
> > A A A New procedure (1)
> > A A A =================
> >
> > A A A * packager opens a review-request on bugzilla
> > A A A * reviewer sets the fedora-review flag to ?
> > A A A * reviewer does the review
> > A A A * reviewer sets the fedora-review flag to +
> > A A A * packager goes to pkgdb2 to request new package
> > A A A A A - precises package name
> > A A A A A - precises package summary
> > A A A A A - precises package branches
> > A A A A A - precises link to review on bugzilla
> > A A A * requests added to the scm admin queue
> > A A A * cvsadmin checks the review (check reviewer is a
> > packagerA^1) A A A * cvsadmin approves the creation of the
> > package in pkgdb A A A * package creation is broadcasted
> > on fedmsg A A A * git adjusted automatically
> >
> > A A A A^1 we could check this automatically by checking
> > which
> comment mentions
> > A A A 'approved'
> > A A A and checking who set the fedora-review flag to +
> >
> > A A A New procedure (2) A - Relies on fedmsg/bugzilla
> > integration A A A =================
> >
> > A A A * packager opens a review-request on bugzilla
> > A A A * reviewer sets the fedora-review flag to ?
> > A A A * reviewer does the review
> > A A A * reviewer sets the fedora-review flag to +
> > A A A * automatically set fedora-cvs flag to ?
> > A A A * cvsadmin checks the review (check reviewer is a
> > packager) A A A * cvsadmin sets the fedora-cvs flag to +
> > A A A * flag change is broadcasted onto fedmsg
> > A A A * pkgdb automatically creates the package (w/ name
> > and summary
> provided
> > A A A in the
> > A A A A A review)
> >
> > A A How does pkgdb know the fas name of the packager? By
> > the email of
> the
> > A A reporter?
>
> The email would be the way indeed. We do require packager to
> have the same email
> in FAS and bugzilla and the admins get an hourly message when
> someone doesn't.
>
> There have been (many?) cases, where the reporter didn't want to
> finish the review process and another one took over the review
> request in the same bug. So I wouldn't rely on this check as there
> are chances where the reviewer doesn't insisted on opening a new
> review request in such a case...
> Or would it be possible to check all comments for SRPM/SPEC
> urls, so that all have been posted by the bug reporter?
That is a valid point and a nice argument to keep the fedora-cvs flag
in :)
Packager is whoever update fedora-cvs to '?'
> > A A Maybe pkgdb2 could wait for the packager to approve the
> automatically
> > A A filled values and then could kick off, when the packager
> confirms?
>
> The idea is that summary will be updated via a cron taking the
> info from yum
> anyway, so, if there was a typo in the summary, fixing it in
> the spec file will
> fix it in pkgdb.
>
> > A A This could then be merged with the next item below
> > A A A
> >
> > A A A * packager goes to pkgdb2 to request new branches
>
> Merging validating name/summary with requesting new branches is
> possible, but it
> will make things a little more complex as my idea is that this
> part of the
> process would/could be used when requesting additional
> branches on an existing
> package.
> > A A Why is there a second check of an cvsadmin needed, when
> > a new
> branch is
> > A A created by the "Main Contact" of the new package?
>
> That is the same check as the one we do already when
> requesting new branches
new branches
> Which should happen automatically by the process script of
the
> cvsadmin, isn't it?
> If it is automatically there, it could also be done fully
> automatically without this second check by a cvsadmin.
I will let the cvs admins speak up here, but I'm not entirely sure
it's fully automatic.
cvsadmins manually verify that the branches are requested
by a current
maintainer and that people are not trying to sneak themselves onto the
acls, though the checks could and should all be automated. In theory
epel branches we make sure the package is not in rhel already
>
> > A A Shouldn't it be enough, to check above, if the review
> > was sane
> with
> > A A setting fedora-cvs to +?
> >
> > A A Another possibility would be to remove anything from
> > above with A A "fedora-cvs" and only one check of an
> > cvsadmin below would be
> required.
>
> One advantage of keeping fedora-cvs is that it gives us the
> flexibility when/if
> we miss or fedmsg drops a message.
> But, we could consider it as well, I just seems to remember
> that Dennis wanted
i think its nice as it gives one place to go to see all the
package
info. but i can see doing without it also. if we moved reviews out of
bugzilla into their own app then it opens up all sorts of change in
processes.
> to keep it in at the meeting.
> >
> > A A A * requests added to the scm admin queue
> > A A A * cvsadmin approves the creation of the branches in
> > pkgdb A A A * branch creation is broadcasted on fedmsg
> > A A A * git adjusted automatically
>
> Pierre
>
> Tom
_______________________________________________
rel-eng mailing list
rel-eng(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/rel-eng
12:01 p.m.
On Tue, Jul 15, 2014 at 04:35:04PM +0200, Pierre-Yves Chibon wrote:
Good morning everyone,
Couple of weeks back we started the discussion around the procedures to include
new packages or request new branches for an existing packages [ticket, 1].
Refs:
[1] https://fedorahosted.org/rel-eng/ticket/5931
[2]
http://meetbot.fedoraproject.org/meetbot/fedora-meeting-1/2014-06-30/rele...
[3]
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-07-21/releng.2014-...
Today at the meeting [3 above] we discussed a little more about the procedure we
could do for new package and new branch.
Turns out, procedure #1 can basically be already started
New procedure (1)
=================
1) packager opens a review-request on bugzilla
2) reviewer sets the fedora-review flag to ?
3) reviewer does the review
4) reviewer sets the fedora-review flag to +
5) packager goes to pkgdb2 to request new package
- precises package name
- precises package summary
- precises package branches
- precises link to review on bugzilla
6) requests added to the scm admin queue
7) cvsadmin checks the review (check reviewer is a packager¹)
8) cvsadmin approves the creation of the package in pkgdb
9) package creation is broadcasted on fedmsg
10) git adjusted automatically
Step 7 here could be automated for some parts (check the reviewer is a packager
for example).
This procedure could be revised a little bit when the bugzilla/fedmsg
integration goes live:
New procedure (1.5)
=================
1) packager opens a review-request on bugzilla
2) reviewer sets the fedora-review flag to ?
3) reviewer does the review
4) reviewer sets the fedora-review flag to +
5) fedmsg broadcast automatically the flag change
6) the new package request is automatically created from the information in the
review (the hardest part being to find out which branch are of interest,
maybe ask them upon review creation?)
6) requests added to the scm admin queue
7) cvsadmin checks the review (check reviewer is a packager)
8) cvsadmin approves the creation of the package in pkgdb
9) package creation is broadcasted on fedmsg
10) git adjusted automatically
So if everyone is ok with this, I think the best is to start with procedure #1
and move onto procedure #1.5 when bugzilla and fedmsg are integrated
Thoughts?
Pierre
3588
days inactive
3594
days old
rel-eng@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Dennis Gilmore -
Pierre-Yves Chibon -
Thomas Spura