Draft Proposal: Spin Submission and Approval Process

Jeff Spaleta jspaleta at gmail.com
Thu Mar 6 19:49:54 UTC 2008


On Thu, Mar 6, 2008 at 1:51 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
>  I haven't ever got patches but if it does happen, some email address is
>  preferable.

How do you plan to expose your email address in the spins you
maintain?  I really don't think you want to do that... and yet.. we
have to expose a communication medium for feedback with regard to spin
issues (especially doing pre-release testing when kickstart logic
might need to be adjusted).    And do you expect to always be the sole
maintainer for all the spins ks files you currently maintain?  What
happens if unexpectedly need to stop working on these spins and other
people need to step in as maintainer in the run up to F10? Can you be
sure that you will forward the personal emails you got to the next
maintainer?  A personal email address doesn't scale in a
collaboration.  I really don't see a compelling reason to have spin
kickstart files be treated differently in terms of how we drive
feedback if we a preparing a process where you as an individual are
not the primary maintainer of a majority of contributed spins. We are
trying to prepare for that sort of future with regards to spin
development right?

>  What I would prefer not to do is getting bugs filed against the spin when it
>  should have been filed against individual packages. I am not sure how
>  exactly to accomplish that.

If you expose an email address instead of a bug component, you'll get
misfiled feedback in your email instead of bugzilla.  Misfiled
information will happen regardless of the communication medium you
choose to expose for feedback.  At least with bugzilla, there is a
mechanism by which to shuffle bugs around...that other people like
triagers can deal with.
But if you are driving feedback from users to email...well...no one
else can help re-catalog the misfiled ones and they just get dropped
on the floor.

-jef




More information about the fedora-advisory-board mailing list