We're about ready to announce this list on fedora-devel-list and fedora-extras-list, but before we do we should write a mission statement. I personally intend on keeping list traffic low noise and high relevancy by enforcing strict moderation. Anything straying from the mission statement will have a single warning, then second infraction moderate bit set.
Some ideas for the mission statement:
* Agreement and documentation of perl packaging standards * Cleanup and maintenance of Core and Extras perl packages * Discussion of perl package development issues * Progressive packaging of CPAN toward Extras
Anything we're missing?
This week we need to figure out ways of better keeping the team informed about new bugs, triage and setting priorities, and tracking open issues.
I am thinking perhaps we should auto-CC all FC and FE perl* packages to a fedora-perl-bugs@redhat.com list, and anybody that wants to follow all perl reports subscribe to that list. This is easier to maintain than adding several people auto-CC to hundreds of packages in Bugzilla. Then we can set filters on that list so only the most important types of bug mail are sent there in order to keep relevancy higher.
I realize this isn't ideal, so very interested to hear your ideas of how we can better balance keeping informed with traffic volume.
Warren Togami wtogami@redhat.com
On Sun, 2005-04-17 at 21:08 -1000, Warren Togami wrote:
We're about ready to announce this list on fedora-devel-list and fedora-extras-list, but before we do we should write a mission statement. I personally intend on keeping list traffic low noise and high relevancy by enforcing strict moderation. Anything straying from the mission statement will have a single warning, then second infraction moderate bit set.
Some ideas for the mission statement:
- Agreement and documentation of perl packaging standards
- Cleanup and maintenance of Core and Extras perl packages
- Discussion of perl package development issues
- Progressive packaging of CPAN toward Extras
Anything we're missing?
Those all sound good. Also, we may want to define a policy for which Perl packages are allowed into Extras. (for example, do they have to be in CPAN first?)
This week we need to figure out ways of better keeping the team informed about new bugs, triage and setting priorities, and tracking open issues.
I am thinking perhaps we should auto-CC all FC and FE perl* packages to a fedora-perl-bugs@redhat.com list, and anybody that wants to follow all perl reports subscribe to that list. This is easier to maintain than adding several people auto-CC to hundreds of packages in Bugzilla. Then we can set filters on that list so only the most important types of bug mail are sent there in order to keep relevancy higher.
I realize this isn't ideal, so very interested to hear your ideas of how we can better balance keeping informed with traffic volume.
I just did a query and there 67 open bugs in perl* components of FC and FE. This doesn't seem like all that many to me. I like the idea of an auto-CC to fedora-perl-bugs@redhat.com. Additionally, I think it would be worthwhile to email this list when a new Perl component is added (or removed) from bugzilla.
Cheers -- Dennis
Dennis Gregorovic wrote:
On Sun, 2005-04-17 at 21:08 -1000, Warren Togami wrote:
We're about ready to announce this list on fedora-devel-list and fedora-extras-list, but before we do we should write a mission statement. I personally intend on keeping list traffic low noise and high relevancy by enforcing strict moderation. Anything straying from the mission statement will have a single warning, then second infraction moderate bit set.
Some ideas for the mission statement:
- Agreement and documentation of perl packaging standards
- Cleanup and maintenance of Core and Extras perl packages
- Discussion of perl package development issues
- Progressive packaging of CPAN toward Extras
Anything we're missing?
Those all sound good. Also, we may want to define a policy for which Perl packages are allowed into Extras. (for example, do they have to be in CPAN first?)
Specifics like that don't belong in the mission statement, but a more detailed document elsewhere that expands on the mission statement.
Another specific would be fixing RPM's perl dep finder to be smarter by default. Like never pull in Win32, never parse %doc or example(s) dirs, etc. That would eliminate the majority of cases where ugly manual Requires filtering is needed, but not all.
This week we need to figure out ways of better keeping the team informed about new bugs, triage and setting priorities, and tracking open issues.
I am thinking perhaps we should auto-CC all FC and FE perl* packages to a fedora-perl-bugs@redhat.com list, and anybody that wants to follow all perl reports subscribe to that list. This is easier to maintain than adding several people auto-CC to hundreds of packages in Bugzilla. Then we can set filters on that list so only the most important types of bug mail are sent there in order to keep relevancy higher.
I realize this isn't ideal, so very interested to hear your ideas of how we can better balance keeping informed with traffic volume.
I just did a query and there 67 open bugs in perl* components of FC and FE. This doesn't seem like all that many to me. I like the idea of an auto-CC to fedora-perl-bugs@redhat.com. Additionally, I think it would be worthwhile to email this list when a new Perl component is added (or removed) from bugzilla.
Good idea. I'll make the request for that mailing list. Time to launch probably Thursday or Friday.
Warren Togami wtogami@redhat.com
On Wed, 2005-04-20 at 14:01 -1000, Warren Togami wrote:
Dennis Gregorovic wrote:
On Sun, 2005-04-17 at 21:08 -1000, Warren Togami wrote:
We're about ready to announce this list on fedora-devel-list and fedora-extras-list, but before we do we should write a mission statement. I personally intend on keeping list traffic low noise and high relevancy by enforcing strict moderation. Anything straying from the mission statement will have a single warning, then second infraction moderate bit set.
Some ideas for the mission statement:
- Agreement and documentation of perl packaging standards
- Cleanup and maintenance of Core and Extras perl packages
- Discussion of perl package development issues
- Progressive packaging of CPAN toward Extras
Anything we're missing?
Those all sound good. Also, we may want to define a policy for which Perl packages are allowed into Extras. (for example, do they have to be in CPAN first?)
Specifics like that don't belong in the mission statement, but a more detailed document elsewhere that expands on the mission statement.
Another specific would be fixing RPM's perl dep finder to be smarter by default. Like never pull in Win32, never parse %doc or example(s) dirs, etc. That would eliminate the majority of cases where ugly manual Requires filtering is needed, but not all.
Agreed. I wasn't thinking clearly when making those comments.
[snip]
Warren Togami wrote:
I am thinking perhaps we should auto-CC all FC and FE perl* packages to a fedora-perl-bugs@redhat.com list, and anybody that wants to follow all perl reports subscribe to that list. This is easier to maintain than adding several people auto-CC to hundreds of packages in Bugzilla. Then we can set filters on that list so only the most important types of bug mail are sent there in order to keep relevancy higher.
I realize this isn't ideal, so very interested to hear your ideas of how we can better balance keeping informed with traffic volume.
I'm reconsidering the fedora-perl-bugs list idea for two reasons: 1) There is no way to post FC bugs with embargo and hide that traffic from the list. By default anybody subscribed there would see the security embargoed details and so would the list archive. 2) It is *annoying* to receive both bug mail directly, and a duplicate from a bug distribution list. Bugzilla has no way of knowing that you would receive it twice. Although this would be helped by filtering the list mail before bug mail...
OK only #1 is a real problem. That problem only makes this feasible if we have a way of creating hidden bugs without adding auto-CC. Current Bugzilla this is not possible.
The alternative to this list is to add the few perl team leaders auto-CC to all perl* FC packages. Those members would be privy to embargo details and expected to keep it private until the embargo lift date.
Or maybe this worry isn't too bad, because embargo on perl* really does not happen often? I have no clue...
Thoughts?
Warren Togami wtogami@redhat.com
perl-devel@lists.fedoraproject.org
-
Dennis Gregorovic -
Warren Togami