Your message dated Thu, 22 Mar 2001 02:30:25 -0500
with message-id [EMAIL PROTECTED]
and subject line Bug#90511: proposal] addressing objections (re: disallow
multi-distribution uploads)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been
Processing commands for [EMAIL PROTECTED]:
reopen 90511
Bug#90511: [proposal] disallow multi-distribution uploads
Bug reopened, originator not changed.
thanks
Stopping processing here.
Please contact me if you need assistance.
Darren Benham
(administrator, Debian Bugs database)
On Wed, 21 Mar 2001, Ben Collins wrote:
On Thu, Mar 22, 2001 at 12:11:43AM +0100, Santiago Vila wrote:
If there is need of a technical reason here, we need a technical
reason to forbid legitimate uploads, which is (one of the things) your
proposal would do.
What is a legitimate reason
Your proposal is exactly like throwing the bash with the baby (sorry, don't
remember the exact wording).
It's throwing out the baby with the bath water :)
And you are probably right. Some of Manoj's points are setting in. The
only thing is that this requires a lot of checking on dinstall's
On Wed, Mar 21, 2001 at 12:45:31PM -0500, Ben Collins wrote:
- tagemfrozen/em/tag
+ tagemtesting/em/tag
I don't think any conclusion has yet been reached about whether or not
we will have some sort of frozen distro during the freeze. So I'm
unsure whether we should
On Wed, Mar 21, 2001 at 01:13:17PM -0500, Ben Collins wrote:
no reason for it. In fact, the only technical reason was back when we
had frozen/unstable uploads, and they do not occur any longer.
We have yet to see what a freeze in the new setup actually looks
like. It has been discussed, but no
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Wichert == Wichert Akkerman [EMAIL PROTECTED] writes:
Wichert Policy should set guidelines for making packages [...]
Wichert The less details, the better.
Ben Um. Policy *IS* the guide for making packages now. There's no
Ben Packaging
Hi,
Looking at the original bug report, the history section seems
to detail implementation flaws in buildd's and dinstall, and the
major motivation for this proposal seems to ber a workaround for the
shortcomings of the dinstall+buildd system. I think this motivation
is bogus, we
Ben == Ben Collins [EMAIL PROTECTED] writes:
Ben What is a legitimate reason for uploading to stable/unstable other than
Ben convience? I see none.
Is there a reason for policy to disallow convenience
(incidentally, what reason is there to use helper packages other than
convenience?
Ben == Ben Collins [EMAIL PROTECTED] writes:
Ben Yes it does help. By allowing stable/unstable uploads, we implicitly
Ben allow maintainers to do something potentially harmful and with almost
Ben zero technical gain. By disallowing it, we raise awareness that it is
Ben most commonly not a
Ben == Ben Collins [EMAIL PROTECTED] writes:
Ben The only objections I have seen are simplified by it is too difficult
Ben to for that one maintainers and it should be possible to do this for
Ben packages that do not break.
You now have wnother one: There is little technical merit in
-BEGIN PGP SIGNED MESSAGE-
Hi,
I second this proposal.
manoj
- --
If I told you you had a beautiful body, would you hold it against me?
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D
On Thu, Mar 22, 2001 at 08:23:20AM -0600, Manoj Srivastava wrote:
No, you have outlined problems in dinstall and the buildd
process. There is inherently no reason not to have multiple versions
of a package in the same distribution using package pools, apart from
the current
I'm pondering a new angle to this. Perhaps we don't even need to mess
with dinstall. What would really suffice is a check in the testing
scripts that disallows anything moving from unstable to testing if it
depends on something marked obsolete.
This could be anything in oldlibs, and special
On Thu, Mar 22, 2001 at 10:44:17AM -0600, Manoj Srivastava wrote:
There is not technical reason
for not building uploads to stable unstable twice in buildd either.
Marcus I think this is not true. What is meant by this? It means
Marcus building the same package twice, with the same
On Thu, Mar 22, 2001 at 06:16:43PM +0100, Marcus Brinkmann wrote:
On Thu, Mar 22, 2001 at 10:44:17AM -0600, Manoj Srivastava wrote:
The stable package need not go into the package pool. Am I
mistaken in assuming that proposed updates packages are not in the
package pool? If I am
On 22-Mar-01, 10:28 (CST), Ben Collins [EMAIL PROTECTED] wrote:
I'm pondering a new angle to this. Perhaps we don't even need to mess
with dinstall. What would really suffice is a check in the testing
scripts that disallows anything moving from unstable to testing if it
depends on something
On Thu, Mar 22, 2001 at 08:14:13PM +0100, Marcelo E. Magallon wrote:
Ben Collins [EMAIL PROTECTED] writes:
Yes, proposed updates do go into the pool.
Interesting. Which Packages file points to them? Certainly not
stable's (at least not for a while), certainly not unstable's (not
18 matches
Mail list logo
