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 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 release Sarge (barring any
> >> > unforseen consequences). Would it be possible to start testing this
> >> > proposal out now by increasing the frequency of dinstall, perhaps to
> >> > once every 6 hours until release?
> >
> >> I've talked about this with James Troup before. He seemed pretty
> >> receptive to speeding it up to something like twice a day, didn't seem
> >> to feel it would hit the mirrors much worse. It's possible he may still
> >> be waiting on SCC splitting up the base set of arches or the like before
> >> revisiting this.
>
> Who's SCC?
>
> If there's no technical *requirement* for this to happen first, we should
> go ahead with speeding up this up, precisely because it's such a good time
> to test its effects, both positive and negative. (Positive effects
> won't be so noticable right after Sarge releases) I'm assuming it would be
> a really easy change to revert if it has negative effects.
>
> >> (BTW, please note that when I or this proposal talks about the "dinstall
> >> run", we're using the circa 1998 definition that includes "mirror sync".
> >> The dinstall program itself aready runs every 15 minutes.)
> >
> > Twice daily seems more reasonable to me than hourly;
>
> Why? If you run it only twice daily, then the developers who are awake at
> one run will probably be asleep at the next, so there's still essentially
> a whole day's lapse before a developer can fix anything. I'd say a minimum
> of 4 times a day lets a developer see the result of his changes before the
> next time he goes to sleep. But the attraction of hourly is that a
> developer can see feedback from his changes within a couple of hours, and
> a developer may be able to clean up any bugs people noticed in the same
> sitting that he introduced them.
>
Hi folks,
just a question from john q. hacker:
is the files associated with a project have not been changed since the last run,
why is the process repeated? Could someone make the process run when the
files are changed? I'm thinking of an event-based approach.
-Kev
--
counter.li.org #238656 -- goto counter.li.org and be counted!
(__)
(oo)
/------\/
/ | ||
* /\---/\
~~ ~~
...."Have you mooed today?"...
Attachment:
signature.asc
Description: Digital signature