[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)



This one time, at band camp, Lucas Nussbaum said:
> The need for review and feedback is another problem. It's often
> difficult to get feedback on a proposed change inside Debian. But I
> really don't think that it should be the release team's job alone to
> decide which project-wide improvements are good or bad. If it's too hard
> to reach consensus on -devel@ on a proposed improvement, I would rather
> prefer if we used the TC's ability to "offer advice".

Releases have, up to now, been the domain of the release team, since
that's sort of what they do.  What goals are set for a given release
seem to me to be something squarely in that realm, especially given that
there is no 'stick' - there's not really anything to compel others to
play along.

Can you explain why you think it would be a good idea to remove the
power to decide their own goals from a team, and why you think it would
be good for Debian to have one team drive another team's goals?  This is
so different to how we usually work that it seems jarring.

Cheers,
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

Attachment: signature.asc
Description: Digital signature


Reply to: