* Matthew Wilcox ([EMAIL PROTECTED]) [060914 14:02]:
On Wed, Sep 13, 2006 at 10:38:39AM +0300, Fabian Fagerholm wrote:
However, the most recent publications indicate that volunteer incentive
is not a well understood area of economics. In fact, it's one of the hot
topics that economists are
On Sun, Apr 22, 2001 at 11:23:43AM +0100 , Michel Salim wrote:
Hello,
I apologise if this is considered off-topic - might be barking up the
wrong tree in the wrong forest here - but bringing up an old issue here
of release frequency, once the transition to using package pools and the
new
Hello,
I apologise if this is considered off-topic - might be barking up the
wrong tree in the wrong forest here - but bringing up an old issue here
of release frequency, once the transition to using package pools and the
new debian-installer is done, would it be reasonable to expect Debian
Enrique Zanardi wrote:
On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote:
Enrique Zanardi writes (Re: Release management - technical):
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
...
I think we can only do one of these. With hamm we're doing the
latter
Enrique Zanardi writes (Re: Release management - technical):
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
...
I think we can only do one of these. With hamm we're doing the
latter; in the future I think we should do the former.
Fine, as long as we have some long term goals
On Mon, 22 Jun 1998, Ian Jackson wrote:
We should continue to have `long term goals', and I applaud people who
work towards them, but we must be able to make a release even when
they are not met. It is better to have a release now and goals later
than no release now and goals later !
and
! | Fax: (+49) 2405/4670-10
-Original Message-
From: Craig Sanders [SMTP:[EMAIL PROTECTED]
Sent: Monday, June 22, 1998 4:17 PM
To: Ian Jackson
Subject:Re: Release management - technical
anyway, what i really wanted to say here
On Mon, Jun 22, 1998 at 01:38:21PM +0100, Ian Jackson wrote:
Enrique Zanardi writes (Re: Release management - technical):
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
...
I think we can only do one of these. With hamm we're doing the
latter; in the future I think we
At 5:38 AM -0700 6/22/98, Ian Jackson wrote:
David Engel writes (Re: Release management - technical):
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
Q. What are we trying to achieve ?
A. There are two possibilities that I can see
- Timely and good-quality releases
Incoming - unstable - unreleased - stable
100% agree.
some times unstable is so stable, that many people use it. this is bad,
if it's stable, it should have been released.
some times unstable is absolutelyy not useable, and it breaks my system
(grep bug, bash bug, new xxx without new
Ian Jackson wrote:
I think that in order to make sense of what's being said here we need
to step back a bit, and think about abstractions rather than
implementation. Lots of people (myself included) have been posting
rather detailed proposals.
Q. What are we trying to achieve ?
A.
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
Q. What are we trying to achieve ?
A. There are two possibilities that I can see
- Timely and good-quality releases, or
- Releases which meet some predefined set of goals.
I think we can only do one of these. With hamm
Just briefly: we will _not_ be voting on release process/
architecture. This is a technical decision, and is therefore up to
the developers concerned (Brian, mainly), and the Technical Committee.
Technical design and decisions must not be left to a vote.
I'll be making another posting about
that I can see
- Timely and good-quality releases, or
- Releases which meet some predefined set of goals.
I think we can only do one of these. With hamm we're doing the
latter; in the future I think we should do the former.
Most people seem to be in agreement that the release management
In article [EMAIL PROTECTED] you wrote:
: We need to think about what kinds of thing need to happen to a package
: or to a distribution before we release it as `stable'.
Yes.
I find it impossible to completely divorce the conceptual model from any
reference to details of the present or any
On Tue, Jun 09, 1998 at 04:21:57PM +0100, Ian Jackson wrote:
I think that in order to make sense of what's being said here we need
to step back a bit, and think about abstractions rather than
implementation. Lots of people (myself included) have been posting
rather detailed proposals.
Q.
On Tue, 25 Jun 1996, Scott Barker wrote:
Ian Jackson said:
We *must* provide a tree which contains only the most rcently
bug-fixed versions of everything, and we *must not* require people to
download broken packages only to have to download good ones too.
ok. This is important, and I
Date: Wed, 1 Nov 95 13:16 GMT
From: Ian Jackson [EMAIL PROTECTED]
Ian Murdock writes (Re: Release management and package announcements):
Are we going to start with an a.out 1.0 and migrate to an ELF 1.0?
If so, I'd agree that this is what we should do (and what I'll do
if we
From: Ian Jackson [EMAIL PROTECTED]
Ian Murdock writes (Re: Release management and package announcements):
Are we going to start with an a.out 1.0 and migrate to an ELF 1.0?
If so, I'd agree that this is what we should do (and what I'll do
if we all think this is the best
Ian Jackson [EMAIL PROTECTED] said:
Somehow the FTP site maintainer's programs also need to know which
section (subdirectory) the files should go in. I suggest that this
information be provided by the `overrides' file on the FTP site, which
is already used by the npdpkg
Bill Mitchell writes (Re: Release management and package announcements):
Ian Jackson [EMAIL PROTECTED] said:
Somehow the FTP site maintainer's programs also need to know which
section (subdirectory) the files should go in. I suggest that this
information be provided
Agreed. I don't think the location should be decided by individual
package maintainers, though they will be free to suggest a location.
The Section field from the control file can be used for this.
If the SECTION field is not going to reliably contain the section name
where
Date: Wed, 1 Nov 95 22:05 GMT
From: Ian Jackson [EMAIL PROTECTED]
Bruce Perens writes (Re: debian-1.0 ):
[EMAIL PROTECTED] said:
it might create problems for the mirrors.
I think that while it is in its current state, 1.0 should not be where
mirrors will find it
Date: Sun, 29 Oct 95 01:04 GMT
From: Ian Jackson [EMAIL PROTECTED]
If this is true then we need to copy the whole of the binary area from
0.93 to 1.0, so that 1.0 instantly becomes the `bleeding-edge'
distribution.
Are we going to start with an a.out 1.0 and migrate to an ELF 1.0?
On Sun, 29 Oct 1995, Ian Jackson wrote:
We need to decide what information the package maintainer needs to
supply to the FTP site maintainer for the correct placement of the
package.
[...]
I don't particularly care about how this is represented in the
(machine-readable) dchanges format,
There is, I think, an overlap between the release management strategy
and the package announcement format thread.
We need to decide what information the package maintainer needs to
supply to the FTP site maintainer for the correct placement of the
package.
Can I take it that following the thread
26 matches
Mail list logo
