[Typo3-typo3org] TER 2.0 - updated concept!
Christian Jul Jensen
julle at typo3.org
Mon Apr 25 22:24:25 CEST 2005
On Monday 25 April 2005 19:42, Robert Lemke wrote:
> [1] http://typo3.org/teams/typo3org/documents/mirroring-the-ter/
What an amazing piece of work! Sets new standards for development processes
within the project. Respect!
A few comments in order of appearence:
(I use LaTeX style page/line refs, p1^2 is page 1 line 2 from the top, p3_4 is
page 3 line 4 from the bottom)
p2_1: "repositories.typo3.org", somehow seems like a weird name for the master
extension repository, I don't have a better suggestion though.
p3^1: "Super mirrors", will there be any pushing of data from the master rep,
or is it only based on cronjobs on the super-mirrors? also it reads:
"supporting mirrors synchronize with the master repository"(p3^8), wouldn't
it suffice to sync with the super-mirrors? To do some load distribution, and
also if nobody fetches the extensions from the super-mirrors they only need
to contain the hashes. I suggest syncing supermirrors to the master by
pushing from the master, and having supporting mirrors sync with the super
mirrors. This will protect the master server from load and scalability is
simply a question of adding super-mirrors. Did I miss somethin important?
p4^2: What's the "/t/e/" in the path?
p4_4-1: why? technically it should be fairly simple to supply the same
extensiosn that power TYPO3.org (but of course that would have very low
priority to support this), or is it to ensure that people don't provide
"special" mirrors to easy?
p5: "Specifications", I suggest adding doc as a special dependency between an
extension and it's documentation. If I look at how I use apt, I can imagine
that I will always want to download docs automatically, but not other
recommended extensions. Also it will be easier to determine whether an
extension provides docs or not, one wekaness of splitting it up is that we
risk undermining the perception that an extension is not fully done without
docs.
p5: "Virtual extensions", brilliant idea, I love it!
p6: "Install scripts", I also really like this. My first thought though was
'oh no don't use fixed names', it would be 'cleaner' to let the extensions
register methods, but maybe this is just one of the cases where it doesn't
make sense to take OO to the maximum extend. It probably only gives an
overhead of function calls without adding any flexibility.
One issue I missed:
Will it no longer be possibel to browse TYPO3 .org, select extensions there
and download in the EM based on this? I'm not sure how many people use that
feature, but did you forget about it or simply leave it out?
--
Christian Jul Jensen
The TYPO3 Association
http://association.typo3.org
More information about the TYPO3-team-typo3org
mailing list