Thanks for the opinion :-)
To 1)
I DID imply it in my proposal, but I didn't spell it out clearly enough.
So assume this passage to be included in the proposal:
>ALL ports, even tier 3, share the same source code base. This should make
>moving up or down the chain much less work, save disk space, and avoid
>dublication of work. Packagers will have to become used to NMU uploads by
>porters, especially from tier 2 ports. If one upload by a port breaks the
>build of another, there are three parties interested in fixing it: The
>uploader, because he risks being flamed for it, the porters for whom the
>package is broken now (obviously), and the packager, because if one of
>the ports is tier 1 (or has chances to become it), he risks that his
>package isn't included (and for some packagers it is hopefully simply a
>matter of pride).
As for downgrading the severity of portability bugs: Yes, my proposal does
that (they are still all called RC, but if the packager is sure it will
only be a tier 2 port that has this bug, it doesn't have to bother him as
much). In its essence, that is what the original proposal wanted to
achieve: Don't let the ports hinder releasing as much. This can only be
achieved by putting the pressure on the porters instead: If they can't
keep up, they are "dropped" (to tier 2, that is). If you try to take that
pressure out, there is nothing left of the proposal...
to a) Using the same source base, plus the ability for porters to make
NMUs, should have this effect.
to b) If it breaks, it breaks. If I have understood procedures correctly,
users won't be able to download packages that didn't compile. So after
such an upload, the users of the the affected arch can still download the
old unstable package, the uploader gets flamed, and three parties are
interested in fixing the state.
And before the code freeze for stable, there is enough time to straighten
out those cases (with all parties interested in it, as explained).
Your suggestion would lead to splitting into arch specific code, which is
something that should avoided, imho.
to 2) I think in my proposal the upwards path is as clear as can be.
The biggest change is, that upon becoming stable tier 2, security updates
have to be provided.
I think that the case where a security update breaks a specific port
(hopefully a rare occurence), which is a tier 2, and where a solution
can't be worked out fast enough, is one of the rare occurences, where a
(temporary) code split should be allowed, to fix the vulnerability as fast
as possible.
Otherwise the simple fact that nothing changes with regard to tools or
hosting, should make upwards or downwards changes simple. And the fact
that all requirements to become higher tier are clearly measurable, should
provide ample motivation.
By and large I would say: Those concerns are taken into consideration :-)
--
SMS bei wichtigen e-mails und Ihre Gedanken sind frei ...
Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
