Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 01/12/13 at 17:53 +0000, Stephen Gran wrote:
> 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.
Sure.
> 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.
Ah, interesting. My POV is that "release goals" are kind-of misnamed,
because most of them are not specific to releases, but are instead
general technical changes.
Most of the goals proposed on https://wiki.debian.org/ReleaseGoals
are very valid and interesting technical changes, but I really fail to
see how they are specific to a given release. Maybe you could explain
why you think that it's the case?
> 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.
Release goals are usually achieved by contributors working on one
specific goal, not by the release team (= the release team doesn't
actively fix packages for release goals). The role of the release team
regarding release goals is to:
1) evaluate/approve goals
2) follow progress (using BTS usertags, usually) and re-evaluate during
the release cycle.
So, I don't think that it's correct to describe release goals as the
release team's "own goals".
Then, yes, I question whether it should really be the release team's
role to evaluate and approve such goals. I'm currently working on a
delegation for the release team (non-final draft at [1]), and I agree
that fictious goals such as "gcc 4.9 by default in jessie" or "GNOME
3.14 in jessie" would totally be in the realm of the release team, but
are already covered in the delegation.
If you think that the release team should have the power to decide on
release goals, how should this draft delegation be changed to include
that?
[1] http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=blob;f=release-delegation.txt
- Lucas
Reply to: