Re: release policy
> > I'm thinking we should ratify it, as is. As soon as possible.
On Sat, Jul 10, 2004 at 04:31:08PM +0100, Ian Jackson wrote:
> Gads, do we really need to ratify the entire text of this document ?
We don't need to. But, why not? That's what was delegated to us.
If anything, it may be that that document doesn't go far enough.
> > I'm thinking we should ratify a changed document [which is more
> > restrictive on DFSG issues] for releases following sarge.
>
> I think the problem we have here is not that we don't have enough
> documentation, it's that we don't have a process for resolving
> disputes quickly. We did have one - the Release Manager decides - but
> this issue has been so badly politicised that it's getting in the way
> of the RM's main job of release engineering.
Release engineering doesn't call for nimble policy making so much as it
requires stable policies.
Quick changes are very much the wrong way to do release engineering.
That said, I agree that bad politicisation [or whatever it's called]
has gotten in the way of the RM's main job.
> So, why don't we simply say something like:
>
> Following the recent General Resolution 2004-004, the Technical
> Committee believes that the Developers intent is that the release
> policy for sarge should not be affected by the Social Contract
> changes in GR 2004-003, and that the policy should remain de facto
> unchanged.
>
> We have been delegated the question of the release policy for sarge,
> in the light of the General Resolutions and other considerations, by
> the Release Manager.
>
> Accordingly, we decide that as regards DFSG issues the release policy
> for sarge should be the same as the policy which was actually applied
> for for woody (and for sarge before GR 003). Any questions regarding
> licensing problems are to be settled in a way most consistent with
> decisions actually made and implemented by the Release Manager
> according to that previous policy.
>
> Should there be a doubt on any specific issues we will adopt the
> following process:
>
> * When the implications of the pre-sarge policy are unclear, the
> Release Manager shall refer the details to the Technical
> Committee, with references to any relevant precedents. This
> referal should take the form of a bug report. The Release
> Manager should state their opinion if they have one.
>
> * The Technical Committee will discuss the matter, with reference to
> previously existing release policy documents and prior precedents.
> If no relevant precedent can be found then we will presume for new
> software that it is not to be included in sarge, but for software
> which was already included in woody that it will be included in
> sarge.
>
> * As soon as an opinion has been clearly expressed by any two
> members of the Technical Committee, the Release Manager shall
> implement that opinion and the bug shall be reassigned and/or
> closed as appropriate.
>
> * Such tentative opinions may be overruled by a normal TC
> resolution. People who wish such a tentative opinion to be
> reversed should therefore talk to the TC informally. They should
> not file bugs.
"When the implications of the pre-sarge policy are unclear,..."
Unclear to who? Given which has risen around this topic, I find it
likely that it will be possible to find people who are unclear on any of
a variety of points. "The Release Manager should state their opinion"
seems to indicate that you're not limiting this clause to cases where
the Release Manager feels any points are unclear.
I think we'd be better served by adopting specific policy, and using
normal TC resolution for when that policy needs to be changed.
"What goes into a release" should be stated clearly, and should be
changed rarely if ever. So I'm uncomfortable about introducing a new
decision making mechanism which has been designed to make such decisions
happen quicker.
Or maybe I'm not making any sense?
--
Raul
Reply to: