[ATrpms-devel] Increased update lead time, repo too large

[Jarod Wilson]

Resend, got bounced when I first sent it on Friday... (something about a local 
delivery error).

On Friday 13 May 2005 09:38, Axel Thimm wrote:
> On Fri, May 13, 2005 at 09:29:21AM -0700, Jarod Wilson wrote:
> > On Friday 13 May 2005 01:27, Axel Thimm wrote:
> > > Yes, I had to upload new ATrpms packages for another project while
> > > mythtv was still building (9 distributions, half of them for two
> > > archs, and even one mythtv build takes a couple of ages). There was no
> > > other way, sorry.
> >
> > I figured that was the case, so I'd waited a while before saying anything
> > about it. Guess I didn't wait long enough. ;-)
>
> The bad news are that the current support of so many distros with
> three different metadataformats and my non-scaling web site rebuilding
> scripts make the smallest update having a minimum of 2h lead time.

Ew.

> And now where ATrpms was listed rather high in the FC4t3 mirror lists
> (first in the German list) the box is quite occupied with delivering
> FC4t3 isos. I have started the upload procedure 5h (!!!) ago and it is
> still in metadata creation.

Ow.

> I'd like feedback on whether some distributions should finally face
> nirvana. Not only for mythtv, but atrpms in general. I tend to want to
> kill everything that RH has killed (EOLed). That would be RHL7.3 to 9
> and FC1 and 2.

I vote to kill them all, and from here on out, keep the policy of only 
supporting what Red Hat supports. ATrpms users wanting to stay on a 2.4 
kernel have the option of EL3 now, EL4 if they want a long-term supported 2.6 
option, and FC4 out the door shortly for the bleeding edge.

There's just no compelling reason anymore that ATrpms should have put forth 
the time and energy to support the EOL'd distros with the availability and 
support of free EL3 and EL4 rebuilds. I'm sure there's a vocal minority that 
would disagree, but its my take that the effort required for the EOL'd 
distros actually hurts more people than it helps, due to repository breakage 
and delays introduced by the build/upload/repogen time to support so many 
distros.

> I'd also welcome help in new web site rebuilding scripts. The current
> system is caching some parts and was intended to be performant, but
> it's scalability has long been exceeded.

I'll do whatever I can to help.

-- 
Jarod Wilson
jarod at wilsonet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-devel/attachments/20050515/e7e273d1/attachment.bin