Re: [gentoo-dev] Re: Re: On hosting self-produced distfiles
[bunch of linguistic stuff skipped..] Huh? Is it just me or is there anybody else who thinks that this went way beyound ridiculous? Especially considering that Diego himself is not a native English speaker.. Anyway, after having been all over the world (including 7 years in California) and having been in contact with many people I tend to *not* look at precise word/phrase meaning any more. Remember - oral/written, actually any kind of communication in any language is a *noisy channel*. Lets get back on topic? (OTOH it seems to me the original topic has also been bitten to death already). George
[gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
Hi everybody,
Within the next week or two, the Infrastructure team hopes to have the
Git repos hosted on the main VCS server migrated into Gitolite [4] for
ease of management [1]. A more exact timeline will be published within
the next few days.
We would like to consider re-arranging the namespace of repositories at
the same time. Suggestions are welcome (to the -dev list), the only idea
we have so far is a set of top-level directories:
proj/${PROJNAME}/${REPONAME}.git
private/${PROJNAME}/${REPONAME}.git
gentoo-portage.git [2]
gentoo-portage-historical.git [2]
The entirety of the proj/ namespace will be mirrored to
sources.gentoo.org (and anon.gentoo.org). This replaces the selective
mishmash of choosing repositories that are mirrored.
When the change goes live, if you have a checkout from any of the
following repositories, you will need to change your remote as follows:
OLD:
git+ssh://${USERNAME}@git.gentoo.org/var/gitroot/${REPO}.git
NEW:
git+ssh://g...@git.gentoo.org/${PATH}/${REPO}.git
The easy way to do it:
# git remote set-url ${REMOTENAME} ${NEWURL}
REMOTENAME is usually 'origin', but advanced git users may have another
name.
It is applicable for the following repositories:
/var/gitroot/devmanual.git [3]
/var/gitroot/gentoo-viewvc-templates.git
/var/gitroot/gstats.git
/var/gitroot/packages.git
(plus 3 private repositories that will be listed on gentoo-core)
[1] Yes, this is one of the checkbox items on the way to hosting the
main repositories in Git.
[2] This is an idea where I'd like to place the main tree, and the
additional graftable tree with the full history. I'm not entirely
happy with this location, and WELCOME suggestions to improve it.
[3] This is the old location, prior to the repository move to
git.overlays.gentoo.org.
[4] Thanks to idl0r for working on some modifications we needed.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpXFqITNCZF4.pgp
Description: PGP signature
Re: [gentoo-dev] Re: On hosting self-produced distfiles
On 2011.01.20 02:55, Diego Elio Pettenò wrote: Il giorno mer, 19/01/2011 alle 20.07 -0500, Rich Freeman ha scritto: Forward going? Or, should we go ahead and start retroactively updating ebuilds that have mirror:// in them right now? Presumably without a revbump over something like this... I wouldn't mind if it was done retroactively, but I'm not going to ask right now for all the ebuilds in tree right now to be converted. If you do happen to pass through a bunch of old ebuilds and edit them anyway please do update them to use long-term-reachable URLs. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ Diego, A few questions ... How does this work when a developer leaves and his account is removed. This will break the links to ~/public_html. What about our GPL obligations to provide sources? That carries on even after an ex developers ~/public_html has been deleted. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpBmJ00REpD5.pgp Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On 21:56 Fri 21 Jan , Sebastian Pipping wrote: On 01/21/11 21:35, Robin H. Johnson wrote: gentoo-portage.git [2] gentoo-portage-historical.git [2] [..] [2] This is an idea where I'd like to place the main tree, and the additional graftable tree with the full history. I'm not entirely happy with this location, and WELCOME suggestions to improve it. I would prefer something like gentoo-main or main-tree over gentoo-portage as could would help reducing the problem of mixing up our main tree and one of our package managers. If it actually is the main tree, why not put that in the name. Thanks for consideration. Sweet, we actually got an invitation to bikeshed! Here's my contributions: gentoo-tree.git gentoo-portage-tree.git portage-tree.git (the name 'portage' derives from bsd ports, so it makes sense to keep that connection to make it recognizable to that audience) -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgp6knDsYSf2N.pgp Description: PGP signature
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Fri, Jan 21, 2011 at 03:47:03PM -0600, Donnie Berkholz wrote: Sweet, we actually got an invitation to bikeshed! Here's my contributions: gentoo-tree.git gentoo-portage-tree.git portage-tree.git (the name 'portage' derives from bsd ports, so it makes sense to keep that connection to make it recognizable to that audience) Please note that I said _location_. I'm not so happy about putting them in in the toplevel namespace. You need to provide TWO names: 1. The current tree that we will start with. 2. The read-only graftable tree with full history (going back to the start of Gentoo commits). As much as I like the original Portage tree, I do agree it's lead to confusing of the source code of the package manager vs. the ebuild tree. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On 01/21/11 23:15, Robin H. Johnson wrote: On Fri, Jan 21, 2011 at 03:47:03PM -0600, Donnie Berkholz wrote: Sweet, we actually got an invitation to bikeshed! Here's my contributions: gentoo-tree.git gentoo-portage-tree.git portage-tree.git (the name 'portage' derives from bsd ports, so it makes sense to keep that connection to make it recognizable to that audience) Please note that I said _location_. I'm not so happy about putting them in in the toplevel namespace. I see. If the long-term goal is too have multiple packages trees, than maybe tree/main.git or tree/core.git would make sense and go well with proj/, as that is not plural either: no projs/, no trees/. It could make tree/core.git tree/science.git tree/games.git tree/... some day. You need to provide TWO names: 1. The current tree that we will start with. 2. The read-only graftable tree with full history (going back to the start of Gentoo commits). Any of these suffixes for the other one would work for me: * past * before * old * history historical is fine, just a bit long, maybe without need to. As much as I like the original Portage tree, I do agree it's lead to confusing of the source code of the package manager vs. the ebuild tree. Great to hear that you share this worry. Best, Sebastian
Re: [gentoo-dev] On hosting self-produced distfiles
On Thu, 20 Jan 2011 01:50:35 +0100, Diego Elio Pettenò wrote: snip Pushing files that are still available somewhere else, but cannot be directly fetched for whatever reason is still to be bone through /space/distfiles-local. This, above, is an important point for the below comment. *PLEASE NOTE:* This is to be considered QA policy, so we're going to ask soon to enforce this. This requirement, though, _will_ be superseded as soon as Infra provides us with a proper archive for this kind of files. I wonder how the QA team is going to enforce this? I can't think of any heuristics to distinguish between mirror://gentoo/self-produced distfile and mirror://gentoo/upstream distfile not self-produced - One way this can happen is dead upstream but useful application. Yes, we have GENTOO_MIRRORS but I've seen it often enough that GENTOO_MIRRORS value is invalid (user error) and SRC_URI is invalid which leads to a non-ideal user experience - at which point $dev normally changes SRC_URI to mirror://gentoo/. Care to touch on that topic? Note: An acceptable answer to me would be update documentation and use common sense because I don't think there is any other option. At risk of being too wordy, I'll leave it at that. Thanks, Jeremy
[gentoo-dev] Re: On hosting self-produced distfiles
Roy Bamford posted on Fri, 21 Jan 2011 20:50:53 + as excerpted: On 2011.01.20 02:55, Diego Elio Pettenò wrote: Il giorno mer, 19/01/2011 alle 20.07 -0500, Rich Freeman ha scritto: Forward going? Or, should we go ahead and start retroactively updating ebuilds that have mirror:// in them right now? Presumably without a revbump over something like this... I wouldn't mind if it was done retroactively, but I'm not going to ask right now for all the ebuilds in tree right now to be converted. If you do happen to pass through a bunch of old ebuilds and edit them anyway please do update them to use long-term-reachable URLs. How does this work when a developer leaves and his account is removed. This will break the links to ~/public_html. What about our GPL obligations to provide sources? That carries on even after an ex developers ~/public_html has been deleted. My understanding, IANAL, etc. Thankfully, Gentoo doesn't have to worry about that in most cases, because we don't provide binaries in most cases, and that's what triggers it. Where we do provide binaries, I believe we're fine as long as we've offered sources along with (and in the same manner as, CD for CD, ISO for ISO, link for link) the binaries as that fulfills our obligation. As long as the sources remain available with the binaries and the binaries are removed either first or at the same time as the sources, we're covered. If someone didn't choose to grab the sources, that's their problem. Only if we don't offer sources at the same time and in the same manner, but instead accompany the binaries with an offer for sources, does the (AFAIK) 3-year delay kick in and we have to worry about providing sources so long after the binaries are long outdated and for our part, forgotten. IOW, it pays to ensure that whenever we distribute binaries, we make sources available at the same time and in the same manner, as by doing so we avoid the three year clause entirely. =:^) Are we always ensuring that source availability in every act of (L)GPLed binary distribution? That's the BIG question, as it avoids at least the legal obligation (tho retention can be useful for practical reasons) of worrying about what happens to the sources after we've stopped distributing the binaries (and developers have left, etc) entirely. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On Friday 21 January 2011 22:35:38 Robin H. Johnson wrote:
Hi everybody,
Within the next week or two, the Infrastructure team hopes to have the
Git repos hosted on the main VCS server migrated into Gitolite [4] for
ease of management [1]. A more exact timeline will be published within
the next few days.
We would like to consider re-arranging the namespace of repositories at
the same time. Suggestions are welcome (to the -dev list), the only idea
we have so far is a set of top-level directories:
proj/${PROJNAME}/${REPONAME}.git
private/${PROJNAME}/${REPONAME}.git
gentoo-portage.git [2]
gentoo-portage-historical.git [2]
The entirety of the proj/ namespace will be mirrored to
sources.gentoo.org (and anon.gentoo.org). This replaces the selective
mishmash of choosing repositories that are mirrored.
When the change goes live, if you have a checkout from any of the
following repositories, you will need to change your remote as follows:
OLD:
git+ssh://${USERNAME}@git.gentoo.org/var/gitroot/${REPO}.git
NEW:
git+ssh://g...@git.gentoo.org/${PATH}/${REPO}.git
The easy way to do it:
# git remote set-url ${REMOTENAME} ${NEWURL}
REMOTENAME is usually 'origin', but advanced git users may have another
name.
It is applicable for the following repositories:
/var/gitroot/devmanual.git [3]
/var/gitroot/gentoo-viewvc-templates.git
/var/gitroot/gstats.git
/var/gitroot/packages.git
(plus 3 private repositories that will be listed on gentoo-core)
[1] Yes, this is one of the checkbox items on the way to hosting the
main repositories in Git.
[2] This is an idea where I'd like to place the main tree, and the
additional graftable tree with the full history. I'm not entirely
happy with this location, and WELCOME suggestions to improve it.
[3] This is the old location, prior to the repository move to
git.overlays.gentoo.org.
[4] Thanks to idl0r for working on some modifications we needed.
Assuming we're going to move the git.overlays.gentoo.org repos there as well
in the near future, this is the structure i am proposing:
source
- portage-main.git
- portage-history.git
infra (or sysadmin)
- (repo1).git
- (repo2).git
- ...
overlay
- project (instead of proj)
- sunrise.git
- kde.git
- ...
- personal (merge dev/ user/)
- aballier.git
- alexxy.git
- ...
website
- blogs.git
- planet.git
- forums.git
- gstats.git
- packages.git
- www.git (the gentoo cvs repo)
- ...
project (includes SOC projects, forks, gentoo projects etc)
- devmanual.git
- portage.git
- ...
--
Theo Chatzimichos (tampakrap)
Gentoo KDE/Qt, Planet, Overlays
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)
On 04:38 Sat 22 Jan , Theo Chatzimichos wrote: Assuming we're going to move the git.overlays.gentoo.org repos there as well in the near future, this is the structure i am proposing: source - portage-main.git - portage-history.git infra (or sysadmin) - (repo1).git - (repo2).git - ... overlay - project (instead of proj) - sunrise.git - kde.git - ... - personal (merge dev/ user/) - aballier.git - alexxy.git - ... website - blogs.git - planet.git - forums.git - gstats.git - packages.git - www.git (the gentoo cvs repo) - ... project (includes SOC projects, forks, gentoo projects etc) - devmanual.git - portage.git - ... I don't see any particular reason to distinguish between the main tree and overlays in this structure. Just do something common for both, like tree/ or ebuilds/ or packages/. In the same vein, there's no good reason I can think of to discriminate between overlays that are project vs personal, since either can be supported or unsupported. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpuPMTE5EJDE.pgp Description: PGP signature
