* kamaraju kusumanchi ([EMAIL PROTECTED]) [050811 23:46]:
> I was just wondering if there are any efforts currently undergoing to
> make this a reality? or has the idea been just dropped? What is
> preventing its implementation?
Currently, even the daily dinstall is creating pain to us, as spohr
* kamaraju kusumanchi [Thu, 11 Aug 2005 12:04:18 -0400]:
> I need not wait for one day to erect my broken sid machine.
Indeed, you need not. In case of breakage, fixed packages would be
available right after upload in http://incoming.debian.org.
(Except during that special hour or now ho
.
> http://wiki.debian.net/?RunDinstallHourly
> I have also read the corresponding thread on debian-devel
> http://lists.debian.org/debian-devel/2005/01/msg00141.html
> I was just wondering if there are any efforts currently undergoing to
> make this a reality? or has the idea be
On 8/11/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Processing time to do a dinstall cycle and pulse all mirrors is quite
> high. You would hit mirrors with the next pulse while the old one
> still runs a lot of the time and, even worse, update the master mirror
> between phase1 and phase
sid machine.
>
> http://wiki.debian.net/?RunDinstallHourly
>
> I have also read the corresponding thread on debian-devel
>
> http://lists.debian.org/debian-devel/2005/01/msg00141.html
>
> I was just wondering if there are any efforts currently undergoing to
> make this a rea
Hi
I was just browsing through the wiki and came across this very
interesting idea. It would be really useful if the mirrors are updated
more frequently. I need not wait for one day to erect my broken sid machine.
http://wiki.debian.net/?RunDinstallHourly
I have also read the corresponding
Remember to make sure the Packages.gz files appear on the mirrors
_after_ the packages they refer to are in place. Bug #217957.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Tue, Jan 11, 2005 at 04:16:32PM +1000, Anthony Towns wrote:
> The other benefits of installing packages more quickly -- working out if
> you've screwed up the upload, or that they don't build -- already happen
> in response to the package getting accepted anyway.
Having the Maintainers file s
* Tollef Fog Heen ([EMAIL PROTECTED]) [050110 23:35]:
> FWIW, our experiences with Ubuntu shows that having fast dinstall
> cycles is very helpful. You can sit and codevelop with people
> uploading to the archive as you go and letting other people in on what
> you are doing rather than having priv
Matt Zimmerman wrote:
On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote:
FWIW, our experiences with Ubuntu shows that having fast dinstall
cycles is very helpful. [...] It's a variant of the ïrelease often,
release earlyï principle.
(Strictly, it's an instance of the principle)
The dow
Matt Zimmerman wrote:
>On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote:
>> Tollef Fog Heen wrote:
>> >
>> >The downside of doing this is the extra load on the autobuilder
>> >network, so Debian might not want to do it because of that.
>>
>> It might affect the mirrors, too...
>
>It
On Mon, Jan 10, 2005 at 10:54:34PM +, Steve McIntyre wrote:
> Tollef Fog Heen wrote:
> >
> >FWIW, our experiences with Ubuntu shows that having fast dinstall
> >cycles is very helpful. You can sit and codevelop with people
> >uploading to the archive as you go and letting other people in on w
Tollef Fog Heen wrote:
>
>FWIW, our experiences with Ubuntu shows that having fast dinstall
>cycles is very helpful. You can sit and codevelop with people
>uploading to the archive as you go and letting other people in on what
>you are doing rather than having private repositories or similar
>solu
Tollef Fog Heen wrote:
> The downside of doing this is the extra load on the autobuilder
> network, so Debian might not want to do it because of that.
Unless we already have a lot of developers putting off an upload until
another day, this is a non-issue, since the autobuilders begin as soon
as a
* Steve Langasek
| There are really very few concrete benefits I can see to increasing the
| dinstall frequency, but one in particular is to speed up debian-installer
| testing. Most other bugs don't require a full dinstall cycle to give people
| a good idea whether they've been fixed, but the i
Robert Lemmen wrote:
On Wed, Jan 05, 2005 at 07:12:34AM -0500, Joey Hess wrote:
All of the benefits I've thought of from running dinstall more often
really only apply to unstable package churn issues. Running britney more
often sounds relatively orthagonal actually, though it does sound useful
for
On Tue, Jan 04, 2005 at 02:45:12PM -0800, Ken Bloom wrote:
> On Wed, 05 Jan 2005 09:36:11 +1100, Andrew Pollock wrote:
>
> > On Tue, Jan 04, 2005 at 10:16:27AM -0800, Ken Bloom wrote:
> >> http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals
> >
Steve Langasek wrote:
> And it's not like users want more frequent updates, either. Once a day is
> plenty often to be fiddling with apt-get; many sid users don't update nearly
> that often, after all.
But we still get good coverage of each set of changes distriuted amoung
our users even if most
On Tue, Jan 04, 2005 at 11:16:44PM -0800, Ken Bloom wrote:
> On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote:
>
> > On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote:
> >> Ken Bloom wrote:
> >> > http://wiki.debian.net/?RunDinstallHourly (part of
On Wed, Jan 05, 2005 at 07:12:34AM -0500, Joey Hess wrote:
> All of the benefits I've thought of from running dinstall more often
> really only apply to unstable package churn issues. Running britney more
> often sounds relatively orthagonal actually, though it does sound useful
> for those annoyin
Steve Langasek wrote:
> Twice daily seems more reasonable to me than hourly; for release purposes,
> another factor is how often britney runs, since that's what triggers changes
> in the testing suite. Doubling the frequency of britney runs seems
> reasonable to me, but hourly would surely be over
> for release purposes,
> > another factor is how often britney runs, since that's what triggers
> > changes in the testing suite. Doubling the frequency of britney runs
> > seems reasonable to me, but hourly would surely be overkill considering we
> > would still wa
On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote:
> On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote:
>> Ken Bloom wrote:
>> > http://wiki.debian.net/?RunDinstallHourly (part of the
>> > ReleaseProposals topic on wiki.debian.net) discusses the conc
On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote:
> Ken Bloom wrote:
> > http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals
> > topic on wiki.debian.net) discusses the concept of speeding up the release
> > process by running dinstall hourly in
Ken Bloom wrote:
> http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals
> topic on wiki.debian.net) discusses the concept of speeding up the release
> process by running dinstall hourly instead of once per day. This seems (to
> my amateur eyes) like a technically s
On Wed, 05 Jan 2005 09:36:11 +1100, Andrew Pollock wrote:
> On Tue, Jan 04, 2005 at 10:16:27AM -0800, Ken Bloom wrote:
>> http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals
>> topic on wiki.debian.net) discusses the concept of speeding up the
>> relea
On Tue, Jan 04, 2005 at 10:16:27AM -0800, Ken Bloom wrote:
> http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals
> topic on wiki.debian.net) discusses the concept of speeding up the release
> process by running dinstall hourly instead of once per day. This seems
http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals
topic on wiki.debian.net) discusses the concept of speeding up the release
process by running dinstall hourly instead of once per day. This seems (to
my amateur eyes) like a technically simple change to make even before we
28 matches
Mail list logo
