I say "practice" because our
retention policy  is not explicit about "composites".
See bug 489967  for more details
but in short I propose we leave only a couple of milestones repositories
in the .../eclipse/updates/4.6milestones composite and, say, 4 in the .../eclipse/updates/4.6-I-builds
The "raw" simple repositories
would stay in place and following existing retention policy, I propose.
[but am open to suggestions].
This started because I realized
we have "dropped" some features and bundles from our repositories
this cycle (e.g. Equinox's Aspectj weaving -- but not Equinox weaving in
general) and I was thinking if someone was casually building or testing
on whatever they got from .../eclipse/updates/4.6milestones they might
have a big surprise once we released. [Building against a composite is
a bad idea to begin with ... but ... just in case, I thought it would be
the community friendly thing to do.]
But, in addition, and maybe more important,
doing an update from one milestone to the next, or one I-build to the next,
gets longer and longer the closer we get to the end of a release or milestone
because so many "sub repositories" are linked to the composite.
[I have never measured it, but, seems longer, to me.]
If anyone can think of some down-sides
that make this proposal a bad idea, please comment in bug 489967.