This one time, at band camp, Lucas Nussbaum said: > On 01/12/13 at 17:53 +0000, Stephen Gran wrote: > > This one time, at band camp, Lucas Nussbaum said: > > > 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? The bullet-point new feature list for a given release is generally speaking, a combination of 'gnome x.x, kde x.x' style version enumeration and the result of release goals. See the bit about multiarch on http://www.debian.org/News/2013/20130504.en.html, for instance. I can't see how a set of new features targeted at the next release can't help but be related to the next release. > > 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). Huh. My impression from watching the last several releases was that the release team was a lot more involved than that in actually doing the work of meeting release goals, and not just a note keeper for someone else's pet project. > 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". OK, so you really do think the release team just does paper work for someone else's goals. I can understand why you don't have a problem changing who makes the decisions, then. I don't share your point of view about the amount of work the release team has historically put into this sort of thing. > 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. It's good of you to allow them the freedom to be able to choose the compiler version in the next release. You should be careful about allowing them that much power, it might go to their heads. > 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? I would presumably put something like: * Release Team members decide on the release goals for stable releases But I am a simple man. Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature