[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] A typical use-case

I've noticed that too ... now that we have three releases at one URL! ...
bummer. And ... I seem to recall you have suggested this same improvement
before, Thomas :)  ... but please don't stop trying to improve things!

One counter view is that many people also want the characteristic that
"once a URL works for something, it should always work" (i.e. repositories
URLs are persistent, and "forever") ... for example, perhaps another
product or project or build might really needs SR0 content, and they have
printed books or tutorials on "how to install their product" or doing
maintenance on their SR0 based product and it would stop working if SR0
content moved to a ...releases/indigo-with-legacy URL. (And, keep in mind,
for what ever reason, they might really did need some very specific SR0
content constraint, and something would break for them if users started
with SR2).

Plus, I suspect many people would think that p2 should be in charge of p2
optimization, not the repository authors or creators (my personal view is
that it could be a balance ... just stating a counter argument). For
example, I have heard rumors that p2 does not currently take advantage of
the "timestamps" that are part of every p2 repository metadata. Perhaps
something like that could be used (by client-side p2) to better know "what
to try first" and only fetch more, older stuff, if the most recent stuff
doesn't satisfy constraints?

Another possible approach ... but kind of a stretch ... might be some
optimization from the opposite direction. We currently have
our .../releases/indigo composite made up of sub-repositories with
date-time stamp directory name. I have always maintained these should not
be "published" and should not be considered "permeant" ... they might move
to archives some day, there could times that even once "published" that
"final date-time sub-repo" has to change to correct an IP issue, or,
perhaps be "added to" to provide security patches, or something similar.
But ... after all those qualifiers ... perhaps we could provide
sub-repositories named such as SR0, SR1, SR2 that would be "published" and
considered permanent, so those that really wanted only the very specific
content could "manually" add those more specific software sites to their
lists? This would mean, though, that each of those SRx repositories itself
would need to be a composite, pointing to dated repositories (that could
move to archives, or be changed "last minute" ... and, the problem with
that, is that having "too many indirect children" is already a problem for
some users (in a different way than what you are describing, having to do
with frequency of HTPP "round trip" requests).

Lastly, (in the least-likely-to-happen-anytime-soon category) ... if we
could get people to make sure their version/qualifiers only changed when it
was really required (i.e. their content substantially changed) we might do
a better job of "pruning" the release repositories and minimizing quantity
of changes. But this would take more work and effort from each project
(both to produce the right stuff, and to test the final result), and more
of a effort from the "common repo release engineer" (currently, me :) to
maintain and quality-check the common (central) release repository.

I don't mean to dampen discussions of improvements ... I'm sure
improvements are possible and would love to see some and I would be willing
to help (well, a little, if effort is small :)  ... but, thought I'd
mention these counter arguments to simply "moving old stuff to a different
URL". I think that'd cause more problems than it would solve. My intuition
is that any substantial improvements will take some substantial effort.

Not to mention, I could be misunderstanding your suggestion, so do please
keep the discussion going in any case, or, open a cross-project bug, if you
think there is a problem that could be improved.


From:	Thomas Hallgren <thomas@xxxxxxx>
To:	P2 developer discussions <p2-dev@xxxxxxxxxxx>,
Date:	02/26/2012 08:23 AM
Subject:	[p2-dev] A typical use-case
Sent by:	p2-dev-bounces@xxxxxxxxxxx

1. I'm downloading and installing Eclipse Classic 3.7.2.
2. I'm installing something from Indigo.

At step 2, I'm forced to wait while all children of the Indigo release are
downloaded. Why? I'm only interested in SR2.
The previous releases will just a) take a long time to download, and 2)
consume a lot of memory when perused.

I know there are cases where someone would like to revert to a previous
install etc. and that all previous releases
therefore must be available, but what I can't understand is why this must
control the default behavior for the 99% of
the users that never needs that. Why not let releases/indigo appoint the
last release and have something like
releases/indigo-with-legacy appoint the composite?

Thoughts ?

- thomas

p2-dev mailing list