FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-25-2008, 06:11 AM
Toshio Kuratomi
 
Default Slight change in how cvs notifications work

We've had some issues with notification emails being sent on cvs
commits. Sometimes generating the list of email addresses to notify was
slow, on other occassions it would fail altogether. To alleviate this
we've changed from a dynamic determination of who is notified by
querying the pkgdb to a static one by sending to an email alias
generated from pkgdb information once an hour.


There is one major difference (besides speed) to note in this: Before,
the owner and people in the watchcommits acls received notifications
that a cvs commit was made to a package. Now the owner and people
onwatchcommits and watchbugzilla acls are notified.


The aliases used to send these messages are all
pkg-owner@fedoraproject.org in case you have mail filters you want to
setup to handle it.


Thank you,
-Toshio

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-25-2008, 06:44 PM
Michael Schwendt
 
Default Slight change in how cvs notifications work

On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote:

> There is one major difference (besides speed) to note in this: Before,
> the owner and people in the watchcommits acls received notifications
> that a cvs commit was made to a package. Now the owner and people
> onwatchcommits and watchbugzilla acls are notified.

So, the separate watchbugzilla now implies watchcommits? Why that change?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-25-2008, 08:43 PM
Toshio Kuratomi
 
Default Slight change in how cvs notifications work

Michael Schwendt wrote:

On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote:

There is one major difference (besides speed) to note in this: Before,
the owner and people in the watchcommits acls received notifications
that a cvs commit was made to a package. Now the owner and people
onwatchcommits and watchbugzilla acls are notified.


So, the separate watchbugzilla now implies watchcommits? Why that change?


Possibly oversight or possibly removing a wart. Here was my reasoning:

We have a lot of things that want to send notification when a change
occurs to a package. This includes:


bugzilla
pkgdb (acl changes)
cvs commits
bodhi
koji
various reports:
broken deps, broken upgrade, fails to rebuild, etc

When the packageDB started I wasn't envisioning all of those uses and
the list of notifications is only growing over time. So what should we
do? We can add more watch* acls to the db and the interface. Or we can
glom onto existing acls -- but if I want to get reports from bodhi, do I
need to sign up for watchcommits or watchbugzilla? Or does it depend on
the commit acl?


Looking at this problem I didn't see any difference between bugzilla,
cvs, and bodhi, or koji. So pruning the list of watch* acls with the
goal of consolidating on a single acl for notification seems to make sense.


OTOH, I haven't done any coding towards this in the core of pkgdb, just
made the new notifylist give out the list of usernames in owner,
watchcommit, watchbugzilla. If you could come up with criteria to use
to determine what makes a good watch* acl (or revamping the system even
further), we can make changes. With a list of what is suitable for
having its own watch* acl we could have multiple aliases that match up
with the acls that meet those criteria.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-26-2008, 07:55 AM
Michael Schwendt
 
Default Slight change in how cvs notifications work

On Fri, 25 Jul 2008 13:43:19 -0700, Toshio Kuratomi wrote:

> Michael Schwendt wrote:
> > On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote:
> >
> >> There is one major difference (besides speed) to note in this: Before,
> >> the owner and people in the watchcommits acls received notifications
> >> that a cvs commit was made to a package. Now the owner and people
> >> onwatchcommits and watchbugzilla acls are notified.
> >
> > So, the separate watchbugzilla now implies watchcommits? Why that change?
> >
> Possibly oversight or possibly removing a wart. Here was my reasoning:
>
> We have a lot of things that want to send notification when a change
> occurs to a package. This includes:
>
> bugzilla
> pkgdb (acl changes)
> cvs commits
> bodhi
> koji
> various reports:
> broken deps, broken upgrade, fails to rebuild, etc
>
> When the packageDB started I wasn't envisioning all of those uses and
> the list of notifications is only growing over time. So what should we
> do? We can add more watch* acls to the db and the interface. Or we can
> glom onto existing acls -- but if I want to get reports from bodhi, do I
> need to sign up for watchcommits or watchbugzilla? Or does it depend on
> the commit acl?

Comments in bodhi are similar to comments in bugzilla and ought to be
delivered via watchbugzilla. Not everyone who gives negative karma
also opens a ticket in bugzilla.

New update notifications in bodhi are more like a commit [to a repo]
and therefore should be posted to watchcommits. Helpful for collaboration.

Koji notifications tell whether a package built successfully, which
is like a commit to the repo, and ought to be forwarded to watchcommits.

OTOH, if someone requests watchbugzilla access only, receiving all cvs
commits is unexpected. Especially as long as the watchcommits acl is a
separate opt-in. It's not called "watchpkg" unless you plan to take
your consolidation into that direction.

> Looking at this problem I didn't see any difference between bugzilla,
> cvs, and bodhi, or koji. So pruning the list of watch* acls with the
> goal of consolidating on a single acl for notification seems to make sense.

Whether it makes sense depends on the original definition of the
several watch* options.

watchbugzilla as a fine-grained choice appeared helpful, because
bugzilla itself doesn't offer such a feature (monitoring other email
addresses increases the spam). watchbugzilla is different. It's like
"I depend on Foo, so I want to learn about bug reports regarding
Foo". Instead, you want to submit also all cvs commits, which quickly
increases the email traffic an observer has to process (minor updates,
cosmetical spec changes, commits with no immediate build). This gives
reason to worry. Maintainers are said to be flooded with bugzilla spam
already. With a change of the pkgdb watch* acls, co-maintainers could
not opt-out from some of the notifications (only with filtering on
their own).

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-26-2008, 05:38 PM
Toshio Kuratomi
 
Default Slight change in how cvs notifications work

Michael Schwendt wrote:

On Fri, 25 Jul 2008 13:43:19 -0700, Toshio Kuratomi wrote:


Michael Schwendt wrote:

On Thu, 24 Jul 2008 23:11:11 -0700, Toshio Kuratomi wrote:

There is one major difference (besides speed) to note in this: Before,
the owner and people in the watchcommits acls received notifications
that a cvs commit was made to a package. Now the owner and people
onwatchcommits and watchbugzilla acls are notified.

So, the separate watchbugzilla now implies watchcommits? Why that change?


Possibly oversight or possibly removing a wart. Here was my reasoning:

We have a lot of things that want to send notification when a change
occurs to a package. This includes:


bugzilla
pkgdb (acl changes)
cvs commits
bodhi
koji
various reports:
broken deps, broken upgrade, fails to rebuild, etc

When the packageDB started I wasn't envisioning all of those uses and
the list of notifications is only growing over time. So what should we
do? We can add more watch* acls to the db and the interface. Or we can
glom onto existing acls -- but if I want to get reports from bodhi, do I
need to sign up for watchcommits or watchbugzilla? Or does it depend on
the commit acl?


Comments in bodhi are similar to comments in bugzilla and ought to be
delivered via watchbugzilla. Not everyone who gives negative karma
also opens a ticket in bugzilla.

New update notifications in bodhi are more like a commit [to a repo]
and therefore should be posted to watchcommits. Helpful for collaboration.

The answer to: "What acl do I need to know what's going on with this
package's updates" becomes "watchcommits and watchbugzilla" which is
decidedly confusing.



Koji notifications tell whether a package built successfully, which
is like a commit to the repo, and ought to be forwarded to watchcommits.

OTOH, if someone requests watchbugzilla access only, receiving all cvs
commits is unexpected. Especially as long as the watchcommits acl is a
separate opt-in. It's not called "watchpkg" unless you plan to take
your consolidation into that direction.

So this is kinda the question I'm asking... do people here think taking
things in the direction of a single watchpkg makes sense? If so, that's
the next step in this... merging watchbugzilla and watchcommits into a
single watchpkg acl.


OTOH, if there is significant value in having separate notification acls
then I think we need to have separate acls for most everything. (A side
note: I don't think we can control koji, unfortunately. I think it uses
its own idea of pkg owners coupled with who submitted a build to send
out notification)


Looking at this problem I didn't see any difference between bugzilla,
cvs, and bodhi, or koji. So pruning the list of watch* acls with the
goal of consolidating on a single acl for notification seems to make sense.


Whether it makes sense depends on the original definition of the
several watch* options.

watchbugzilla as a fine-grained choice appeared helpful, because
bugzilla itself doesn't offer such a feature (monitoring other email
addresses increases the spam). watchbugzilla is different. It's like
"I depend on Foo, so I want to learn about bug reports regarding
Foo". Instead, you want to submit also all cvs commits, which quickly
increases the email traffic an observer has to process (minor updates,
cosmetical spec changes, commits with no immediate build). This gives
reason to worry. Maintainers are said to be flooded with bugzilla spam
already. With a change of the pkgdb watch* acls, co-maintainers could
not opt-out from some of the notifications (only with filtering on
their own).

This makes sense. Now, how do we make this general? For instance, if
we're worried about the level of bugzilla mail, adding bodhi comments to
the watchbugzilla acl becomes less attractive. Also the names don't
imply anything about what other things will be attached to the acl... we
should either rename the acl to encompass those things or split out
separate acls for them.


After we solve the criteria issue, we have to solve the UI issue:
making more acls makes the current UI more and more cluttered. I've
been thinking that we want to have a single button for most things. If
you're not yet a maintainer of the package you see this:


= Simple view =

Package: qa-assistant

_/*Fedora*\_Fedora_EPEL_\_Fedora_OLPC_\______

Active Releases: F-8 F-9 devel

Role:
(o) Just Watch Package
(_) Help Develop Package
(_) Full Co-Maintainership

[view advanced]

= Advanced View =

Package: qa-assistant

_/*Fedora*\_Fedora_EPEL_\_Fedora_OLPC_\______

_/*F-8*\_F-9_\_devel_\_________

Acls:
Req Apprv
[X] [X] watch commits
[X] [_] watch bugzilla
[X] [X] watch updates
[_] [_] Commit
[_] [_] Update
[_] [_] Approve Acl Requests

[simple view]

Maintainers would see something similar to the current view but they
will also have a simple approval queue (from the /users/ space) (Note,
this needs more work):


Approval Queue:

abadger requests
qa-assistant
[X] watch bugzilla
[X] commit
[X] update
[ ] approve acl requests

[Approve Request]
[Deny Request]
[...]

[Approve all Requests]

I've got to get together with a UI designer to work out whether I'm on
the right track but something like this will definitely be needed if we
keep adding acls.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-30-2008, 11:55 AM
Michael Schwendt
 
Default Slight change in how cvs notifications work

On Sat, 26 Jul 2008 10:38:11 -0700, Toshio Kuratomi wrote:

> (A side note: I don't think we can control koji, unfortunately. I think
> it uses its own idea of pkg owners coupled with who submitted a build to
> send out notification)

Which shows that the new %{name}-owner email addresses are insufficient.
In particular, koji would need to learn about package owners elsewhere
(the separate list in koji of which pkgs to monitor is not connected to
the pkgdb either).
Theoretically, koji *could* simply mail to those new -owner addresses in
addition to the person who requested a build (so all pkg co-maintainers
learn about the build job), but that doesn't take into account multiple
projects (such as olpc, epel) unless there will be more email
addresses. Like epel-%{name}-owner once epel pkgs will be built in koji.

> After we solve the criteria issue, we have to solve the UI issue:
> making more acls makes the current UI more and more cluttered. I've
> been thinking that we want to have a single button for most things.

This topic is an example of where bottom-up and top-down don't meet
eachother.

We want to support co-maintainership. We've got several pieces of
infrastructure (including web UIs), some of which don't communicate with
eachother [yet].

Simple co-maintenance: multiple persons get exactly the same privileges
with regard to a package in various places:
cvs : commit
pkgdb : give privileges (in "admin" role)
koji : permission to build pkg
bodhi : permission to release builds as updates
bz : either be the assignee or in Cc (and be able to modify tickets)
A simple way of communicating (besides irc or private mail) is to commit
messages to a README file in pkg cvs. All pkg co-owners receive the commit
diff via private mail. It's like a pinboard. It's not a substitute for a
mailing-list and not suitable for long discussions.

With that design of co-maintenance, however, it takes extra effort to
distribute work-load among the co-maintainers. One co-maintainer might
want to be the release master (and take care of issueing updates in
bodhi). Another one would focus on bug triaging. Even another two can't
handle the bz traffic and prefer spending time on actual assignments done
by the bug triager. And what about pkg-specific testers? Do they fit into
the scheme at all? Or does it need privately maintained email lists to
notify them of version upgrades or updates? One can easily see that
sending all sorts of notifications to all co-maintainers is suboptimal.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-30-2008, 01:49 PM
Jesse Keating
 
Default Slight change in how cvs notifications work

On Wed, 2008-07-30 at 13:55 +0200, Michael Schwendt wrote:
> Which shows that the new %{name}-owner email addresses are insufficient.
> In particular, koji would need to learn about package owners elsewhere
> (the separate list in koji of which pkgs to monitor is not connected to
> the pkgdb either).
> Theoretically, koji *could* simply mail to those new -owner addresses in
> addition to the person who requested a build (so all pkg co-maintainers
> learn about the build job), but that doesn't take into account multiple
> projects (such as olpc, epel) unless there will be more email
> addresses. Like epel-%{name}-owner once epel pkgs will be built in koji.

In the future, where we have a common message bus, things like koji and
cvs etc... will just drop messages on the bus, stating that some action
occurred, and perhaps who created the action. It would be up to a
messaging server to consume those messages and decide whom to email
about it.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-30-2008, 03:04 PM
Toshio Kuratomi
 
Default Slight change in how cvs notifications work

Michael Schwendt wrote:

On Sat, 26 Jul 2008 10:38:11 -0700, Toshio Kuratomi wrote:


(A side note: I don't think we can control koji, unfortunately. I think
it uses its own idea of pkg owners coupled with who submitted a build to
send out notification)


Which shows that the new %{name}-owner email addresses are insufficient.
In particular, koji would need to learn about package owners elsewhere
(the separate list in koji of which pkgs to monitor is not connected to
the pkgdb either).
Theoretically, koji *could* simply mail to those new -owner addresses in
addition to the person who requested a build (so all pkg co-maintainers
learn about the build job), but that doesn't take into account multiple
projects (such as olpc, epel) unless there will be more email
addresses. Like epel-%{name}-owner once epel pkgs will be built in koji.

Which is no better or worse than what we deal with now. (ie: the pkggdb
doesn't have build or watchbuild acls because koji lacks the former and
has its own idea about the latter). If someone wanted to build up a
notification sync process similar to what we do for bugzilla, we could
make this work. Patches would be cheerfully accepted for this.


After we solve the criteria issue, we have to solve the UI issue:
making more acls makes the current UI more and more cluttered. I've
been thinking that we want to have a single button for most things.


This topic is an example of where bottom-up and top-down don't meet
eachother.

We want to support co-maintainership. We've got several pieces of
infrastructure (including web UIs), some of which don't communicate with
eachother [yet].

Simple co-maintenance: multiple persons get exactly the same privileges
with regard to a package in various places:
cvs : commit
pkgdb : give privileges (in "admin" role)
koji : permission to build pkg
bodhi : permission to release builds as updates
bz : either be the assignee or in Cc (and be able to modify tickets)


I notice that you only have the active privileges listed here. The
passive privileges (being notified of changes in an area) need to be
available as well so that upstreams, users, and other people who are not
Fedora packagers can be aware of what's going on with packages.



A simple way of communicating (besides irc or private mail) is to commit
messages to a README file in pkg cvs. All pkg co-owners receive the commit
diff via private mail. It's like a pinboard. It's not a substitute for a
mailing-list and not suitable for long discussions.

With that design of co-maintenance, however, it takes extra effort to
distribute work-load among the co-maintainers. One co-maintainer might
want to be the release master (and take care of issueing updates in
bodhi). Another one would focus on bug triaging. Even another two can't
handle the bz traffic and prefer spending time on actual assignments done
by the bug triager. And what about pkg-specific testers? Do they fit into
the scheme at all? Or does it need privately maintained email lists to
notify them of version upgrades or updates? One can easily see that
sending all sorts of notifications to all co-maintainers is suboptimal.



I would love a better designed UI and better designed acls. So please,
give me a design to implement instead of merely criticising what's
there. Don't take me wrong, I love that you're criticising it because
it's horrible. But without a notion of what the better system looks
like we're never going to replace what we have.


-Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-30-2008, 04:37 PM
Michael Schwendt
 
Default Slight change in how cvs notifications work

On Wed, 30 Jul 2008 08:04:36 -0700, Toshio Kuratomi wrote:

> > Simple co-maintenance

> I notice that you only have the active privileges listed here.

Because it only described the much simplified model, which recent
consolidation seems to have as a goal.

> The
> passive privileges (being notified of changes in an area) need to be
> available as well so that upstreams, users, and other people who are not
> Fedora packagers can be aware of what's going on with packages.

That's the less simple design with fine-grained options for the various
types of notifications, so e.g. "watchbugzilla" and "watchcommits"
are distinct from eachother.

> I would love a better designed UI and better designed acls. So please,
> give me a design to implement instead of merely criticising what's
> there. Don't take me wrong, I love that you're criticising it because
> it's horrible. But without a notion of what the better system looks
> like we're never going to replace what we have.
>
> -Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi

I'm not talking UI design yet, as that can only follow backend feature
design.

Whether the user may need to mark checkboxes or move items from one
listbox to another and vice versa, is still unimportant. Imagine users in
bodhi could click a "monitor this package" icon and confirm subscription
with their credentials. Only if that's possible in the backend software,
you can start worrying about the UI. I can't either comment on UI
proposals like

> Acls:
> Req Apprv
> [X] [X] watch commits
> [X] [_] watch bugzilla
> [X] [X] watch updates

> Approval Queue:
>
> abadger requests
> qa-assistant
> [X] watch bugzilla

without any background on why pkg maintainers must approve such monitoring
requests at all. Bugzilla is world-readable except for tickets with
special flags (e.g. only visible to Fedora Contributors). Same for cvs,
unless mechanisms are in place which hide branches in embargo
situations. Approval of requests for access to non-public data (or
write-privileges) is something else, of course.

Jesse mentioned work on a "common message bus" and a "messaging server",
which is something in the area of the notification queueing server
proposed long ago, but more versatile.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 07-30-2008, 05:12 PM
Toshio Kuratomi
 
Default Slight change in how cvs notifications work

Michael Schwendt wrote:

On Wed, 30 Jul 2008 08:04:36 -0700, Toshio Kuratomi wrote:


Simple co-maintenance


I notice that you only have the active privileges listed here.


Because it only described the much simplified model, which recent
consolidation seems to have as a goal.

This doesn't answer my question of whether you and others want
consolidation or not, though. And it doesn't tell me what to do with
the notification acls which are more problematic than the acls for
things that actually allow you to do things.


The
passive privileges (being notified of changes in an area) need to be
available as well so that upstreams, users, and other people who are not
Fedora packagers can be aware of what's going on with packages.


That's the less simple design with fine-grained options for the various
types of notifications, so e.g. "watchbugzilla" and "watchcommits"
are distinct from eachother.

Not entirely. There must always be at least one notification acl. If
you like consolidation, then you have to list at least that one acl. If
you dislike notification, then you should propose something with an
expanded list of notification acls.


I would love a better designed UI and better designed acls. So please,
give me a design to implement instead of merely criticising what's
there. Don't take me wrong, I love that you're criticising it because
it's horrible. But without a notion of what the better system looks
like we're never going to replace what we have.


-Toshio "I posted my strawman of a new UI, now how 'bout you?" Kuratomi


I'm not talking UI design yet, as that can only follow backend feature
design.

Sure. But backend feature design is driven by what the user wants in
the front end. I can implement either a single backend acl or multiple.
But it makes little sense for me to continue adding backend
notification acls if you don't want to see them in the front-end. And
it makes it impossible for us to have multiple front-end acls if I code
a single backend acl. If you give me UI, then I can code the backend to
enable it. If you give me criteria for when to add new notification
acls, I can code the backend to have acls that meet those criteria.



Whether the user may need to mark checkboxes or move items from one
listbox to another and vice versa, is still unimportant. Imagine users in
bodhi could click a "monitor this package" icon and confirm subscription
with their credentials. Only if that's possible in the backend software,
you can start worrying about the UI. I can't either comment on UI
proposals like

Your example is too simple. Whether there's one notification acl or
five, it is still possible to have a "monitor this package" icon in
bodhi. The question is what you want such an icon to do. Monitor all
notifications to the package? Monitor only changes in bodhi? Monitor
only comments on that particular build? this is what I need to know in
order to build a backend that supports it.



Acls:
Req Apprv
[X] [X] watch commits
[X] [_] watch bugzilla
[X] [X] watch updates



Approval Queue:

abadger requests
qa-assistant
[X] watch bugzilla


without any background on why pkg maintainers must approve such monitoring
requests at all. Bugzilla is world-readable except for tickets with
special flags (e.g. only visible to Fedora Contributors). Same for cvs,
unless mechanisms are in place which hide branches in embargo
situations. Approval of requests for access to non-public data (or
write-privileges) is something else, of course.

Well, I can't work on the backend without knowing what people actually
want to be able to do. Tell me that and I can change the pkgdb to
accommodate it or put it on the wishlist for when we have a message bus
and notification service.


(Re: approving watchbugzilla: I asked a while ago to make watchbugzilla
and watchcommits auto-approved but hadess objected because bugzilla can
be used to file tickets that are under embargo, for instance, security
related. Therefore, the desire was to manually approve who was able to
join this. watchcommits, OTOH, goes to a public mailing list already
so I don't see any point in continuing to manually approve that.)




Jesse mentioned work on a "common message bus" and a "messaging server",
which is something in the area of the notification queueing server
proposed long ago, but more versatile.

Yep. I was excited whe Jesse first mentioned this at FUDCon and then
asked for a server to work up a proof of concept on as it addresses that
need very well. It still needs to have a way to associate the user with
the notifications they're interested in, though, so there still needs to
be a backend store somewhere.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 07:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org