<div dir="auto">Please remove my email from the mailing list thank you.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 5, 2022 at 9:46 AM Cyril Brulebois <<a href="mailto:kibi@debian.org">kibi@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Roland Clobus <<a href="mailto:rclobus@rclobus.nl" target="_blank">rclobus@rclobus.nl</a>> (2022-03-05):<br>
> On 05/03/2022 12:40, Cyril Brulebois wrote:<br>
> > We could, and should, release a new d-i and possibly an Alpha 1 at some<br>
> > point, but I don't have a specific timeline for that.<br>
> <br>
> Understood. I assume that an Alpha 1 release will be made somewhere<br>
> near the release date of bookworm.<br>
<br>
In the past I've tried to have an Alpha 1 released after a few months<br>
into the new release cycle, then aim for something like a release every<br>
1-2 months.<br>
<br>
But the archive can disagree from time to time, and lately, I'm rather<br>
busy with other things…<br>
<br>
> Indeed. A new debian-installer upload would need to happen in<br>
> lock-step with every new ABI in src:linux, to guarantee a consistent<br>
> state of d-i. This could mean quite some work on your side.<br>
<br>
Uploading more often could be doable; the current approach has been to<br>
upload whenever we were getting close to wanting a new release of the<br>
installer, following up with 1-2 more uploads if things didn't work out<br>
immediately.<br>
<br>
> I'm looking at possible solutions here (that's why I've added the<br>
> rb-general mailing list):<br>
> * (Manually) do official releases of debian-installer more often<br>
<br>
Doable, as stated above.<br>
<br>
>   (as I wrote, openQA will soon have some tests that detect when the<br>
>   kernel version got out-of-sync)<br>
<br>
Well, I do follow kernel uploads and ABI bumps closely, so that's a<br>
problem that's already solved (git says since 2013).<br>
<br>
FWIW we're seeing mutiple hours to multiple days of delay for some<br>
architectures (we need the *-signed packages to get processed).<br>
<br>
> * Automatically release git snapshots to deb.d.o instead of d-i.d.o<br>
<br>
Uploading untested stuff to the archive, automatically? No, thanks.<br>
<br>
> * Extend snapshot.d.o and/or <a href="http://snapshot.notset.fr" rel="noreferrer" target="_blank">snapshot.notset.fr</a> to cover d-i.d.o in<br>
>   addition to deb.d.o<br>
<br>
Maybe avoidable if we go for more frequent uploads.<br>
<br>
> * No changes, and accept that older images cannot be recreated (this<br>
>   option is not preferred by me)<br>
> * Other ...<br>
> <br>
> > How long do you need to go back / how long do you need to keep a given<br>
> > build? Maybe we could just keep (some) builds for a longer while there,<br>
> > but that's at 90 days already.<br>
> <br>
> Looking at <a href="https://d-i.debian.org/daily-images/amd64/" rel="noreferrer" target="_blank">https://d-i.debian.org/daily-images/amd64/</a>, the current<br>
> history I can see is about 15 days.<br>
<br>
Right, ISTR that was around 30 days, glanced at the graph before hitting<br>
the sack and didn't check thoroughly: we indeed clean more frequently<br>
than showed on the graph.<br>
<br>
> While investigating reproducible issues I personally tend to pick some<br>
> timestamp and work on that for a longer period of time. 90 days would<br>
> suffice completely for my purpose.<br>
<br>
At the moment, daily-images is 42G, 6.8G of it being amd64. If we<br>
estimate a ×6 in size for just that architecture, that's nearly doubling<br>
that size, and it's only covering that one architecture. The machine is<br>
shared across various services, but has 121G free at the moment, so we<br>
could probably try something like that (maybe some middleground like 45<br>
days for starters) if that helped in the very short term? Or would you<br>
need to look at more architectures immediately?<br>
<br>
<br>
Cheers,<br>
-- <br>
Cyril Brulebois (<a href="mailto:kibi@debian.org" target="_blank">kibi@debian.org</a>)            <<a href="https://debamax.com/" rel="noreferrer" target="_blank">https://debamax.com/</a>><br>
D-I release manager -- Release team member -- Freelance Consultant<br>
</blockquote></div></div>