About the Open Source Software Mirror Alliance (Non-Technical Part)

Terminology: (It feels quite awkward)

  • Mirror: Like Ubuntu, CPAN, PyPi, etc.
  • Mirror site: An open source mirror site at a university, each mirror site hosts several mirrors
  • (Mirror) Node: Each mirror site that hosts the same mirror

Mirror Alliance Maintainers:

Following the Debian development model, the maintainers of the Mirror Alliance can be divided into Mirrors Maintainer and Mirrors Developer. Mirrors Developer are core developers who have maintenance access and decision-making voting rights on the main site of the Mirror Alliance; anyone involved in the development and maintenance of the Mirror Alliance can apply to become a Mirrors Maintainer.

Mirrors Maintainer can:

  • Maintain their responsible mirror nodes
  • Modify the forwarding policy of their responsible mirrors
  • Access the logs of their responsible mirrors
  • Modify the main site wiki
  • Submit bugs and patches to the issue tracker, participate in discussions

Mirrors Developer, in addition to what Mirrors Maintainer can do, can also:

  • Modify the forwarding policy of all mirrors
  • Access the logs of all mirrors
  • Add new mirrors
  • Participate in Mirror Alliance votes to decide on important matters
  • Participate in internal mailing list discussions
  • Post announcements on the announce mailing list

Developer Tools:

  • For Mirrors Developer: Scripts for common operations on the main site of the Mirror Alliance.
  • For Mirrors Maintainer: Scripts for each mirror node, including internal maintenance and communication between the node and the main site, similar to Debian packaging tools, which can be used by each mirror node, but are not mandatory.

Mirror Alliance Main Site:

  • Apply for an independent domain, hosted at a university.
  • The homepage lists the LOGOs of all mirror sites.
  • Set up a public wiki, issue tracker, and code repository. (We set up a Gitlab test site http://gitlab.lug.ustc.edu.cn and it feels quite useful)

Mailing Lists:

  • Set up an internal mailing list for Mirrors Developer.
  • Set up a “newbie list” where anyone can post and subscribe, with automatic forwarding of issue tracker messages for public discussion.
  • Set up an announce mailing list for posting announcements.

Relationships Between Mirror Sites:

  • Each mirror site maintains its own site as usual and can continue to provide mirror services and promote under its own name.
  • Official sources maintained by each mirror site can voluntarily notify the official open source software authorities to switch the official source to the Mirror Alliance.
  • For an open source software mirror, if the Mirror Alliance has already applied to become the official source in mainland China, other mirror sites should not apply to become the official source under their own name if the mirror operates well.

Suggestions for Becoming a Mirror Site:

  • The server is located within mainland China
  • The network conditions are relatively stable, with a fixed IP address

Classification of Mirror Sites:

  • Main Site: The core node of the Mirror Alliance, requires very stable performance, with low latency from networks of various operators.
  • Mainland Primary Mirror: Each mirror has one primary mirror node, which syncs from the upstream source, and other mirror nodes sync from it. Requires stability and significant bandwidth for international access.
  • Public Mirror: Requires stability and not too small bandwidth out of the campus.
  • IPv6-only Mirror: For schools that do not allow IPv4 services externally, the Mirror Alliance will only route internal IPv4 and nearby IPv6 to this mirror.
  • Campus Mirror: For schools with limited bandwidth out of campus or that do not allow external services, they can apply to become a campus mirror and provide the school’s IP range, and the Mirror Alliance will route requests from this IP range to the campus mirror, other requests will not be routed to this mirror.
  • Proxy Server: If the general public network speed within the campus is slow, and there is a server with fast public network speed but no storage resources, a “proxy server” can be set up within the school. It does not store any mirrors, only acts as a proxy. Provide the school’s IP range, and the Mirror Alliance will route requests from this IP range to the proxy server.

Allowing Non-University Mirrors to Participate:

In the tuna mailing list, some companies and institutions have expressed willingness to cooperate. They often have publicly routable bandwidth measured in gigabits, while university sources have better CERNET bandwidth. If universities and companies that love open source can cooperate, it will ensure better access speeds for both educational networks and public networks. Moreover, experienced technicians from these companies can also provide us with technical guidance and support.

If companies and institutions participate, the name “Educational Network” in the Mirror Alliance might not be suitable. If it’s called “China (Mainland) Open Source Software Mirror Alliance,” it seems a bit grand.

Comments

2013-03-19
▲