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?"...
signature.asc
Description: Digital signature
