Re: Re: pre-building NEW packages, when they only introduce new binary packages
Le February 12, 2008 03:19:47 am Joerg Jaspert, vous avez écrit : On 11293 March 1977, Philippe Cloutier wrote: Lets jump in here, even if not all points address your mail only. If by disfavour you imply that it's intentional that NEW packages aren't built before being accepted, I think you're wrong. I think it would require not completely trivial changes. It *is* intentional that NEW queue packages wont get build automagically. [...] Now, one might limit the packages to such ones that already got accepted in the past and just change binary package names. But thats IMO much more work than it will ever gain us, as you [...] - Have to sort them into the queue somehow. If you go and sort them below everything in unstable then you wont have *any* advantage from autobuilding NEW, as only faster architectures will ever built them, as the slower ones wont get down that far in the queue. You do get the advantage that builds for faster archs are ready right away. Also, slow archs don't necessarily always have a queue. They just need to have more buildds than fast archs. At the moment, only hppa and mips* have significant queues, so...at least arm would build sooner. [...] The whole thing is just way less benefit compared to the work one needs to do for it. Thanks. Of course, it *is* intentional not to throw NEW packages to the buildd network in its current form, since it's not designed to support that. I was talking about whether it was intentional to autobuild *none* of NEW. Your mail clarifies that this is not intentional, we just don't have the infrastructure for it, but we agree that even if it's possible to autobuild at least parts, this would be low priority work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: pre-building NEW packages, when they only introduce new binary packages
On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote: That probably won't make much time difference on fast archs (i386, amd64 etc), but on slower ones like mips, mipsel etc (those sometimes hold up testing transition :(). A missing build will only slow testing migration if the package wasn't built when the unstable testing delay is over. Since almost all uploads to NEW are low urgency, the build would need to take over 10 days to affect the time to testing migration. pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet uploaded] today), so it *can* make a difference (not a really big one though in this case) Ah, yes. I misinterpreted your message. I thought you meant that the package would spend more than the testing transition delay actually compiling, which is not reasonable. I see others reasons to mention slow arches: 1. Builds tend to take more time to be signed 2. Builds tend to fail more often 3. Slow arches are more often unable to keep up Your suggestion could help with 1 and 2, but not really with 3. If the NEW package gets earlier in the queue, it's built more quickly, but packages that come later are built more slowly. And 3 must be the main reason for the delay in this case, presumably more than 90% of the delay. To speed up testing migration due to missing builds, it would be much more efficient to work on buildd redundancy (or other improvements to the buildd network). More/faster buildds, nicer dependencies etc, sure. But why not this one too? ;) I didn't mean this one shouldn't be done. I just meant that if it should, it's a low priority one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: pre-building NEW packages, when they only introduce new binary packages
Dear Philippe, if the ressources are scarce, I think that it would be fair that the internal competition for the access to them would be organised in a productive way. The current system disfavours the works that changes the structure of the package. How does this fit in a strategy to optimise the usage of the buildd power in Debian? It avoids building packages that will be rejected. If by disfavour you imply that it's intentional that NEW packages aren't built before being accepted, I think you're wrong. I think it would require not completely trivial changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: pre-building NEW packages, when they only introduce new binary packages
Le Mon, Feb 11, 2008 at 02:44:59PM -0500, Philippe Cloutier a écrit : If the NEW package gets earlier in the queue, it's built more quickly, but packages that come later are built more slowly. Dear Philippe, if the ressources are scarce, I think that it would be fair that the internal competition for the access to them would be organised in a productive way. The current system disfavours the works that changes the structure of the package. How does this fit in a strategy to optimise the usage of the buildd power in Debian? Of course there are alternatives to competition. When a buildd has a 15-day queue for more than a month, we could agree to refrain from uploading changes that can be postponed, in the same spirit as the people who share their cars when trains are on strike. An alternative approach would be to add a buildd, but for a reason that I do not understand, it seems to be off-topic on this list. So let's learn the décroissance way in Debian, it is a good training for real life anyway. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
